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

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

cert-manager と Let's Encrypt EKSを使用して Amazon のアプリケーションの end-to-end 暗号化を設定する

作成者: Mahendra Revanasiddappa (AWS) と Vasanth Jeyaraj (AWS)

コードリポジトリ: Amazon での E nd-to-end 暗号化 EKS

環境:PoC またはパイロット

テクノロジー: DevOps、コンテナとマイクロサービス、セキュリティ、アイデンティティ、コンプライアンス

ワークロード:その他すべてのワークロード

AWS サービス: Amazon EKS、Amazon Route 53

[概要]

end-to-end 暗号化の実装は複雑になる場合があり、マイクロサービスアーキテクチャの各アセットの証明書を管理する必要があります。Network Load Balancer または Amazon API Gateway を使用して、Amazon Web Services (TLS) ネットワークのエッジで Transport Layer Security (AWS) 接続を終了できますが、一部の組織では end-to-end 暗号化が必要です。

このパターンではNGINX、入力に Ingress Controller を使用します。これは、Kubernetes Ingress を作成する場合、イングレスリソースがNetwork Load Balancer を使用するためです。Network Load Balancer は、クライアント証明書のアップロードを許可しません。したがって、Kubernetes イングレスTLSとの相互通信を実現することはできません。

このパターンは、アプリケーション内のすべてのマイクロサービス間の相互認証を必要とする組織を対象としています。相互にユーザー名またはパスワードを維持する負担TLSを軽減し、ターンキーセキュリティフレームワークを使用することもできます。このパターンのアプローチは、接続されているデバイスが多数ある組織や、厳格なセキュリティガイドラインに準拠する必要がある場合にも適合します。

このパターンは、Amazon Elastic Kubernetes Service (Amazon ) で実行されているアプリケーションの end-to-end 暗号化を実装することで、組織のセキュリティ体制を強化するのに役立ちますEKS。このパターンは、 GitHub Amazon リポジトリの E nd-to-end 暗号化EKSのサンプルアプリケーションとコードを提供し、マイクロサービスが Amazon での end-to-end 暗号化でどのように実行されるかを示しますEKS。このパターンのアプローチでは、Kubernetes のアドオンである「cert-manager」 を使用し、認証局 (CA) として 「Let's Encrypt」 を使用します。Let's Encrypt は費用対効果の高い証明書管理ソリューションで、90 日間有効な証明書を無料で提供しています。Cert-manager は、新しいマイクロサービスが Amazon にデプロイされると、証明書のオンデマンドプロビジョニングとローテーションを自動化しますEKS。 

対象者

このパターンは、Kubernetes、、Amazon Route 53TLS、ドメインネームシステム () の使用経験があるユーザーに推奨されますDNS。

前提条件と制限

前提条件

  • アクティブ AWS アカウント。

  • 既存の Amazon EKSクラスター。

  • AWS コマンドラインインターフェイス (AWS CLI) バージョン 1.7 以降で、macOS 、Linux、または Windows にインストールおよび設定されている。

  • Amazon EKSクラスターにアクセスするようにインストールおよび設定されたkubectlコマンドラインユーティリティ。詳細については、Amazon ドキュメントの「kubectl のインストール」を参照してください。 EKS

  • アプリケーションをテストするための既存のDNS名前。これについての詳細は、Amazon Route 53 デベロッパーガイドの「 Amazon Route 53 を使用したドメイン名の登録」を参照してください。 

  • ローカルマシンにインストールされている最新の 「Helm」 バージョン。詳細については、Amazon ドキュメントの「Amazon での Helm の使用EKS」および「 GitHub Helm リポジトリ」を参照してください。 EKS 

  • ローカルマシンに複製された GitHub Amazon リポジトリの E nd-to-end 暗号化EKS。 

  • Amazon リポジトリのクローン GitHub E nd-to-end 暗号化EKSから policy.jsonおよび trustpolicy.json ファイル内の次の値を置き換えます。

    • <account number> – を、ソリューションをデプロイするアカウントのアカウント AWS ID に置き換えます。 

    • <zone id> — ドメイン名の Route 53 ゾーン ID に置き換えます。 

    • <node_group_role> – を Amazon EKSノードに関連付けられた AWS Identity and Access Management (IAM) ロールの名前に置き換えます。

    • <namespace> – Ingress Controller とサンプルアプリケーションをデプロイする Kubernetes NGINX 名前空間に置き換えます。

    • <application-domain-name> — Route 53 のDNSドメイン名に置き換えます。

