Transport Layer Security (TLS)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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