Transport Layer Security (TLS) - AWS App Mesh
証明書の要件TLS 認証証明書TLS をネゴシエートするための App Mesh による Envoys の設定方法暗号化の検証証明書の更新TLS 認証を使用するように Amazon ECS ワークロードを設定します。 AWS App MeshTLS 認証を使用するように Kubernetes ワークロードを設定します。 AWS App Mesh

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Transport Layer Security (TLS)

App Mesh では、Transport Layer Security (TLS) は、仮想ノード や 仮想ゲートウェイ などのメッシュエンドポイントによって App Mesh で表される、コンピューティングリソースにデプロイされた Envoy プロキシ間の通信を暗号化します。プロキシは TLS をネゴシエートして終了します。プロキシがアプリケーションと一緒にデプロイされる場合、アプリケーションコードには TLS セッションをネゴシエートする役割はありません。プロキシが、アプリケーションに代わって TLS をネゴシエートします。

App Mesh では、次の方法で TLS 証明書をプロキシに提供できます。

  • () によって発行される AWS Certificate Manager (ACM) からのプライベート証明書。 AWS Private Certificate Authority AWS Private CA

  • 独自の認証局 (CA) によって発行された仮想ノードのローカルファイルシステムに保存されている証明書

  • ローカルの Unix ドメインソケットを介して Secrets Discovery Service (SDS) エンドポイントによって提供される証明書。

Envoy プロキシの認可 は、メッシュエンドポイントで表されるデプロイ済みの Envoy プロキシで有効にする必要があります。プロキシ認証を有効にする場合は、暗号化を有効にするメッシュエンドポイントのみへのアクセスに制限するようお勧めします。

証明書の要件

証明書のサブジェクト代替名 (SAN) の 1 つが、メッシュエンドポイントによって表される実際のサービスの検出方法に応じて、特定の基準に一致する必要があります。

  • DNS — 証明書 SAN の 1 つが、DNS サービスディスカバリ設定で指定された値と一致する必要があります。mesh-endpoint.apps.local というサービスディスカバリ名を持つアプリケーションの場合、その名前と一致する証明書を作成するか、ワイルドカード *.apps.local を使用して証明書を作成することができます。

  • AWS Cloud Map— 証明書 SAN の 1 つが、 AWS Cloud Map この形式を使用するサービス検出設定で指定された値と一致する必要があります。service-name.namespace-nameServiceName mesh-endpoint と NameSpaceName AWS Cloud Map apps.local のサービス検出設定を使用するアプリケーションでは、名前と一致する証明書mesh-endpoint.apps.local、またはワイルドカードを含む証明書を作成できます。*.apps.local.

どちらの検出メカニズムでも、DNS サービスディスカバリ設定に一致する証明書 SAN がない場合、クライアントの Envoy から見て、Envoys 間の接続は、次のエラーメッセージで失敗します。

TLS error: 268435581:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED

TLS 認証証明書

App Mesh では、TLS 認証を使用する場合、証明書の複数のソースがサポートされます。

AWS Private CA

証明書は、証明書を使用するメッシュエンドポイントと同じリージョンおよび AWS アカウントの ACM に保存する必要があります。CA AWS の証明書は同じアカウントにある必要はありませんが、メッシュエンドポイントと同じリージョンにある必要があります。をお持ちでない場合は AWS Private CA、証明書をリクエストする前に証明書を作成する必要があります。ACM AWS Private CA を使用している既存の証明書をリクエストする方法の詳細については、「プライベート証明書をリクエストする」を参照してください。証明書をパブリック証明書にすることはできません。

TLS クライアントポリシーに使用するプライベート CA は、ルートユーザー CA である必要があります。

からの証明書とCAを使用して仮想ノードを構成するには AWS Private CA、App Mesh を呼び出すために使用するプリンシパル（ユーザーやロールなど）に次のIAM権限が必要です。

  • リスナーの TLS 設定に追加する証明書では、プリンシパルに acm:DescribeCertificate のアクセス許可が必要です。

  • TLS クライアントポリシーで設定された CA の場合は、プリンシパルに acm-pca:DescribeCertificateAuthority のアクセス許可が必要です。