機能制限

  • このパターンでは、証明書をローテーションする方法を説明しておらず、Amazon のマイクロサービスで証明書を使用する方法のみを示しますEKS。 

アーキテクチャ

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

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

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

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

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

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

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

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

  6. ポッドは cert-managerの証明書を使用してサンプルアプリケーションを実行します。Ingress Controller NGINX とポッド間の通信では、 を使用しますHTTPS。

: cert-managerはその独自の名前空間で実行されます。Kubernetes クラスターロールを使用して、証明書を特定の名前空間のシークレットとしてプロビジョニングします。これらの名前空間は、アプリケーションポッドと Ingress Controller NGINX にアタッチできます。

ツール

AWS サービス

  • Amazon Elastic Kubernetes Service (Amazon EKS) は、独自の Kubernetes コントロールプレーンまたはノードをインストール、運用、保守AWSすることなく、 で Kubernetes を実行するために使用できるマネージドサービスです。

  • Elastic Load Balancing は、受信したトラフィックを複数のターゲット、コンテナ、IPアドレスに自動的に分散します。

  • AWS Identity and Access Management (IAM) は、誰を認証し、誰に使用を認可するかを制御することで、AWSリソースへのアクセスを安全に管理するのに役立ちます。

  • Amazon Route 53 は、可用性が高くスケーラブルなDNSウェブサービスです。

その他のツール

  • cert-manager」 は Kubernetes のアドオンで、証明書をリクエストして Kubernetes コンテナに配布し、証明書の更新を自動化します。

  • NGINX Ingress Controller は、Kubernetes およびコンテナ化された環境でのクラウドネイティブアプリケーション向けのトラフィック管理ソリューションです。

エピック

タスク説明必要なスキル

Route 53 にドメインのパブリックホストゾーンを作成します。

AWS マネジメントコンソールにサインインし、Amazon Route 53 コンソールを開き、ホストゾーン を選択し、ホストゾーンの作成 を選択します。パブリックホストゾーンを作成し、ゾーン ID を記録します。これについての詳細は、Amazon Route 53 ドキュメントの「公開ホストゾーンの作成」を参照してください。

: DNS01 ACME は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 リポジトリのクローン E nd-to-end 暗号化EKS1-IAMRole ディレクトリで提供されます。

で次のコマンドAWSCLIを入力して、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 ディレクトリで提供されます。

で次のコマンドAWSCLIを入力して、IAMロールを作成します。

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

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

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

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

Ingress Controller NGINX をデプロイします。

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

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

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

AWS DevOps

Ingress Controller NGINX がインストールされていることを確認します。

helm list コマンドを入力します。出力には、Ingress Controller NGINX がインストールされていることが示されます。

AWS DevOps

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

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

  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 VirtualServer。

NGINX VirtualServer リソースは、イングレスリソースの代替となる負荷分散設定です。NGINX VirtualServer リソースを作成する設定は、 6-Nginx-Virtual-Server ディレクトリの nginx_virtualserver.yaml ファイルで使用できます。で次のコマンドkubectlを入力して、 NGINX VirtualServer リソースを作成します。

kubectl apply -f  nginx_virtualserver.yaml

重要: nginx_virtualserver.yaml ファイルのアプリケーションドメイン名、証明書シークレット、アプリケーションサービス名の更新を必ず行ってください。

AWS DevOps

NGINX VirtualServer が作成されていることを確認します。

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

kubectl get virtualserver

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

AWS DevOps

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

このパターンでは、 end-to-end 暗号化をテストするためのアプリケーションとして TLS が有効になっているNGINXウェブサーバーを使用します。テストアプリケーションのデプロイに必要な設定ファイルは、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. を前に作成した Route53 DNS名に置き換えて<application-domain-name>、次のコマンドを入力します。

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

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

AWS DevOps

関連リソース

AWS リソース

その他のリソース