翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
AWS セキュリティグループは、EC2 インスタンスの仮想ファイアウォールとして機能し、インバウンドトラフィックとアウトバウンドトラフィックを制御します。デフォルトでは、Amazon VPC CNI はノード上のプライマリ ENI に関連付けられたセキュリティグループを使用します。具体的には、インスタンスに関連付けられているすべての ENI に同じ EC2 セキュリティグループがあります。したがって、ノード上のすべての Pod は、実行されるノードと同じセキュリティグループを共有します。
次の図に示すように、ワーカーノードで動作しているすべてのアプリケーションポッドは、RDS データベースサービスにアクセスできます (RDS インバウンドではノードセキュリティグループが許可されます）。セキュリティグループは、ノードで実行されているすべての Pod に適用されるため、粗すぎます。Pod のセキュリティグループは、ワークロードのネットワークセグメンテーションを提供します。これは、深い戦略における優れた防御に不可欠な部分です。
Pod のセキュリティグループを使用すると、共有コンピューティングリソースでさまざまなネットワークセキュリティ要件を持つアプリケーションを実行することで、コンピューティング効率を向上させることができます。Pod-to-Pod や Pod-to-External AWS サービスなど、複数のタイプのセキュリティルールを EC2 セキュリティグループで 1 か所で定義し、Kubernetes ネイティブ APIs を使用するワークロードに適用できます。以下の図は、Pod レベルで適用されるセキュリティグループと、それらがアプリケーションのデプロイとノードアーキテクチャを簡素化する方法を示しています。Pod が Amazon RDS データベースにアクセスできるようになりました。
ENABLE_POD_ENI=true VPC CNI の を設定することで、Pod のセキュリティグループを有効にできます。有効にすると、コントロールプレーン (EKS によって管理) で実行されている VPC リソースコントローラーAmazonEKSVPCResourceController管理ポリシーを追加する必要があります。
また、コントローラーは「aws-k8s-branch-eni」という名前のブランチインターフェイスを作成し、トランクインターフェイスに関連付けます。ポッドには SecurityGroupPolicy
ブランチインターフェイス容量は、セカンダリ IP アドレスの既存のインスタンスタイプの制限に追加されます。セキュリティグループを使用するポッドは、max-pods 式では考慮されません。ポッドにセキュリティグループを使用する場合は、max-pods 値を増やすことを検討するか、ノードが実際にサポートできる数よりも少ないポッドの実行で問題ありません。
m5.large には、最大 9 つのブランチネットワークインターフェイスと最大 27 のセカンダリ IP アドレスを標準ネットワークインターフェイスに割り当てることができます。以下の例に示すように、m5.large のデフォルトの最大ポッド数は 29 で、EKS はセキュリティグループを使用するポッドを最大ポッド数にカウントします。ノードの最大ポッドを変更する方法については、EKS ユーザーガイドを参照してください。
Pod のセキュリティグループをカスタムネットワークと組み合わせて使用する場合、ポッドのセキュリティグループで定義されたセキュリティグループは、ENIConfig で指定されたセキュリティグループではなく使用されます。その結果、カスタムネットワーキングが有効になっている場合は、Pod ごとにセキュリティグループを使用しながら、セキュリティグループの順序を慎重に評価します。
レコメンデーション
Liveness Probe の TCP 早期デマックスを無効にする
ライブネスプローブまたは準備状況プローブを使用している場合は、TCP アーリーデマックスも無効にして、kubelet が TCP 経由でブランチネットワークインターフェイスの Pod に接続できるようにする必要があります。これは strict モードでのみ必要です。これを行うには、次のコマンドを実行します。
kubectl edit daemonset aws-node -n kube-system
initContainer セクションで、 の値を DISABLE_TCP_EARLY_DEMUX に変更します。 true.
Pod のセキュリティグループを使用して、既存の AWS 設定投資を活用します。
セキュリティグループを使用すると、RDS データベースや EC2 インスタンスなどの VPC リソースへのネットワークアクセスを簡単に制限できます。Pod あたりのセキュリティグループの明らかな利点の 1 つは、既存の AWS セキュリティグループリソースを再利用できることです。セキュリティグループをネットワークファイアウォールとして使用して AWS サービスへのアクセスを制限する場合は、ブランチ ENIs を使用してセキュリティグループを Pod に適用することをお勧めします。EC2 インスタンスから EKS にアプリケーションを転送し、セキュリティグループを使用して他の AWS サービスへのアクセスを制限する場合は、Pod のセキュリティグループの使用を検討してください。
Pod セキュリティグループ強制モードを設定する
Amazon VPC CNI プラグインバージョン 1.11 に、 POD_SECURITY_GROUP_ENFORCING_MODE (「強制モード」) という名前の新しい設定が追加されました。強制モードは、ポッドに適用するセキュリティグループと、ソース NAT が有効になっているかどうかの両方を制御します。強制モードは strict または standard として指定できます。Strict がデフォルトであり、 を ENABLE_POD_ENIに設定して VPC CNI の以前の動作を反映していますtrue。
Strict Mode では、ブランチ ENI セキュリティグループのみが強制されます。ソース NAT も無効になっています。
標準モードでは、プライマリ ENI とブランチ ENI (ポッドに関連付けられている) の両方に関連付けられているセキュリティグループが適用されます。ネットワークトラフィックは両方のセキュリティグループに準拠する必要があります。
警告
モードを変更すると、新しく起動されたポッドにのみ影響します。既存のポッドは、ポッドの作成時に設定されたモードを使用します。トラフィックの動作を変更する場合は、セキュリティグループを使用して既存の Pod をリサイクルする必要があります。
強制モード: ポッドとノードのトラフィックを分離するには、厳密なモードを使用します。
デフォルトでは、Pod のセキュリティグループは「厳格モード」に設定されています。Pod トラフィックをノードの残りのトラフィックから完全に分離する必要がある場合は、この設定を使用します。Strict モードでは、ソース NAT がオフになっているため、ブランチ ENI アウトバウンドセキュリティグループを使用できます。
警告
Strict モードを有効にすると、ポッドからのすべてのアウトバウンドトラフィックがノードを離れ、VPC ネットワークに入ります。同じノード上のポッド間のトラフィックは VPC を経由します。これにより、VPC トラフィックが増加し、ノードベースの機能が制限されます。NodeLocal DNSCache は strict モードではサポートされていません。
強制モード: 次の状況では標準モードを使用します。
Pod のコンテナに表示されるクライアントソース IP
Pod のコンテナにクライアントソース IP を表示したままにする必要がある場合は、 POD_SECURITY_GROUP_ENFORCING_MODEを に設定することを検討してくださいstandard。Kubernetes サービスは externalTrafficPolicy=local をサポートし、クライアントソース IP (デフォルトタイプクラスター) の保存をサポートします。標準モードで externalTrafficPolicy を Local に設定してインスタンスターゲットを使用して、NodePort および LoadBalancer タイプの Kubernetes サービスを実行できるようになりました。 はクライアントソース IP Localを保持し、LoadBalancer および NodePort タイプのサービスの 2 番目のホップを回避します。
NodeLocal DNSCache のデプロイ
ポッドにセキュリティグループを使用する場合は、NodeLocal DNSCache
NodeLocal DNSCache は、ノードへのすべてのネットワークトラフィックが VPC に入るため、厳密なモードではサポートされません。
Kubernetes ネットワークポリシーのサポート
セキュリティグループが関連付けられている Pod でネットワークポリシーを使用する場合は、標準強制モードを使用することをお勧めします。
Pod のセキュリティグループを利用して、クラスターの一部ではない AWS のサービスへのネットワークレベルのアクセスを制限することを強くお勧めします。クラスター内のポッド間のネットワークトラフィックを制限するネットワークポリシーを検討してください。これは、多くの場合、東部/西部トラフィックと呼ばれます。
Pod ごとにセキュリティグループとの非互換性を特定する
Windows ベースのインスタンスと Nitro 以外のインスタンスは、Pod のセキュリティグループをサポートしていません。Pod でセキュリティグループを利用するには、インスタンスに isTrunkingEnabled というタグを付ける必要があります。Pod が VPC 内外の AWS のサービスに依存していない場合は、セキュリティグループではなくネットワークポリシーを使用して Pod 間のアクセスを管理します。
ポッドあたりのセキュリティグループを使用して AWS サービスへのトラフィックを効率的に制御する
EKS クラスター内で実行されているアプリケーションが RDS データベースなどの VPC 内の別のリソースと通信する必要がある場合は、ポッドSGs を使用することを検討してください。CIDR または DNS 名を指定できるポリシーエンジンはありますが、VPC 内に存在するエンドポイントを持つ AWS サービスと通信するときは最適ではありません。
これとは対照的に、Kubernetes ネットワークポリシー
Amazon EKS では、Calico
AWS Loadbalancer Controller を使用するように単一のセキュリティグループにタグ付けする
Pod に多くのセキュリティグループが割り当てられている場合、Amazon EKS ではkubernetes.io/cluster/$name
アウトバウンドトラフィックの NAT を設定する
セキュリティグループが割り当てられている Pod からのアウトバウンドトラフィックでは、ソース NAT は無効になっています。NAT ゲートウェイまたはインスタンスで設定されたプライベートサブネット上のインターネット起動ワーカーノードにアクセスし、CNI で外部 SNAT を有効にする必要があるセキュリティグループを使用するポッドの場合。
kubectl set env daemonset -n kube-system aws-node AWS_VPC_K8S_CNI_EXTERNALSNAT=true
セキュリティグループを持つポッドをプライベートサブネットにデプロイする
セキュリティグループが割り当てられたポッドは、プライベートサブネットにデプロイされているノードで実行する必要があります。パブリックサブネットにデプロイされたセキュリティグループが割り当てられたポッドは、インターネットにアクセスできないことに注意してください。
Pod 仕様ファイルで terminationGracePeriodSeconds を検証する
Pod 仕様ファイルで terminationGracePeriodSecondsがゼロ以外であることを確認します (デフォルトは 30 秒）。これは、Amazon VPC CNI がワーカーノードから Pod ネットワークを削除するために不可欠です。ゼロに設定すると、CNI プラグインはホストから Pod ネットワークを削除せず、ブランチ ENI は効果的にクリーンアップされません。
Fargate でのポッドのセキュリティグループの使用
Fargate で実行される Pod のセキュリティグループは、EC2 ワーカーノードで実行される Pod と非常によく似ています。たとえば、Fargate Pod に関連付ける SecurityGroupPolicy でセキュリティグループを参照する前に、セキュリティグループを作成する必要があります。デフォルトでは、SecurityGroupPolicy を Fargate Pod に明示的に割り当てない場合、クラスターセキュリティグループはすべての Fargate Pod に割り当てられます。わかりやすくするために、クラスターセキュリティグループを Fagate Pod の SecurityGroupPolicy に追加することもできます。追加しない場合は、セキュリティグループに最小セキュリティグループルールを追加する必要があります。describe-cluster API を使用してクラスターセキュリティグループを見つけることができます。
aws eks describe-cluster --name CLUSTER_NAME --query 'cluster.resourcesVpcConfig.clusterSecurityGroupId'cat >my-fargate-sg-policy.yaml <<EOF
apiVersion: vpcresources.k8s.aws/v1beta1
kind: SecurityGroupPolicy
metadata:
name: my-fargate-sg-policy
namespace: my-fargate-namespace
spec:
podSelector:
matchLabels:
role: my-fargate-role
securityGroups:
groupIds:
- cluster_security_group_id
- my_fargate_pod_security_group_id
EOFセキュリティグループの最小ルールを以下に示します。これらのルールにより、Fargate Pod は kube-apiserver、kubelet、CoreDNS などのクラスター内のサービスと通信できます。また、Fargate Pod との間のインバウンド接続とアウトバウンド接続を許可するルールを追加する必要があります。これにより、Pod は VPC 内の他の Pod またはリソースと通信できるようになります。さらに、Fargate が Amazon ECR または DockerHub などの他のコンテナレジストリからコンテナイメージをプルするためのルールを含める必要があります。詳細については、AWS 全般のリファレンスの「AWS IP アドレス範囲」を参照してください。
以下のコマンドを使用して、Fargate Pod に適用されているセキュリティグループを検索できます。
kubectl get pod FARGATE_POD -o jsonpath='{.metadata.annotations.vpc\.amazonaws\.com/pod-eni}{"\n"}'上記のコマンドの eniId を書き留めます。
aws ec2 describe-network-interfaces --network-interface-ids ENI_ID --query 'NetworkInterfaces[*].Groups[*]'新しいセキュリティグループを適用するには、既存の Fargate ポッドを削除して再作成する必要があります。たとえば、次のコマンドは example-app のデプロイを開始します。特定のポッドを更新するには、次のコマンドで名前空間とデプロイ名を変更できます。
kubectl rollout restart -n example-ns deployment example-pod