重要

CA を他のアカウントと共有すると、それらのアカウントに意図しない CA への特権が与えられる可能性があります。リソースベースのポリシーを使用して、CA から証明書を発行する必要のないアカウントに対しては acm-pca:DescribeCertificateAuthority と acm-pca:GetCertificateAuthorityCertificate のみへのアクセスに制限するようお勧めします。

これらのアクセス許可は、プリンシパルにアタッチされている既存の IAM ポリシーに追加するか、新しいプリンシパルとポリシーを作成してポリシーをプリンシパルにアタッチできます。詳細については、「IAM ポリシーの編集」、「IAM ポリシーの作成」、「IAM ID アクセス許可の追加」を参照してください。

注記

AWS Private CA 削除するまで、それぞれの操作には月額料金がかかります。また、毎月発行するプライベート証明書とエクスポートするプライベート証明書についても料金が発生します。詳細については、「AWS Certificate Manager 料金」を参照してください。

メッシュエンドポイントが表す Envoy プロキシのプロキシ認証を有効にする場合、使用する IAM ロールに、次の IAM アクセス許可を割り当てる必要があります。

  • 仮想ノードのリスナーに設定された証明書の場合、ロールには acm:ExportCertificate のアクセス許可が必要です。

  • TLS クライアントポリシーで設定されている CA の場合、ロールにはacm-pca:GetCertificateAuthorityCertificate のアクセス許可が必要です。

ファイルシステム

ファイルシステムを使用して Envoy に証明書を配信できます。これを行うには、証明書チェーンとこれに対応するシークレットキーをファイルパスで使用できるようにします。そうすれば、これらのリソースは Envoy サイドカープロキシから利用可能です。

Envoy Secret Discovery Service (SDS)

Envoy は、Secrets Discovery プロトコルを使用して、特定のエンドポイントから TLS 証明書などの機密情報を取得します。このプロトコルの詳細については、Envoy の SDS ドキュメントを参照してください。

App Mesh は、SDS (Secret Discovery Service) が証明書および証明書チェーンのソースとして機能する場合、プロキシに対してローカルな Unix ドメインソケットを使用して SDS エンドポイントとして機能するように Envoy プロキシを設定します。APPMESH_SDS_SOCKET_PATH 環境変数を使用して、このエンドポイントへのパスを設定できます。

重要

Unix ドメインソケットを使用した Local Secrets Discovery Service は、App Mesh Envoy プロキシのバージョン 1.15.1.0 以降でサポートされています。

App Mesh では、gRPC を使用して V2 SDS プロトコルがサポートされています。

SPIFFE ランタイム環境 (SPIRE) との統合

SPIFFE ランタイム環境 (SPIRE) などの既存のツールチェーンを含む、SDS API の任意のサイドカー実装を使用できます。SPIRE は、分散システムの複数のワークロード間で相互 TLS 認証をデプロイできるように設計されています。実行時にワークロードのアイデンティティを証明します。また、SPIRE は、ワークロード固有で一時的に使えて自動的にローテーションするキーと証明書をワークロードに直接送信します。

SPIRE エージェントを Envoy の SDS プロバイダーとして設定する必要があります。相互 TLS 認証を提供するために必要なキーマテリアルを Envoy に直接提供できるようにします。Envoy プロキシの横にあるサイドカーで SPIRE エージェントを実行します。エージェントは、必要に応じて一時的に使えるキーおよび証明書を再生成します。エージェントは、Envoy を証明し、Envoy が SPIRE エージェントによって公開される SDS サーバーに接続するときに、Envoy がどのサービスアイデンティティと CA 証明書を使用できるようにするかを決定します。

このプロセス中に、サービスアイデンティティ と CA 証明書がローテーションされ、更新情報が Envoy にストリーミングされます。Envoy は、その情報を中断やダウンタイムもなく、プライベートキーがファイルシステムに触れることなく、新しい接続にすぐに適用します。

TLS をネゴシエートするための App Mesh による Envoys の設定方法

