cert-managerと Let's Encrypt を使用して Amazon EKS のアプリケーションのエンドツーエンド暗号化を設定 - AWS 規範ガイダンス

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

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 エンドツーエンド暗号化」 のサンプルアプリケーションとコードを提供し、マイクロサービスが Amazon EKS でエンドツーエンド暗号化を使用してどのように実行されるかを示します。このパターンのアプローチでは、Kubernetes のアドオンである「cert-manager」 を使用し、認証局 (CA) として 「Let's Encrypt」 を使用します。Let's Encrypt は費用対効果の高い証明書管理ソリューションで、90 日間有効な証明書を無料で提供しています。Cert-manager は、新しいマイクロサービスが Amazon EKS にデプロイされたときに、証明書のオンデマンドプロビジョニングとローテーションを自動化します。 

対象者

このパターンは、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.jsontrustpolicy.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 のマイクロサービスで証明書を使用する方法のみを示しています。 

アーキテクチャ

次の図表は、このパターンのアプリケーションのワークフローとアーキテクチャコンポーネントを示しています。

cert-manager と Let's Encrypt を使用して Amazon EKS 上のアプリケーションの暗号化を設定するワークフロー。

この図表は、次のワークフローを示しています:

  1. クライアントは DNS 名へのアプリケーションへのアクセスリクエストを送信します。

  2. Route 53 レコードは Network Load Balancer の CNAMEです。

  3. Network Load Balancer は、TLS リスナーで設定された NGINX Ingress コントローラーにリクエストを転送します。NGINX Ingress コントローラーと Network Load Balancer 間の通信は HTTPS プロトコルに従います。

  4. NGINX Ingress Controller は、アプリケーションサービスへのクライアントのリクエストに基づいてパスベースのルーティングを実行します。

  5. アプリケーションサービスはリクエストをアプリケーションポッドに転送します。このアプリケーションは、シークレットを呼び出すことで。同じ証明書を使用するように設計されています。

  6. ポッドは 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 レコードを作成し、そのレコードを _acme-challenge.<YOURDOMAIN> に保存します。次に、Let's Encrypt は DNS にそのレコードを問い合わせます。一致するものが見つかったら、証明書の発行に進むことができます。

AWS DevOps
タスク説明必要なスキル

cert-manager 用の IAM ポリシーを作成します。

ユーザーが Route 53 ドメインを所有していることを検証する権限を cert-manager に提供するには、IAM ポリシーが必要です。policy.json のサンプル IAM ポリシーが、複製されたGitHub「 Amazon EKS リポジトリのエンドツーエンドの暗号化」リポジトリの 1-IAMRole ディレクトリにあります。

次の AWS CLI コマンドを使用して、IAM ポリシーを作成します。

aws iam create-policy \ --policy-name PolicyForCertManager \ --policy-document file://policy.json
AWS DevOps

cert-managerの IAM ロールを作成します。

IAM ポリシーを作成したら、IAM ロールを作成する必要があります。trustpolicy.json サンプル IAM ロールが 1-IAMRole ディレクトリに提供されます。

IAM ロールを作成するには、次のコマンドをAWS CLIに入力します。

aws iam create-role \ --role-name RoleForCertManager \ --assume-role-policy-document file://trustpolicy.json
AWS DevOps

ロールへのポリシーの付与

AWS CLI に以下のコマンドを入力して、 IAM ロールにIAMポリシーをアタッチします。AWS_ACCOUNT_ID を自分の AWS アカウントのID に置き換えます。

aws iam attach-role-policy \ --policy-arn arn:aws:iam::AWS_ACCOUNT_ID:policy/PolicyForCertManager \ --role-name RoleForCertManager
AWS DevOps
タスク説明必要なスキル

NGINX Ingress コントローラーをデプロイします。

