

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

# cert-managerと Let's Encrypt を使用して Amazon EKS のアプリケーションのエンドツーエンド暗号化を設定
<a name="set-up-end-to-end-encryption-for-applications-on-amazon-eks-using-cert-manager-and-let-s-encrypt"></a>

*Mahendra Revanasiddappa と Vasanth Jeyaraj、Amazon Web Services*

## 概要
<a name="set-up-end-to-end-encryption-for-applications-on-amazon-eks-using-cert-manager-and-let-s-encrypt-summary"></a>

エンドツーエンド暗号化の実装は複雑で、マイクロサービスアーキテクチャ内の各アセットの証明書を管理する必要があります。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 エンドツーエンド暗号化](https://github.com/aws-samples/end-to-end-encryption-on-amazon-eks#readme)」 のサンプルアプリケーションとコードを提供し、マイクロサービスが Amazon EKS でエンドツーエンド暗号化を使用してどのように実行されるかを示します。このパターンのアプローチでは、Kubernetes のアドオンである「[cert-manager](https://cert-manager.io/docs/)」 を使用し、認証局 (CA) として 「[Let's Encrypt](https://letsencrypt.org/)」 を使用します。Let's Encrypt は費用対効果の高い証明書管理ソリューションで、90 日間有効な証明書を無料で提供しています。Cert-manager は、新しいマイクロサービスが Amazon EKS にデプロイされたときに、証明書のオンデマンドプロビジョニングとローテーションを自動化します。 

**対象者**

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

## 前提条件と制限事項
<a name="set-up-end-to-end-encryption-for-applications-on-amazon-eks-using-cert-manager-and-let-s-encrypt-prereqs"></a>

**前提条件**
+ アクティブな AWS アカウント。
+ 既存の Amazon EKS クラスター。
+ macOS、Linux、または Windows にインストールされ、設定された AWS コマンドラインインターフェイス (AWS CLI) バージョン 1.7 以降。
+ Amazon EKS クラスターにアクセスするために、インストールおよび設定された `kubectl` コマンドラインユーティリティ。これについての詳細は、Amazon EKS ドキュメントの「[kubectl のインストール](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)」 を参照してください。
+ アプリケーションをテストするための既存のアプリケーション名です。これについての詳細は、Amazon Route 53 デベロッパーガイドの「 [Amazon Route 53 を使用したドメイン名の登録](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/registrar.html)」を参照してください。 
+ ローカルマシンにインストールされている最新の 「[Helm](https://docs.aws.amazon.com/eks/latest/userguide/helm.html)」 バージョン。これについての詳細は、Amazon EKS ドキュメントの「[Amazon EKS での Helm の使用](https://docs.aws.amazon.com/eks/latest/userguide/helm.html)」 と GitHub 「[Helm](https://github.com/helm/helm)」 リポジトリを参照してください。 
+ ローカルマシンに複製された GitHub 「[Amazon EKS リポジトリの エンドツーエンド暗号化](https://github.com/aws-samples/end-to-end-encryption-on-amazon-eks#readme)」。 
+ 複製された GitHub 「[Amazon EKS リポジトリのエンドツーエンド暗号化](https://github.com/aws-samples/end-to-end-encryption-on-amazon-eks#readme)」から `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 のマイクロサービスで証明書を使用する方法のみを示しています。 

## アーキテクチャ
<a name="set-up-end-to-end-encryption-for-applications-on-amazon-eks-using-cert-manager-and-let-s-encrypt-architecture"></a>

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

![\[cert-manager と Let's Encrypt を使用して Amazon EKS のアプリケーションの暗号化を設定するワークフロー。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/9aa3ee9e-73db-41f5-a467-b5c47fef496e/images/40692ede-6fb3-474e-8c9e-85c51529e8ad.png)


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

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

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

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

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

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

1. ポッドは cert-managerの証明書を使用してサンプルアプリケーションを実行します。NGINX Ingress コントローラーとポッド間の通信には HTTPS が使用されます。


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

## ツール
<a name="set-up-end-to-end-encryption-for-applications-on-amazon-eks-using-cert-manager-and-let-s-encrypt-tools"></a>

**AWS サービス**
+ [Amazon Elastic Kubernetes Service (Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) は、AWS で Kubernetes を簡単に実行できるようにするマネージド型サービスです。ユーザー独自の Kubernetes コントロールプレーンまたはノードをインストール、操作、維持する必要はありません。
+ [Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html) は、受信したトラフィックを複数のターゲット、コンテナ、IPアドレスに自動的に分散します。
+ 「[AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)」は、AWS リソースへのアクセスを安全に管理し、誰が認証され、使用する権限があるかを制御するのに役立ちます。
+ [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) は、高可用性でスケーラブルな DNS Web サービスです。

**その他のツール**
+ 「[cert-manager](https://cert-manager.io/docs/installation/supported-releases/)」 は Kubernetes のアドオンで、証明書をリクエストして Kubernetes コンテナに配布し、証明書の更新を自動化します。
+ 「[NGINX Ingress Controller](https://kubernetes.github.io/ingress-nginx/) 」は、Kubernetes およびコンテナ化された環境におけるクラウドネイティブアプリケーション向けのトラフィック管理ソリューションです。

## エピック
<a name="set-up-end-to-end-encryption-for-applications-on-amazon-eks-using-cert-manager-and-let-s-encrypt-epics"></a>

### Route 53 でパブリックホストゾーンを作成して設定
<a name="create-and-configure-a-public-hosted-zone-with-route-53"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| Route 53 にドメインのパブリックホストゾーンを作成します。 | AWS マネジメントコンソールにサインインし、Amazon Route 53 コンソールを開き、［**ホストゾーン**］を選択し、［**ホストゾーンの作成**］を選択します。パブリックホストゾーンを作成し、ゾーン ID を記録します。これについての詳細は、Amazon Route 53 ドキュメントの「[公開ホストゾーンの作成](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingHostedZone.html)」を参照してください。ACME DNS01 は DNS プロバイダーを使用して、証明書発行用の cert-manager にチャレンジを投稿します。このチャレンジでは、ドメイン名の TXT レコードに特定の値を入力して、そのドメイン名の DNS を管理していることを証明するよう求められます。Let's Encrypt が ACME クライアントにトークンを渡した後、クライアントはそのトークンとアカウントキーから得た TXT レコードを作成し、そのレコードを `_acme-challenge.<YOURDOMAIN>` に保存します。次に、Let's Encrypt は DNS にそのレコードを問い合わせます。一致するものが見つかったら、証明書の発行に進むことができます。 | AWS DevOps | 

### 証明書マネージャーがパブリックホストゾーンにアクセスできるように IAM ロールを設定する
<a name="configure-an-iam-role-to-allow-cert-manager-to-access-the-public-hosted-zone"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| cert-manager 用の IAM ポリシーを作成します。 | ユーザーが Route 53 ドメインを所有していることを検証する権限を cert-manager に提供するには、IAM ポリシーが必要です。`policy.json` のサンプル IAM ポリシーが、複製されたGitHub「[ Amazon EKS リポジトリのエンドツーエンドの暗号化](https://github.com/aws-samples/end-to-end-encryption-on-amazon-eks#readme)」リポジトリの `1-IAMRole` ディレクトリにあります。次の AWS CLI コマンドを使用して、IAM ポリシーを作成します。<pre>aws iam create-policy \<br />  --policy-name PolicyForCertManager \<br />  --policy-document file://policy.json</pre> | AWS DevOps | 
| cert-managerの IAM ロールを作成します。 | IAM ポリシーを作成したら、IAM ロールを作成する必要があります。`trustpolicy.json` サンプル IAM ロールが `1-IAMRole` ディレクトリに提供されます。IAM ロールを作成するには、次のコマンドをAWS CLIに入力します。<pre>aws iam create-role \<br />  --role-name RoleForCertManager \<br />  --assume-role-policy-document file://trustpolicy.json</pre> | AWS DevOps | 
| ロールへのポリシーの付与 | AWS CLI に以下のコマンドを入力して、 IAM ロールにIAMポリシーをアタッチします。`AWS_ACCOUNT_ID` を自分の AWS アカウントのID に置き換えます。<pre>aws iam attach-role-policy \<br />  --policy-arn arn:aws:iam::AWS_ACCOUNT_ID:policy/PolicyForCertManager \<br />  --role-name RoleForCertManager</pre> | AWS DevOps | 

### Amazon EKS で NGINX Ingress コントローラーをセットアップする
<a name="set-up-the-nginx-ingress-controller-in-amazon-eks"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| 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 を指します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-end-to-end-encryption-for-applications-on-amazon-eks-using-cert-manager-and-let-s-encrypt.html) | AWS DevOps | 

### Amazon EKS に NGINX 仮想サーバーをセットアップ
<a name="set-up-nginx-virtualserver-on-amazon-eks"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| 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` に入力して、テストアプリケーションに必要なリソースが作成されていることを確認します[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-end-to-end-encryption-for-applications-on-amazon-eks-using-cert-manager-and-let-s-encrypt.html) | AWS DevOps | 
| アプリケーションを検証します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/set-up-end-to-end-encryption-for-applications-on-amazon-eks-using-cert-manager-and-let-s-encrypt.html) | AWS DevOps | 

## 関連リソース
<a name="set-up-end-to-end-encryption-for-applications-on-amazon-eks-using-cert-manager-and-let-s-encrypt-resources"></a>

「**AWS リソース**」
+ 「[Amazon Route 53 コンソールを使用したレコードの作成](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-creating.html)」 (Amazon Route 53 ドキュメント)
+ 「[Amazon EKS の NGINX イングレスコントローラーでのNetwork Load Balancer の使用](https://aws.amazon.com/blogs/opensource/network-load-balancer-nginx-ingress-controller-eks/)」 (AWS ブログ投稿)

**その他のリソース**
+ 「[Route 53](https://cert-manager.io/docs/configuration/acme/dns01/route53/)」 (cert-managerドキュメント)
+ 「[DNS01 チャレンジプロバイダーの設定](https://cert-manager.io/docs/configuration/acme/dns01/)」 (cert-managerドキュメント)
+ 「[Let’s Encrypt DNS チャレンジ](https://letsencrypt.org/docs/challenge-types/#dns-01-challenge)」(Let’s Encrypt ドキュメント)