App Mesh は、メッシュ内にある Envoys 間の通信の設定方法を決定する際に、クライアントとサーバーの両方のメッシュエンドポイント設定を使用します。

クライアントポリシーを使用する場合

クライアントポリシーで TLS の使用が適用され、クライアントポリシー内のポートの 1 つがサーバーのポリシーのポートと一致する場合、クライアントポリシーを使用してクライアントの TLS 検証コンテキストを設定します。例えば、仮想ゲートウェイのクライアントポリシーが仮想ノードのサーバーポリシーと一致する場合、TLS ネゴシエーションは、仮想ゲートウェイのクライアントポリシーで定義された設定を使用して、プロキシ間で試行されます。クライアントポリシーがサーバーのポリシーのポートと一致しない場合、サーバーポリシーの TLS 設定に応じて、プロキシ間の TLS がネゴシエートされる場合とそうでない場合があります。

クライアントポリシーを使用しない場合

クライアントがクライアントポリシーを設定していない場合、またはクライアントポリシーがサーバーのポートと一致しない場合、App Mesh はサーバーを使用して、クライアントから TLS をネゴシエートするかどうか、また、その方法を判断します。例えば、仮想ゲートウェイでクライアントポリシーが指定されておらず、仮想ノードが TLS 終了を設定していない場合、TLS はプロキシ間でネゴシエートされません。クライアントが一致するクライアントポリシーを指定しておらず、サーバーが TLS モード STRICT または PERMISSIVE で設定されている場合、プロキシは TLS をネゴシエートするように設定されます。TLS 終了時の証明書の提供方法に応じて、次の追加の動作が適用されます。

  • ACM 管理の TLS 証明書 — サーバーが ACM 管理された証明書を使用して TLS 終了を設定した場合、App Mesh は、TLS をネゴシエートし、証明書がチェーンアップするルートユーザー CA に対して証明書を検証するようにクライアントを自動的に設定します。

  • ファイルベースの TLS 証明書 — サーバーがプロキシのローカルファイルシステムからの証明書を使用して TLS 終了を設定すると、App Mesh は TLS をネゴシエートするようにクライアントを自動的に設定しますが、サーバーの証明書は検証されません。

サブジェクトの別名

オプションで、信頼するサブジェクトの別名 (SAN) のリストを指定することもできます。SAN は FQDN または URI 形式である必要があります。SAN が提供されている場合、Envoy は、提示された証明書のサブジェクトの別名がこのリストのいずれかの名前と一致することを確認します。

終端側のメッシュエンドポイントで SAN を指定しない場合、そのノードの Envoy プロキシはピアクライアント証明書の SAN を検証しません。発信元のメッシュエンドポイントで SAN を指定しない場合、終端側のエンドポイントによって提供される証明書の SAN は、メッシュエンドポイントのサービスディスカバリ設定と一致する必要があります。

詳細については、App Mesh の「TLS: 証明書の要件」を参照してください。

重要

TLS のクライアントポリシーが not enforced に設定されている場合にのみ、ワイルドカード SAN を使用できます。クライアント仮想ノードまたは仮想ゲートウェイのクライアントポリシーが TLS を適用するように構成されている場合、ワイルドカード SAN を受け入れることはできません。

暗号化の検証

TLS を有効にしたら、Envoy プロキシにクエリを送信して、通信が暗号化されていることを確認できます。Envoy プロキシは、TLS 通信が正常に機能しているかどうかを理解するのに役立つリソースの統計情報を出力します。例えば、Envoy プロキシは、指定されたメッシュエンドポイントに対して正常にネゴシエートした TLS ハンドシェイクの数に関する統計情報を記録します。次のコマンドを実行して、my-mesh-endpoint という名前のメッシュエンドポイントで成功した TLS ハンドシェイクの数を特定します。

curl -s 'http://my-mesh-endpoint.apps.local:9901/stats' | grep ssl.handshake

次の返された出力例では、メッシュエンドポイントに対して 3 つのハンドシェイクがあったため、通信は暗号化されています。

listener.0.0.0.0_15000.ssl.handshake: 3

