翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
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
対象者
このパターンは、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。
アーキテクチャ
次の図表は、このパターンのアプリケーションのワークフローとアーキテクチャコンポーネントを示しています。
この図表は、次のワークフローを示しています:
クライアントは、アプリケーションにアクセスするためのリクエストをDNS名前に送信します。
Route 53 レコードは、Network Load Balancer CNAMEへの です。
Network Load Balancer は、TLSリスナーで設定された Ingress Controller NGINX にリクエストを転送します。Ingress Controller NGINX と Network Load Balancer 間の通信はHTTPS、プロトコルに従います。
NGINX Ingress Controller は、アプリケーションサービスへのクライアントのリクエストに基づいてパスベースのルーティングを実行します。
アプリケーションサービスはリクエストをアプリケーションポッドに転送します。このアプリケーションは、シークレットを呼び出すことで。同じ証明書を使用するように設計されています。
ポッドは 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レコードを作成し、そのレコードを に配置します | AWS DevOps |
タスク | 説明 | 必要なスキル |
---|---|---|
cert-manager のIAMポリシーを作成します。 | Route 53 ドメインを所有していることを検証するアクセス許可を cert-manager に提供するには、 IAMポリシーが必要です。 で次のコマンドAWSCLIを入力して、IAMポリシーを作成します。
| AWS DevOps |
cert-manager のIAMロールを作成します。 | IAM ポリシーを作成したら、 IAMロールを作成する必要があります。 で次のコマンドAWSCLIを入力して、IAMロールを作成します。
| AWS DevOps |
ロールへのポリシーの付与 | で次のコマンドを入力してAWSCLI、IAMポリシーをIAMロールにアタッチします。をAWSアカウントの ID
| AWS DevOps |
タスク | 説明 | 必要なスキル |
---|---|---|
Ingress Controller NGINX をデプロイします。 | Helm を使用する
| AWS DevOps |
Ingress Controller NGINX がインストールされていることを確認します。 |
| AWS DevOps |
Route 53 A レコードを作成します。 | A レコードは、Ingress Controller によって作成された Network Load Balancer NGINX を指します。
| AWS DevOps |
タスク | 説明 | 必要なスキル |
---|---|---|
をデプロイしますNGINX VirtualServer。 | NGINX VirtualServer リソースは、イングレスリソースの代替となる負荷分散設定です。NGINX VirtualServer リソースを作成する設定は、
重要: | AWS DevOps |
NGINX VirtualServer が作成されていることを確認します。 | で次のコマンド
注: | AWS DevOps |
TLS を有効にしてNGINXウェブサーバーをデプロイします。 | このパターンでは、 end-to-end 暗号化をテストするためのアプリケーションとして TLS が有効になっているNGINXウェブサーバーを使用します。テストアプリケーションのデプロイに必要な設定ファイルは、 アプリケーションのテストを行うには、次のコマンドを
| AWS DevOps |
テストアプリケーションリソースが作成されたことを確認します。 | 次のコマンドを
| AWS DevOps |
アプリケーションを検証します。 |
| AWS DevOps |
関連リソース
AWS リソース
「Amazon Route 53 コンソールを使用したレコードの作成」 (Amazon Route 53 ドキュメント)
Amazon の Ingress Controller での Network Load Balancer NGINX の使用 EKS
(AWS ブログ記事)
その他のリソース
「Route 53
」 (cert-managerドキュメント) DNS「01 チャレンジプロバイダーの設定
」(証明書マネージャードキュメント) Let's Encrypt DNSチャレンジ
(Let's Encrypt ドキュメント)