Transport Layer Security (TLS) - 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 つが、service-name.namespace-name の形式を使用して AWS Cloud Map サービスディスカバリ設定で提供された値と一致する必要があります。serviceName mesh-endpoint および namespaceName apps.local の AWS Cloud Map サービスディスカバリ設定を持つアプリケーションの場合、名前 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、それならあなたはしなければならない1 つ作成証明書をリクエストする前に。既存からの証明書のリクエストの詳細についてはAWS Private CAACM を使用する場合は、を参照してくださいプライベート証明書のリクエスト。証明書をパブリック証明書にすることはできません。

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

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

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

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

重要

CA を他のアカウントと共有すると、それらのアカウントに意図しない CA への特権が与えられる可能性があります。リソースベースのポリシーを使用して、CA から証明書を発行する必要のないアカウントに対しては acm-pca:DescribeCertificateAuthorityacm-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: 証明書の要件

重要

ワイルドカード SAN を使用できるのは、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 リスナー統計情報」を参照してください。

証明書の更新

AWS Private CA

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

独自の証明書を使用する

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

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

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

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

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

注記

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

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

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

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

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

    --set sds.enabled=true
注記

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