Envoy プロキシは、TLS ネゴシエーションが失敗したときにも統計情報を送信します。メッシュエンドポイントに TLS エラーがあったかどうかを確認します。

curl -s 'http://my-mesh-endpoint.apps.local:9901/stats' | grep -e "ssl.*\(fail\|error\)"

返された出力例では、複数の統計情報でエラーがゼロだったため、TLS ネゴシエーションは成功しています。

listener.0.0.0.0_15000.ssl.connection_error: 0
listener.0.0.0.0_15000.ssl.fail_verify_cert_hash: 0
listener.0.0.0.0_15000.ssl.fail_verify_error: 0
listener.0.0.0.0_15000.ssl.fail_verify_no_cert: 0
listener.0.0.0.0_15000.ssl.ssl.fail_verify_san: 0

Envoy TLS 統計の詳細については、「Envoy リスナー統計情報」を参照してください。

証明書の更新

AWS Private CA

ACM を使用して証明書を更新すると、更新が完了してから35分以内に接続されているプロキシに更新された証明書が自動的に配信されます。マネージド型更新を使用して、有効期間の期限に近づいた証明書を自動的に更新するようお勧めします。詳細については、ユーザーガイドの「ACM の Amazon 発行証明書のマネージド更新」を参照してください。 AWS Certificate Manager

独自の証明書を使用する

ローカルファイルシステムからの証明書を使用する場合、Envoy は、証明書が変更されても自動的に再ロードしません。Envoy プロセスを再起動するか、再デプロイして、新しい証明書をロードできます。新しい証明書を別のファイルパスに配置し、そのファイルパスで仮想ノードまたはゲートウェイ設定を更新することもできます。

TLS 認証を使用するように Amazon ECS ワークロードを設定します。 AWS App Mesh

メッシュを設定すると、TLS 認証を使用できます。ワークロードに追加する Envoy プロキシサイドカーで証明書が使用可能であることを確認します。EBS ボリュームまたは EFS ボリュームを Envoy サイドカーにアタッチすることも、証明書を保存したり、 AWS Secrets Manager から取得することもできます。

  • ファイルベースの証明書のディストリビューションを使用する場合は、EBS ボリュームまたは EFS ボリュームを Envoy サイドカーにアタッチします。証明書とプライベートキーへのパスが、で設定されているパスと一致していることを確認してください。 AWS App Mesh

  • SDS ベースのディストリビューションを使用している場合は、証明書へのアクセス権を持つ Envoy の SDS API を実装するサイドカーを追加します。

注記

SPIRE は Amazon ECS ではサポートされません。

TLS 認証を使用するように Kubernetes ワークロードを設定します。 AWS App Mesh

AWS App Mesh Controller for Kubernetes を構成して、仮想ノードと仮想ゲートウェイサービスのバックエンドとリスナーの TLS 認証を有効にできます。ワークロードに追加する Envoy プロキシサイドカーで証明書が使用可能であることを確認します。相互 TLS 認証のチュートリアルセクションで、各ディストリビューションタイプの例を確認できます。

  • ファイルベースの証明書のディストリビューションを使用する場合は、EBS ボリュームまたは EFS ボリュームを Envoy サイドカーにアタッチします。証明書とシークレットキーへパスが、コントローラーで設定されているパスと一致していることを確認します。または、ファイルシステム上にマウントされている Kubernetes Secret を使用することもできます。

  • SDS ベースのディストリビューションを使用する場合は、Envoy の SDS API を実装するノードローカル SDS プロバイダーを設定する必要があります。Envoy は UDS を介して到達します。EKS コントローラーで SDS ベースの mTLS サポートを有効にするには、フラグを設定し、enable-sdsフラグを介してローカル SDS AppMesh true プロバイダーのコントローラーへの UDS パスを指定します。sds-uds-pathHelm を使用する場合は、コントローラーインストールの一部としてこれらを設定します。

    --set sds.enabled=true
注記

Fargate モードで Amazon Elastic Kubernetes Service (Amazon EKS) を使用している場合は、SPIRE を使用して証明書を配信することはできません。