翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
cert-managerと Let's Encrypt を使用して Amazon EKS のアプリケーションのエンドツーエンド暗号化を設定
作成者: Mahendra Revanasiddappa (AWS) と Vasanth Jeyaraj (AWS)
概要
エンドツーエンド暗号化の実装は複雑で、マイクロサービスアーキテクチャ内の各アセットの証明書を管理する必要があります。Amazon Web Services (AWS) ネットワークの端にあるTransport Layer Security (TLS) 接続は、Network Load Balancer または Amazon API Gateway を使用して終了できますが、一部の組織ではエンドツーエンドの暗号化が必要です。
このパターンでは、入力に NGINX Ingress コントローラーを使用します。これは、Kubernetes Ingress を作成する場合、イングレスリソースがNetwork Load Balancer を使用するためです。Network Load Balancer は、クライアント証明書のアップロードを許可しません。したがって、Kubernetes Ingress では相互TLSを実現できません。
このパターンは、アプリケーション内のすべてのマイクロサービス間の相互認証を必要とする組織を対象としています。相互 TLS は、ユーザー名やパスワードを管理する負担を軽減し、すぐに使えるセキュリティフレームワークを使用することもできます。このパターンのアプローチは、接続されているデバイスが多数ある組織や、厳格なセキュリティガイドラインに準拠する必要がある場合にも適合します。
このパターンは、Amazon Elastic Kubernetes Service (Amazon EKS) 上で実行されるアプリケーションにエンドツーエンドの暗号化を実装することで、組織のセキュリティ体制強化に役立ちます。このパターンでは、「Amazon EKS リポジトリの GitHub エンドツーエンド暗号化
対象者
このパターンは、Kubernetes、TLS、Amazon Route 53、およびドメインネームシステム (DNS) の使用経験があるユーザーに推奨されます。
前提条件と制限
前提条件
アクティブな AWS アカウント。
既存の アマゾン EKS クラスター。
macOS、Linux、または Windows にインストールされ、設定された AWS コマンドラインインターフェイス (AWS CLI) バージョン 1.7 以降。
Amazon EKS クラスターにアクセスするために、インストールおよび設定された
kubectl
コマンドラインユーティリティ。これについての詳細は、Amazon EKS ドキュメントの「kubectl のインストール」 を参照してください。アプリケーションをテストするための既存のアプリケーション名です。これについての詳細は、Amazon Route 53 デベロッパーガイドの「 Amazon Route 53 を使用したドメイン名の登録」を参照してください。
ローカルマシンにインストールされている最新の 「Helm」 バージョン。これについての詳細は、Amazon EKS ドキュメントの「Amazon EKS での Helm の使用」 と GitHub 「Helm
」 リポジトリを参照してください。 ローカルマシンに複製された GitHub 「Amazon EKS リポジトリの エンドツーエンド暗号化
」。 複製された GitHub 「Amazon EKS リポジトリのエンドツーエンド暗号化
」から policy.json
とtrustpolicy.json
のファイルの以下の値を置き換えます:<account number>
— ソリューションをデプロイするアカウントの AWS アカウント ID と置き換えます。<zone id>
— ドメイン名の Route 53 ゾーン ID に置き換えます。<node_group_role>
— Amazon EKS ノードに関連付けられている AWS 識別とアクセス管理(IAM) ロールの名前に置き換えます。<namespace>
— NGINX Ingress コントローラーとサンプルアプリケーションをデプロイする Kubernetes 名前空間に置き換えます。<application-domain-name>
— Route 53 の DNS ドメイン名に置き換えます。
機能制限
このパターンでは、証明のローテーション方法を説明するものではなく、Amazon EKS のマイクロサービスで証明書を使用する方法のみを示しています。
アーキテクチャ
次の図表は、このパターンのアプリケーションのワークフローとアーキテクチャコンポーネントを示しています。

