翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # Transport Layer Security (TLS) **重要** サポート終了通知: 2026 年 9 月 30 日、 AWS はサポートを終了します AWS App Mesh。2026 年 9 月 30 日以降、 AWS App Mesh コンソールまたは AWS App Mesh リソースにアクセスできなくなります。詳細については、このブログ記事[「 から Amazon ECS Service Connect AWS App Mesh への移行](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect)」を参照してください。 App Mesh では、Transport Layer Security (TLS) は、[仮想ノード](virtual_nodes.md) や [仮想ゲートウェイ](virtual_gateways.md) などのメッシュエンドポイントによって 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 プロキシの認可](proxy-authorization.md) は、メッシュエンドポイントで表されるデプロイ済みの Envoy プロキシで有効にする必要があります。プロキシ認可を有効にする場合は、暗号化を有効にするメッシュエンドポイントのみへのアクセスに制限するようお勧めします。 ## 証明書の要件 証明書のサブジェクト代替名 (SAN) の 1 つが、メッシュエンドポイントによって表される実際のサービスの検出方法に応じて、特定の基準に一致する必要があります。 + **DNS** — 証明書 SAN の 1 つが、DNS サービスディスカバリ設定で指定された値と一致する必要があります。`mesh-endpoint.apps.local` というサービスディスカバリ名を持つアプリケーションの場合、その名前と一致する証明書を作成するか、ワイルドカード `*.apps.local` を使用して証明書を作成することができます。 + **AWS Cloud Map** – 証明書 SANs の 1 つは、 形式を使用して AWS Cloud Map サービス検出設定で指定された値と一致する必要があります`service-name.namespace-name`。serviceName `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、証明書をリクエストする前に[作成](https://docs.aws.amazon.com/acm-pca/latest/userguide/PcaCreateCa.html)する必要があります。ACM AWS Private CA を使用して既存の から証明書をリクエストする方法の詳細については、[「プライベート証明書をリクエストする](https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-request-private.html)」を参照してください。証明書をパブリック証明書にすることはできません。 TLS クライアントポリシーに使用するプライベート CA は、ルートユーザー CA である必要があります。 証明書と CAs を使用して仮想ノードを設定するには 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 ポリシーの編集](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-edit.html)」、「[IAM ポリシーの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html)」、「[IAM ID アクセス許可の追加](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html#add-policies-console)」を参照してください。 各 のオペレーションは、削除する AWS Private CA まで月額料金が発生します。また、毎月発行するプライベート証明書とエクスポートするプライベート証明書についても料金が発生します。詳細については、[AWS Certificate Manager の料金](https://aws.amazon.com//certificate-manager/pricing/)を参照してください。 メッシュエンドポイントが表す Envoy Proxy の[プロキシ認可](proxy-authorization.md)を有効にする場合、使用する IAM ロールに次の IAM アクセス許可を割り当てる必要があります。 + 仮想ノードのリスナーに設定された証明書の場合、ロールには `acm:ExportCertificate` のアクセス許可が必要です。 + TLS クライアントポリシーで設定されている CA の場合、ロールには`acm-pca:GetCertificateAuthorityCertificate` のアクセス許可が必要です。 **ファイルシステム** ファイルシステムを使用して Envoy に証明書を配信できます。これを行うには、証明書チェーンとこれに対応するシークレットキーをファイルパスで使用できるようにします。そうすれば、これらのリソースは Envoy サイドカープロキシから利用可能です。 **Envoy Secret Discovery Service (SDS)** Envoy は、Secrets Discovery プロトコルを使用して、特定のエンドポイントから TLS 証明書などの機密情報を取得します。このプロトコルの詳細については、Envoy の [SDS ドキュメント](https://www.envoyproxy.io/docs/envoy/latest/configuration/security/secret)を参照してください。 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)](https://github.com/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: 証明書の要件](https://docs.aws.amazon.com/app-mesh/latest/userguide/tls.html#virtual-node-tls-prerequisites)」を参照してください。 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 リスナー統計情報](https://www.envoyproxy.io/docs/envoy/latest/configuration/listeners/stats)」を参照してください。 ## 証明書の更新 **AWS Private CA** ACM を使用して証明書を更新すると、更新が完了してから35分以内に接続されているプロキシに更新された証明書が自動的に配信されます。マネージド型更新を使用して、有効期間の期限に近づいた証明書を自動的に更新するようお勧めします。詳細については、[「 ユーザーガイド」の「ACM の Amazon 発行証明書のマネージド更新](https://docs.aws.amazon.com/acm/latest/userguide/managed-renewal.html)」を参照してください。 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 認証の[チュートリアル](https://docs.aws.amazon.com/app-mesh/latest/userguide/mutual-tls.html#mtls-walkthrough)セクションで、各ディストリビューションタイプの例を確認できます。 + ファイルベースの証明書のディストリビューションを使用する場合は、EBS ボリュームまたは EFS ボリュームを Envoy サイドカーにアタッチします。証明書とシークレットキーへパスが、コントローラーで設定されているパスと一致していることを確認します。または、ファイルシステム上にマウントされている Kubernetes Secret を使用することもできます。 + SDS ベースのディストリビューションを使用する場合は、Envoy の SDS API を実装するノードローカル SDS プロバイダーを設定する必要があります。Envoy は UDS を介して到達します。EKS App Mesh コントローラーで SDS ベースの mTLS サポートを有効にするには、`enable-sds` フラグを `true` に設定し、ローカル SDS プロバイダーの UDS パスを `sds-uds-path` フラグを介してコントローラーに提供します。Helm を使用する場合は、コントローラーインストールの一部としてこれらを設定します。 ``` --set sds.enabled=true ``` **注記** Fargate モードで Amazon Elastic Kubernetes Service (Amazon EKS) を使用している場合は、SPIRE を使用して証明書を配信することはできません。