Helm を使用する nginx-ingress の最新バージョンをインストールします。デプロイする前に、要件に応じて nginx-ingress の設定を変更できます。このパターンでは、5-Nginx-Ingress-Controller ディレクトリの使用可能の注釈付き、内部向けのNetwork Load Balancer を使用します。 

5-Nginx-Ingress-Controller ディレクトリから次の Helm コマンドを実行して、 NGINX Ingress コントローラーをインストールします。

helm install test-nginx nginx-stable/nginx-ingress  -f  5-Nginx-Ingress-Controller/values_internal_nlb.yaml

AWS DevOps

コントローラーがインストールされていることを確認します。

helm list コマンドを入力します。出力では NGINX Ingress コントローラーがインストールされていることが表示されるはずです。

AWS DevOps

Route 53 A レコードを作成します。

A レコードは NGINX Ingress コントローラーによって作成された Network Load Balancer を指します。

  1. Network Load Balancerの DNS 名を取得します。手順については、「ELB ロードバランサーの DNS 名の取得」 を参照してください。

  2. Amazon Route 53 コンソールで、ホストゾーンを選択します。

  3. レコードを作成するパブリックホストゾーンを選択し、レコードの作成 を選択します。

  4. レポートの [Name](名前) を入力します。 

  5. [レコードタイプ] で、[A — IPv4 アドレスと一部の AWS リソースにトラフィックをルーティングする] を選択します。  

  6. Alias を有効にします。

  7. トラフィックのルーティング先]で、次の操作を行います:

    1. Network Load Balancer へのエイリアス] を選択します。

    2. Network Load Balancer がデプロイされている AWS リージョンを選択します。

    3. Network Load Balancer の DNS 名を入力します。

  8. [レコードを作成] を選択します。

AWS DevOps
タスク説明必要なスキル

NGINX 仮想サーバーをデプロイします。

NGINX VirtualServer リソースは、イングレスリソースの代替となるロードバランシング設定です。NGINX VirtualServer リソースを作成するための設定は、6-Nginx-Virtual-Server ディレクトリの nginx_virtualserver.yaml のファイルで利用可能です。NGINX VirtualServer リソースを作成するには、kubectl に以下のコマンドを入力します。

kubectl apply -f  nginx_virtualserver.yaml

重要

ファイル内のアプリケーションドメイン名、証明書シークレット、およびアプリケーションサービス名を必ず更新してくださいnginx_virtualserver.yaml

AWS DevOps

NGINX 仮想サーバーが作成されていることを確認します。

kubectl にある以下のコマンドを入力して、NGINX VirtualServer リソースが正常に作成されたことを確認します。

kubectl get virtualserver

注記

Host 列がアプリケーションのドメイン名と一致することを確認します。

AWS DevOps

TLS を有効にして NGINX ウェブサーバーをデプロイします。

このパターンでは、TLS が有効になっている NGINX Web サーバーを、エンドツーエンドの暗号化をテストするためのアプリケーションとして使用します。テストアプリケーションのデプロイに必要な設定ファイルは、demo-webserver のディレクトリに使用可能です。 

アプリケーションのテストを行うには、次のコマンドをkubectl に入力します。

kubectl apply -f nginx-tls-ap.yaml

AWS DevOps

テストアプリケーションリソースが作成されたことを確認します。

次のコマンドを kubectl に入力して、テストアプリケーションに必要なリソースが作成されていることを確認します

  • kubectl get deployments

    注記

    Ready 列と Available列を検証します。

  • kubectl get pods | grep -i example-deploy

    注記

    ポッドは running状態である必要があります。

  • kubectl get configmap 

  • kubectl get svc 

AWS DevOps

アプリケーションを検証します。

  1. <application-domain-name> を 先ほど作成したRoute53 DNS 名に置き換えて、次のコマンドを入力します。

    curl --verbose https://<application-domain-name>

  2. アプリケーションにアクセスできることを確認します。

AWS DevOps

関連リソース

AWS リソース

その他のリソース