**このページの改善にご協力ください** このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。 # アマゾン エラスティックKubernetesサービス のセキュリティに関する考慮事項 以下はアマゾン EKS に影響するため、クラウドのセキュリティに関する考慮事項です。 **Topics** + [Amazon EKS でのインフラストラクチャセキュリティ](infrastructure-security.md) + [Amazon EKS クラスターの耐障害性の説明](disaster-recovery-resiliency.md) + [Amazon EKS におけるサービス間の混乱した代理の防止](cross-service-confused-deputy-prevention.md) # Amazon EKS でのインフラストラクチャセキュリティ マネージドサービスの Amazon Elastic Kubernetes Service は、AWS グローバルネットワークセキュリティによって保護されています。AWS セキュリティサービスと AWS がインフラストラクチャを保護する方法については「[AWS クラウドセキュリティ](https://aws.amazon.com/security/)」を参照してください。インフラストラクチャセキュリティのベストプラクティスを使用して AWS 環境を設計するには「*セキュリティの柱 - AWS 適切なアーキテクチャを備えたフレームワーク*」の「[インフラストラクチャの保護](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html)」を参照してください。 AWS が公開している API コールを使用し、ネットワーク経由で Amazon EKS にアクセスします。クライアントは以下をサポートする必要があります。 + Transport Layer Security (TLS)。TLS 1.2 が必須で、TLS 1.3 をお勧めします。 + DHE (楕円ディフィー・ヘルマン鍵共有) や ECDHE (楕円曲線ディフィー・ヘルマン鍵共有) などの完全前方秘匿性 (PFS) による暗号スイート。これらのモードはJava 7 以降など、ほとんどの最新システムでサポートされています。 また、リクエストにはアクセスキー ID と、IAM プリンシパルに関連付けられているシークレットアクセスキーを使用して署名する必要があります。または、[AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) (AWS STS) で一時的なセキュリティ認証情報を生成して、リクエストに署名することもできます。 Amazon EKS のクラスターの作成時には、使用するクラスターの VPC サブネットを指定します。Amazon EKS には、2 つ以上のアベイラビリティーゾーンにサブネットが必要です。パブリックサブネットとプライベートサブネットを持つ VPC をお勧めします。これにより、Kubernetes がパブリックサブネットにパブリックロードバランサーを作成し、プライベートサブネットにあるノードで実行されている Pod へのトラフィックを負荷分散します。 VPC に関する考慮事項の詳細については、「」を参照してください[VPC とサブネットの Amazon EKS ネットワーキング要件を表示する](network-reqs.md) チュートリアル「[Amazon EKS の使用を開始する](getting-started.md)」で提供されている AWS CloudFormation テンプレートを使用して VPC およびノードグループを作成した場合、コントロールプレーンとノードのセキュリティグループは推奨設定で構成されます。 セキュリティグループの考慮事項の詳細については、「」を参照してください[クラスターの Amazon EKS セキュリティグループ要件を表示する](sec-group-reqs.md) 新しいクラスターを作成すると、Amazon EKS によってマネージド型の Kubernetes API サーバーのエンドポイントが作成されます。ユーザーはこのエンドポイントを、(`kubectl` などの Kubernetes 管理ツールにより) クラスターとの通信に使用します。デフォルトでは、この API サーバーエンドポイントはインターネットに公開されます。API サーバーへのアクセスの保護には、AWS Identity and Access Management (IAM) と、ネイティブの Kubernetes [ロールベースアクセスコントロール](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) (RBAC) が組み合わせて使用されます。 Kubernetes API サーバーへのプライベートアクセスを有効にすると、ノードと API サーバー間のすべての通信が VPC 内で行われるようになります。インターネットから API サーバーにアクセスできる IP アドレスを制限したり、API サーバーへのインターネットアクセスを完全に無効にしたりできます。 クラスターエンドポイントアクセスの変更の詳細については、「」を参照してください[クラスターエンドポイントのアクセスの変更](cluster-endpoint.md#modify-endpoint-access) Amazon VPC CNI を使用するか、[Project Calico](https://docs.tigera.io/calico/latest/about/) などのサードパーティーツールを使用して、Kubernetes *ネットワークポリシー*を実装できます。Amazon VPC CNI をネットワークポリシーに使用する方法の詳細については、「[Kubernetes ネットワークポリシーにより Pod トラフィックを制限する](cni-network-policy.md)」を参照してください。Project Calico はサードパーティのオープンソースプロジェクトです。詳細については、[Project Calico のドキュメント](https://docs.tigera.io/calico/latest/getting-started/kubernetes/managed-public-cloud/eks/)を参照してください。 # AWS プライベートリンクを使用して Amazon EKS にアクセスする AWS プライベートリンク を使用して、VPC と Amazon Elastic Kubernetes Service 間にプライベート接続を作成できます。インターネットゲートウェイ、NAT デバイス、VPN 接続、AWS Direct Connect 接続のいずれかを使用せずに、VPC 内にあるかのように Amazon EKS にアクセスできます。VPC のインスタンスはパブリック IP アドレスがなくても Amazon EKS にアクセスできます。 AWS プライベートリンク が電源を供給するインターフェイスエンドポイントを作成することにより、このプライベート接続を確立します。インターフェイスエンドポイントに対して有効にする各サブネットにエンドポイントネットワークインターフェイスを作成します。これらはAmazon EKS 宛てのトラフィックのエントリポイントとして機能するリクエスタ管理型ネットワークインターフェイスです。 詳細については「AWS プライベートリンク ガイド」の「[AWS プライベートリンク を介した AWS サービスへのアクセス](https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-access-aws-services.html)」を参照してください。 ## [開始する前に] 始める前に、次のタスクを実行していることを確認してください。 + 「* AWS PrivateLink ガイド*」の「[インターフェイス VPC エンドポイントを使用した AWS サービスへのアクセス](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#considerations-interface-endpoints)」を確認する ## 考慮事項 + **サポートと制限**: Amazon EKS のインターフェイスエンドポイントは、VPC からのすべての Amazon EKS API アクションへの安全なアクセスを可能にしますが、特定の制限があります。Kubernetes API へのアクセスはサポートされません。Kubernetes API は個別のプライベートエンドポイントがあるため、インターフェイスエンドポイントを介してのみアクセスできるように Amazon EKS を設定することはできません。 + **料金**: Amazon EKS のインターフェイスエンドポイントを使用すると、標準の AWS PrivateLink 料金 (各アベイラビリティーゾーンでプロビジョニングされた各エンドポイントの時間単位の料金と、エンドポイントを経由するトラフィックのデータ処理料金) が発生します。詳細については、「[AWS PrivateLink の料金](https://aws.amazon.com/privatelink/pricing/)」を参照してください。 + **セキュリティとアクセスコントロール**: セキュリティを強化し、アクセスを制御するために、以下の追加設定を推奨します。VPC エンドポイントポリシーを使用し、インターフェイスエンドポイントを介して Amazon EKS へのアクセスを制御し、エンドポイントネットワークインターフェイスにセキュリティグループを関連付けてトラフィックを管理し、VPC フローログを使用してインターフェイスエンドポイントを行き来する IP トラフィックをキャプチャおよびモニタリングし、ログを Amazon CloudWatch または Amazon S3 に発行できるようにします。詳細については、「[エンドポイントポリシーを使用して VPC エンドポイントへのアクセスを制御する](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html)」および「[VPC フローログを使用した IP トラフィックのログ記録](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)」を参照してください。 + **接続オプション**: インターフェイスエンドポイントは、**オンプレミスアクセス** (AWS Direct Connect または AWS Site-to-Site VPN を使用してインターフェイスエンドポイントを持つ VPC にオンプレミスデータセンターを接続する) の使用または **VPC 間接続** (AWS Transit Gateway または VPC ピアリングを使用して、インターフェイスエンドポイントを持つ VPC に他の VPC を接続し、トラフィックを AWS ネットワーク内に留める) を介して柔軟な接続オプションを実現します。 + **IP バージョンのサポート**: 2024 年 8 月より前に作成されたエンドポイントは、eks.region.amazonaws.com を使用した IPv4 のみをサポートします。2024 年 8 月以降に作成された新規エンドポイントは、デュアルスタック IPv4 および IPv6 (eks.region.amazonaws.com や eks.region.api.aws など) をサポートしています。 + **リージョン別可用性**: EKS API の AWS PrivateLink は、アジアパシフィック (マレーシア) (ap-southeast-5)、アジアパシフィック (タイ) (ap-southeast-7)、メキシコ (中部) (mx-central-1)、アジアパシフィック (台北) (ap-east-2) のリージョンでは使用できません。 AWSEKS-auth (EKS Pod Identity) の PrivateLink サポートは、アジアパシフィック (マレーシア) (ap-southeast-5) リージョンで利用できます。 ## Amazon EKS 用のインターフェイスエンドポイントを作成します Amazon VPC コンソールまたは AWS コマンドラインインターフェイス (AWS CLI) を使用して、Amazon EKS のインターフェイスエンドポイントを作成できます。詳細については『AWS プライベートリンク ガイド』の「[VPC エンドポイントを作成](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint-aws)」を参照してください。 次のサービス名を使用して Amazon EKS のインターフェイスエンドポイントを作成します: ### EKS API + com.amazonaws.region-code.eks + com.amazonaws.region-code.eks-fips (FIPS 準拠のエンドポイントの場合) ### EKS Auth API (EKS Pod Identity) + com.amazonaws.region-code.eks-auth ## Amazon EKS インターフェイスエンドポイントのプライベート DNS 機能 Amazon EKS およびその他の AWS サービスのインターフェイスエンドポイントに対してデフォルトで有効になっているプライベート DNS 機能は、デフォルトのリージョン DNS 名を使用して安全でプライベートな API リクエストを容易にします。この機能により、API コールがプライベート AWS ネットワーク経由でインターフェイスエンドポイントを通じてルーティングされ、セキュリティおよびパフォーマンスが向上します。 Amazon EKS または他の AWS サービスのインターフェイスエンドポイントを作成すると、プライベート DNS 機能は自動的にアクティブ化されます。有効にするには、特定の属性を設定して VPC を正しく設定する必要があります。 + **enableDnsHostnames**: VPC 内のインスタンスに DNS ホスト名を付けることができます。 + **enableDnsSupport**: VPC 全体で DNS 解決を有効にします。 これらの設定を確認または変更する手順については、「[VPC の DNS 属性の表示と更新](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating)」を参照してください。 ### DNS 名と IP アドレスタイプ プライベート DNS 機能を有効にすると、特定の DNS 名を使用して Amazon EKS に接続でき、これらのオプションは時間の経過とともに進化します。 + **eks.region.amazonaws.com**: 2024 年 8 月より前に IPv4 アドレスにのみ解決される従来の DNS 名。デュアルスタックに更新された既存のエンドポイントの場合、この名前は IPv4 アドレスおよび IPv6 アドレスの両方に解決されます。 + **eks.region.api.aws**: 2024 年 8 月以降に作成された新規エンドポイントに利用できるこのデュアルスタック DNS 名は、IPv4 アドレスおよび IPv6 アドレスの両方に解決されます。 2024 年 8 月以降、新規のインターフェイスエンドポイントには 2 つの DNS 名があり、デュアルスタック IP アドレスタイプを選択できます。既存のエンドポイントの場合、デュアルスタックに更新すると、IPv4 および IPv6 の両方をサポートするように **eks.region.amazonaws.com** が変更されます。 ### プライベート DNS 機能の使用 設定が完了したら、プライベート DNS 機能をワークフローに統合して次の機能が実現されます。 + **API リクエスト**: エンドポイントの設定に基づいて `eks.region.amazonaws.com` または `eks.region.api.aws` のいずれかのデフォルトリージョン DNS 名を使用し、Amazon EKS に API リクエストを行います。 + **アプリケーションの互換性**: EKS API を呼び出す既存のアプリケーションは、この機能を活用するために変更する必要はありません。 + **AWS CLI とデュアルスタックの併用**: デュアルスタックエンドポイントを AWS CLI と使用するには、「* AWS SDK とツールリファレンスガイド*」の「[デュアルスタックと FIPS エンドポイント](https://docs.aws.amazon.com/sdkref/latest/guide/feature-endpoints.html)」の設定を参照してください。 + **自動ルーティング**: Amazon EKS のデフォルトサービスエンドポイントへの呼び出しはインターフェイスエンドポイントを介して自動的に転送されるため、プライベートで安全な接続が保証されます。 # Amazon EKS クラスターの耐障害性の説明 AWS のグローバルインフラストラクチャは、AWS リージョンとアベイラビリティーゾーンを中心として構築されています。AWSリージョンには、低レイテンシー、高いスループット、そして高度の冗長ネットワークで接続されている複数の物理的に独立し隔離されたアベイラビリティーゾーンがあります。アベイラビリティーゾーンでは、アベイラビリティーゾーン間で中断せずに、自動的にフェイルオーバーするアプリケーションとデータベースを設計および運用することができます。アベイラビリティーゾーンは、従来の単一または複数のデータセンターインフラストラクチャよりも可用性、耐障害性、および拡張性が優れています。 Amazon EKS は、複数の AWS アベイラビリティーゾーンで Kubernetes コントロールプレーンインスタンスを実行およびスケーリングして、高可用性を実現します。Amazon EKS は、負荷に基づいてコントロールプレーンインスタンスを自動的にスケーリングします。また、異常なコントロールプレーンインスタンスを自動的に検出して置換し、そのコントロールプレーンに自動的にパッチを適用します。バージョン更新を開始すると、Amazon EKS によってコントロールプレーンが自動的に更新され、更新中のコントロールプレーンの高可用性が維持されます。 このコントロールプレーンは、少なくとも 2 つの API サーバーインスタンスと、(1 つの AWS リージョンで 3 つのアベイラビリティーゾーンにまたがっている) 3 つの `etcd` インスタンスを含みます。Amazon EKS: + コントロールプレーンインスタンスの負荷をアクティブに監視し、高パフォーマンスを確保するために、それらのインスタンスを自動的にスケーリングします。 + 異常なコントロールプレーンインスタンスを自動的に検出して置換します。それらのコントロールプレーンインスタンスは、必要に応じて AWS リージョン内のアベイラビリティーゾーンで再起動されます。 + 高可用性を維持するために、AWS リージョンのアーキテクチャを活用します。そのため、Amazon EKS では [API サーバーエンドポイント向けの可用性の SLA](https://aws.amazon.com/eks/sla) をご利用いただけます。 AWS リージョンとアベイラビリティーゾーンの詳細については、「[AWSグローバルインフラストラクチャ](https://aws.amazon.com/about-aws/global-infrastructure/)」を参照してください。 # Amazon EKS におけるサービス間の混乱した代理の防止 混乱した代理問題とは、あるアクションを実行する許可を持たないエンティティが、より多くの特権を持つエンティティにアクションの実行を強制できることで生じるセキュリティ上の問題です。AWS では、サービス間でのなりすましによって、混乱した代理問題が発生する場合があります。サービス間でのなりすましは、1 つのサービス (呼び出し元サービス) が、別のサービス (呼び出し対象サービス) を呼び出すときに発生する可能性があります。呼び出し元サービスが操作され、それ自身のアクセス許可が使用されて、本来アクセス許可が付与されるべきではない方法により、別の顧客のリソースに影響を与える可能性があります。これを防ぐために、AWS には、アカウント内のリソースへのアクセス権が付与されたサービスプリンシパルですべてのサービスのデータを保護するために役立つツールが用意されています。 リソースポリシー内では [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) および [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) のグローバル条件コンテキストキーを使用して、Amazon Elastic Kubernetes Service (Amazon EKS) が別のサービスに付与する、リソースへのアクセス許可を制限することをお勧めします。 `aws:SourceArn` 1 つのリソースだけをクロスサービスのアクセスに関連付ける場合は、`aws:SourceArn` を使用します。 `aws:SourceAccount` アカウント内の任意のリソースをクロスサービスの使用に関連付ける場合は、`aws:SourceAccount` を使用します。 混乱した代理問題から保護するための最も効果的な方法は、リソースの完全な ARN を指定して `aws:SourceArn` グローバル条件コンテキストキーを使用することです。リソースの完全な ARN が不明な場合や、複数のリソースを指定する場合には、グローバルコンテキスト条件キー `aws:SourceArn` で、ARN の未知部分を示すためにワイルドカード文字 (\$1) を使用します。例えば、` arn:aws::*:<123456789012>:*`。 `aws:SourceArn` の値に Amazon S3 バケット ARN などのアカウント ID が含まれていない場合は、両方の `aws:SourceAccount` と `aws:SourceArn` を使用して、アクセス許可を制限する必要があります。 ## Amazon EKS クラスターロールのクロスサービスにおける混乱した代理を防止する Amazon EKS クラスター IAM ロールはクラスターごとに必要です。Amazon EKS によって管理される Kubernetes クラスターはこのロールを使用してノードを管理し、[レガシークラウドプロバイダー](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/#legacy-cloud-provider)はこのロールを使用して Elastic Load Balancing によるロードバランサーをサービス用に作成します。このいずれのクラスターアクションも同じアカウントにのみ影響するため、各クラスターロールをそのクラスターとアカウントに制限することをお勧めします。これは、*最小特権の原則*に従って AWS の推奨事項をアカウントに具体的に適用したものです。 **ソースの ARN 形式** `aws:SourceArn` の値は、` arn:aws:eks:region:account:cluster/cluster-name ` という形式の EKS クラスターの ARN にする必要があります。例えば、` arn:aws:eks:us-west-2:123456789012:cluster/my-cluster` です。 **EKS クラスターロールの信頼ポリシーの形式** 次の例では、Amazon EKS で `aws:SourceArn` と `aws:SourceAccount` のグローバル条件コンテキストキーを使用して、「混乱した代理」問題を回避する方法を示します。 ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "eks.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "ArnLike": { "aws:SourceArn": "arn:aws:eks:us-west-2:123456789012:cluster/my-cluster" }, "StringEquals": { "aws:SourceAccount": "123456789012" } } } ] } ```