この図表は、次のワークフローを示しています:
クライアントは DNS 名へのアプリケーションへのアクセスリクエストを送信します。
Route 53 レコードは Network Load Balancer の CNAMEです。
Network Load Balancer は、TLS リスナーで設定された NGINX Ingress コントローラーにリクエストを転送します。NGINX Ingress コントローラーと Network Load Balancer 間の通信は HTTPS プロトコルに従います。
NGINX Ingress Controller は、アプリケーションサービスへのクライアントのリクエストに基づいてパスベースのルーティングを実行します。
アプリケーションサービスはリクエストをアプリケーションポッドに転送します。このアプリケーションは、シークレットを呼び出すことで。同じ証明書を使用するように設計されています。
ポッドは cert-managerの証明書を使用してサンプルアプリケーションを実行します。NGINX Ingress コントローラーとポッド間の通信には HTTPS が使用されます。
注記Cert-manager は独自の名前空間で実行されます。Kubernetes クラスターロールを使用して、証明書を特定の名前空間のシークレットとしてプロビジョニングします。これらの名前空間はアプリケーションポッドと NGINX Ingress コントローラーにアタッチできます。 |
ツール
AWS サービス
Amazon Elastic Kubernetes Service (Amazon EKS) は、AWS で Kubernetes を簡単に実行できるようにするマネージド型サービスです。ユーザー独自の Kubernetes コントロールプレーンまたはノードをインストール、操作、維持する必要はありません。
Elastic Load Balancing は、受信したトラフィックを複数のターゲット、コンテナ、IPアドレスに自動的に分散します。
「AWS Identity and Access Management (IAM)」は、AWS リソースへのアクセスを安全に管理し、誰が認証され、使用する権限があるかを制御するのに役立ちます。
Amazon Route 53 は、高可用性でスケーラブルな DNS Web サービスです。
その他のツール
「cert-manager
」 は Kubernetes のアドオンで、証明書をリクエストして Kubernetes コンテナに配布し、証明書の更新を自動化します。 「NGINX Ingress Controller
」は、Kubernetes およびコンテナ化された環境におけるクラウドネイティブアプリケーション向けのトラフィック管理ソリューションです。
エピック
タスク | 説明 | 必要なスキル |
---|---|---|
Route 53 にドメインのパブリックホストゾーンを作成します。 | AWS マネジメントコンソールにサインインし、Amazon Route 53 コンソールを開き、[ホストゾーン]を選択し、[ホストゾーンの作成]を選択します。パブリックホストゾーンを作成し、ゾーン ID を記録します。これについての詳細は、Amazon Route 53 ドキュメントの「公開ホストゾーンの作成」を参照してください。 注記ACME DNS01 は DNS プロバイダーを使用して、cert-manager が証明書を発行するためのチャレンジを投稿します。このチャレンジでは、ドメイン名の TXT レコードに特定の値を入力して、そのドメイン名の DNS を管理していることを証明するよう求められます。Let's Encrypt が ACME クライアントにトークンを渡した後、クライアントはそのトークンとアカウントキーから得た TXT レコードを作成し、そのレコードを | AWS DevOps |
タスク | 説明 | 必要なスキル |
---|---|---|
cert-manager 用の IAM ポリシーを作成します。 | ユーザーが Route 53 ドメインを所有していることを検証する権限を cert-manager に提供するには、IAM ポリシーが必要です。 次の AWS CLI コマンドを使用して、IAM ポリシーを作成します。
| AWS DevOps |
cert-managerの IAM ロールを作成します。 | IAM ポリシーを作成したら、IAM ロールを作成する必要があります。 IAM ロールを作成するには、次のコマンドをAWS CLIに入力します。
| AWS DevOps |
ロールへのポリシーの付与 | AWS CLI に以下のコマンドを入力して、 IAM ロールにIAMポリシーをアタッチします。
| AWS DevOps |
タスク | 説明 | 必要なスキル |
---|---|---|
NGINX Ingress コントローラーをデプロイします。 | Helm を使用する
| AWS DevOps |
コントローラーがインストールされていることを確認します。 |
| AWS DevOps |
Route 53 A レコードを作成します。 | A レコードは NGINX Ingress コントローラーによって作成された Network Load Balancer を指します。
| AWS DevOps |
タスク | 説明 | 必要なスキル |
---|---|---|
NGINX 仮想サーバーをデプロイします。 | NGINX VirtualServer リソースは、イングレスリソースの代替となるロードバランシング設定です。NGINX VirtualServer リソースを作成するための設定は、
重要ファイル内のアプリケーションドメイン名、証明書シークレット、およびアプリケーションサービス名を必ず更新してください | AWS DevOps |
NGINX 仮想サーバーが作成されていることを確認します。 |
注記
| AWS DevOps |
TLS を有効にして NGINX ウェブサーバーをデプロイします。 | このパターンでは、TLS が有効になっている NGINX Web サーバーを、エンドツーエンドの暗号化をテストするためのアプリケーションとして使用します。テストアプリケーションのデプロイに必要な設定ファイルは、 アプリケーションのテストを行うには、次のコマンドを
| AWS DevOps |
テストアプリケーションリソースが作成されたことを確認します。 | 次のコマンドを
| AWS DevOps |
アプリケーションを検証します。 |
| AWS DevOps |
関連リソース
「AWS リソース」
「Amazon Route 53 コンソールを使用したレコードの作成」 (Amazon Route 53 ドキュメント)
「Amazon EKS の NGINX イングレスコントローラーでのNetwork Load Balancer の使用
」 (AWS ブログ投稿)
その他のリソース
「Route 53
」 (cert-managerドキュメント) 「DNS01 チャレンジプロバイダーの設定
」 (cert-managerドキュメント) 「Let’s Encrypt DNS チャレンジ
」(Let’s Encrypt ドキュメント)