Transport Layer Security (TLS） - AWS App Mesh
証明書の要件TLS 認証証明書App Mesh が交渉する Envoys を設定する方法 TLS暗号化の検証証明書の更新でTLS認証を使用するように Amazon ECSワークロードを設定する AWS App MeshでTLS認証を使用するように Kubernetes ワークロードを設定する AWS App Mesh

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

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 への移行」を参照してください。

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 プロキシで有効にする必要があります。プロキシ認可を有効にする場合は、暗号化を有効にするメッシュエンドポイントのみへのアクセスに制限するようお勧めします。

証明書の要件

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

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

  • AWS Cloud Map – 証明書の 1 つは、 形式を使用して AWS Cloud Map サービス検出設定で指定された値と一致するSANs必要がありますservice-name.namespace-name。 AWS Cloud Map のサービス検出設定が serviceNamemesh-endpointおよび のアプリケーションの場合 namespaceName apps.local、名前 に一致する証明書mesh-endpoint.apps.local、またはワイルドカードを持つ証明書を作成できます。 *.apps.local.

どちらの検出メカニズムでも、どの証明書もDNSサービス検出設定SANsと一致しない場合、クライアント Envoy からわかるように、Envoys 間の接続は失敗し、次のエラーメッセージが表示されます。

TLS error: 268435581:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED

TLS 認証証明書

App Mesh は、TLS認証を使用する際に複数の証明書ソースをサポートしています。

AWS Private CA

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

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

App Mesh の呼び出しに使用するプリンシパル (ユーザーやロールなど) には AWS Private CA、 CAsからの証明書と を使用して仮想ノードを設定するには、次のIAMアクセス許可が必要です。

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

  • TLS クライアントポリシーCAsに設定されている については、プリンシパルに acm-pca:DescribeCertificateAuthority許可が必要です。

重要

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

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

注記

削除 AWS Private CA されるまで、各 のオペレーションに対して月額料金が発生します。また、毎月発行するプライベート証明書とエクスポートするプライベート証明書についても料金が発生します。詳細については、AWS Certificate Manager 料金を参照してください。

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

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

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

ファイルシステム

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

Envoy's Secret Discovery Service (SDS）

Envoy は、Secrets Discovery プロトコルを通じて、特定のエンドポイントからTLS証明書などのシークレットを取得します。このプロトコルの詳細については、「Envoy のSDSドキュメント」を参照してください。

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

重要

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

App Mesh は、g を使用して V2 SDSプロトコルをサポートしますRPC。

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

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

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

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

App Mesh が交渉する Envoys を設定する方法 TLS

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、サーバーの証明書は検証されません。

サブジェクトの別名

必要に応じて、信頼するサブジェクト代替名 (SANs) のリストを指定できます。SANs は FQDNまたは URI形式である必要があります。が指定されている場合、Envoy SANsは提示された証明書のサブジェクト代替名が、このリストの名前のいずれかと一致することを確認します。

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

詳細については、「App Mesh TLS: Certificate requirements」を参照してください。

重要

のSANsクライアントポリシーTLSが に設定されている場合にのみ、ワイルドカードを使用できますnot enforced。クライアント仮想ノードまたは仮想ゲートウェイのクライアントポリシーが を強制するように設定されている場合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 Listener Statistics」を参照してください。

証明書の更新

AWS Private CA

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

独自の証明書を使用する

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

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

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

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

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

注記

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

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

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

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

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

    --set sds.enabled=true
注記

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