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）

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 間の接続は失敗し、クライアント Envoy から次のエラーメッセージが表示されます。

TLS error: 268435581:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED

TLS 認証証明書

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

AWS Private CA

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

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

証明書と CAsからの仮想ノードを設定するには AWS Private CA、App Mesh の呼び出しに使用するプリンシパル (ユーザーやロールなど) に次の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 の 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 ランタイム環境 (SPIRE） SDS などの既存のツールチェーンを含むAPI、 の任意のサイドカー実装を使用できます。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 は証明書が連鎖するルートユーザー CA に対して証明書をネゴシエートTLSおよび検証するようにクライアントを自動的に設定します。

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

サブジェクトの別名

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

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

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

重要

ワイルドカードは、 のクライアントポリシーTLSが に設定されているSANs場合にのみ使用できます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 リスナー統計」を参照してください。

証明書の更新

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 から証明書を保存および取得することもできます。

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

    --set sds.enabled=true
注記

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