ポッドあたりのセキュリティグループ - Amazon EKS
レコメンデーション

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

ポッドあたりのセキュリティグループ

AWS セキュリティグループは、インバウンドトラフィックとアウトバウンドトラフィックを制御するEC2インスタンスの仮想ファイアウォールとして機能します。デフォルトでは、Amazon VPCCNIはノードENIのプライマリに関連付けられたセキュリティグループを使用します。具体的には、インスタンスENIに関連付けられているすべての に同じEC2セキュリティグループがあります。したがって、ノード上のすべての Pod は、実行しているノードと同じセキュリティグループを共有します。

次の図に示すように、ワーカーノードで動作しているすべてのアプリケーションポッドは、RDSデータベースサービスにアクセスできます (RDSインバウンドではノードセキュリティグループが許可されます）。セキュリティグループは、ノードで実行されているすべての Pod に適用されるため、粗すぎます。Pods のセキュリティグループは、ワークロードのネットワークセグメンテーションを提供します。これは、デプス戦略における優れた防御に不可欠な部分です。

に接続しているセキュリティグループを持つノードの図 RDS

Pods のセキュリティグループを使用すると、共有コンピューティングリソースでさまざまなネットワークセキュリティ要件を持つアプリケーションを実行することで、コンピューティング効率を向上させることができます。や Pod-to-External AWSサービスなど Pod-to-Pod、複数のタイプのセキュリティルールをEC2セキュリティグループで 1 か所で定義し、Kubernetes ネイティブ のワークロードに適用できますAPIs。以下の図は、ポッドレベルで適用されたセキュリティグループと、それらがアプリケーションのデプロイとノードアーキテクチャを簡素化する方法を示しています。Pod が Amazon RDS データベースにアクセスできるようになりました。

に接続しているさまざまなセキュリティグループを持つポッドとノードの図 RDS

ポッドのセキュリティグループを有効にするには、 を VPC ENABLE_POD_ENI=trueに設定しますCNI。有効にすると、コントロールプレーン ( によって管理EKS) で実行されている VPC Resource Controller は、「aws-k8s-trunk-eni」と呼ばれるトランクインターフェイスを作成してノードにアタッチします。トランクインターフェイスは、インスタンスにアタッチされた標準ネットワークインターフェイスとして機能します。トランクインターフェイスを管理するには、Amazon クラスターと連携するEKSクラスターロールに AmazonEKSVPCResourceControllerマネージドポリシーを追加する必要があります。

また、コントローラーは「aws-k8s-branch-eni」という名前のブランチインターフェイスを作成し、それらをトランクインターフェイスに関連付けます。ポッドには、SecurityGroupPolicyカスタムリソースを使用してセキュリティグループが割り当てられ、ブランチインターフェイスに関連付けられます。セキュリティグループはネットワークインターフェイスで指定されているため、これらの追加のネットワークインターフェイスで特定のセキュリティグループを必要とするポッドをスケジュールできるようになりました。デプロイの前提条件を含めEKS、ポッドのセキュリティグループに関するユーザーガイドセクションを確認してください。

に関連付けられたセキュリティグループを持つワーカーサブネットの図 ENIs

ブランチインターフェイス容量は、セカンダリ IP アドレスの既存のインスタンスタイプの制限に追加されます。セキュリティグループを使用するポッドは max-pods 式では考慮されず、ポッドにセキュリティグループを使用する場合は、max-pods 値を上げることを検討するか、ノードが実際にサポートできる数よりも少ないポッドの実行で問題ありません。

m5.large には、最大 9 つのブランチネットワークインターフェイスと最大 27 のセカンダリ IP アドレスを標準ネットワークインターフェイスに割り当てることができます。以下の例に示すように、m5.large のデフォルトの最大ポッドは 29 で、セキュリティグループを使用するポッドを最大ポッドにEKSカウントします。ノードの最大ポッドを変更する方法については、EKSユーザーガイドを参照してください。

Pods のセキュリティグループをカスタムネットワーク と組み合わせて使用する場合、Pods のセキュリティグループで定義されたセキュリティグループが、 で指定されたセキュリティグループではなく使用されますENIConfig。その結果、カスタムネットワークが有効になっている場合は、Pod ごとにセキュリティグループを使用しながら、セキュリティグループの順序を慎重に評価します。

レコメンデーション

TCP Early Demux for Liveness Probe を無効にする

ライブネスまたは準備状況プローブを使用している場合は、kubelet が 経由でブランチネットワークインターフェイスの Pods に接続できるように、TCP早期デマルチプレクサを無効にする必要もありますTCP。これは、厳密なモードでのみ必要です。これを行うには、次のコマンドを実行します。

kubectl edit daemonset aws-node -n kube-system

initContainer セクションで、 の値を DISABLE_TCP_EARLY_DEMUX に変更します。 true.

Security Group For Pods を使用して、既存のAWS設定投資を活用します。

セキュリティグループを使用すると、RDSデータベースやEC2インスタンスなどのVPCリソースへのネットワークアクセスを簡単に制限できます。ポッドあたりのセキュリティグループの明らかな利点の 1 つは、既存のAWSセキュリティグループリソースを再利用する機会です。セキュリティグループをネットワークファイアウォールとして使用してAWSサービスへのアクセスを制限する場合は、ブランチ を使用してセキュリティグループを Pod に適用することをお勧めしますENIs。EC2 インスタンスから にアプリケーションを転送しEKS、セキュリティグループを使用して他のAWSサービスへのアクセスを制限する場合は、Pods のセキュリティグループの使用を検討してください。

ポッドセキュリティグループ強制モードの設定

Amazon VPC CNI プラグインバージョン 1.11 に、 POD_SECURITY_GROUP_ENFORCING_MODE (「強制モード」) という名前の新しい設定が追加されました。強制モードは、ポッドに適用するセキュリティグループと、ソースNATが有効になっている場合の両方を制御します。強制モードは、厳格または標準として指定できます。Strict はデフォルトであり、 が ENABLE_POD_ENIに設定されている VPC CNI の以前の動作を反映していますtrue。

Strict モードでは、ブランチENIセキュリティグループのみが強制されます。ソースも無効NATになっています。

スタンダードモードでは、プライマリENIとブランチの両方に関連付けられているセキュリティグループ ENI (ポッドに関連付けられている) が適用されます。ネットワークトラフィックは両方のセキュリティグループに準拠する必要があります。

警告

モードを変更すると、新しく起動された Pod にのみ影響します。既存のポッドは、ポッドの作成時に設定されたモードを使用します。トラフィック動作を変更する場合は、セキュリティグループを使用して既存の Pod をリサイクルする必要があります。

強制モード: ポッドとノードのトラフィックを分離するには、ストリックモードを使用します。

デフォルトでは、ポッドのセキュリティグループは「厳格モード」に設定されています。Pod トラフィックをノードの残りのトラフィックから完全に分離する必要がある場合は、この設定を使用します。厳密なモードでは、ブランチENIアウトバウンドセキュリティグループを使用できるように、ソースNATがオフになります。

警告

厳密なモードが有効になっている場合、ポッドからのすべてのアウトバウンドトラフィックはノードを離れ、VPCネットワークに入ります。同じノード上のポッド間のトラフィックは、 を経由しますVPC。これにより、VPCトラフィックが増加し、ノードベースの機能が制限されます。 NodeLocal DNSCache は、厳密なモードではサポートされていません。

強制モード: 次の状況では標準モードを使用します。

Pod のコンテナに表示されるクライアントソース IP

Pod のコンテナにクライアントソース IP を表示したままにする必要がある場合は、 POD_SECURITY_GROUP_ENFORCING_MODE を に設定することを検討してくださいstandard。Kubernetes サービスサポート externalTrafficPolicy=local は、クライアントソース IP (デフォルトタイプクラスター) の保存をサポートします。これで、 タイプの Kubernetes サービスを実行し NodePort 、インスタンスターゲットを 標準モードで Local externalTrafficPolicy に設定して LoadBalancer 使用できるようになりました。 はクライアントソース IP Localを保持し、 LoadBalancer と NodePort タイプの Services の 2 番目のホップを回避します。

デプロイ NodeLocal DNSCache

ポッドにセキュリティグループを使用する場合は、 を使用するポッドをサポートするように標準モードを設定しますNodeLocal DNSCache。 NodeLocal DNSCache は、クラスターノードで としてDNSキャッシュエージェントを実行することで、クラスターDNSのパフォーマンスを向上させます DaemonSet。これにより、ローカルキャッシュを持つローカル kube-dns/CoreDNS をクエリするDNSQPS要件が最も高いポッドが役立ち、レイテンシーが向上します。

NodeLocal DNSCache は、ノードへのすべてのネットワークトラフィックが に入るため、厳密なモードではサポートされませんVPC。

Kubernetes ネットワークポリシーのサポート

セキュリティグループが関連付けられている Pod でネットワークポリシーを使用する場合は、標準強制モードを使用することをお勧めします。

Pods のセキュリティグループを利用して、クラスターに含まれていないAWSサービスへのネットワークレベルのアクセスを制限することを強くお勧めします。クラスター内の Pod 間のネットワークトラフィックを制限するネットワークポリシーを検討してください。多くの場合、East/West トラフィックと呼ばれます。

ポッドごとにセキュリティグループとの非互換性を特定する

Windows ベースのインスタンスと非ニトロインスタンスは、ポッドのセキュリティグループをサポートしていません。Pods でセキュリティグループを使用するには、インスタンスに のタグを付ける必要があります isTrunkingEnabled。ポッドが 内外AWSのサービスに依存していない場合は、セキュリティグループではなく、ネットワークポリシーを使用してポッド間のアクセスを管理しますVPC。

ポッドあたりのセキュリティグループを使用して、AWSサービスへのトラフィックを効率的に制御する

EKS クラスター内で実行されているアプリケーションが、RDSデータベースなどVPC、 内の別のリソースと通信する必要がある場合は、 をポッドSGsに使用することを検討してください。CIDR または DNS 名を指定できるポリシーエンジンはありますが、 内にエンドポイントがあるAWSサービスと通信するときは最適ではありませんVPC。

対照的に、Kubernetes ネットワークポリシーは、クラスター内外の進入トラフィックと進出トラフィックを制御するメカニズムを提供します。アプリケーションが他の AWS サービスへの依存関係を制限している場合は、Kubernetes ネットワークポリシーを検討する必要があります。のようなAWSネイティブセマンティクスではなく、CIDR範囲に基づいてエグレスルールを指定するネットワークポリシーを設定して、AWSサービスへのアクセスを制限できますSGs。Kubernetes ネットワークポリシーを使用して、ポッド間 (多くの場合、東部/西部トラフィック) およびポッドと外部サービス間のネットワークトラフィックを制御できます。Kubernetes ネットワークポリシーはOSIレベル 3 と 4 で実装されます。

Amazon EKS では、Calico や Cilium などのネットワークポリシーエンジンを使用できます。デフォルトでは、ネットワークポリシーエンジンはインストールされません。設定方法については、それぞれのインストールガイドを参照してください。ネットワークポリシーの使用方法の詳細については、EKS「セキュリティのベストプラクティス」を参照してください。DNS ホスト名機能は、エンタープライズバージョンのネットワークポリシーエンジンで使用できます。これは、Kubernetes サービス/ポッドと の外部で実行されるリソース間のトラフィックを制御するのに役立ちますAWS。また、デフォルトでセキュリティグループをサポートしていないAWSサービスのDNSホスト名サポートを検討することもできます。

AWS Loadbalancer Controller を使用するように単一のセキュリティグループにタグ付けする

Pod に多くのセキュリティグループが割り当てられている場合、Amazon はkubernetes.io/cluster/$name共有または所有されている単一のセキュリティグループにタグ付けEKSすることをお勧めします。タグを使用すると、AWSLoadbalancer Controller はセキュリティグループのルールを更新して、トラフィックを Pods にルーティングできます。Pod に 1 つのセキュリティグループのみが付与されている場合、タグの割り当てはオプションです。セキュリティグループで設定されたアクセス許可は追加されるため、ロードバランサーコントローラーがルールを見つけて調整するには、単一のセキュリティグループにタグ付けするだけで十分です。また、セキュリティグループで定義されているデフォルトのクォータに従うのにも役立ちます。

アウトバウンドトラフィックNAT用に を設定する

セキュリティグループが割り当てられている Pod からのアウトバウンドトラフィックでは、ソースNATは無効になっています。NAT ゲートウェイまたはインスタンスで設定されたプライベートサブネット上のインターネット起動ワーカーノードへのアクセスを必要とするセキュリティグループを使用する Pod の場合、 で外部SNATを有効にしますCNI。

kubectl set env daemonset -n kube-system aws-node AWS_VPC_K8S_CNI_EXTERNALSNAT=true

セキュリティグループを含むポッドをプライベートサブネットにデプロイする

セキュリティグループが割り当てられているポッドは、プライベートサブネットにデプロイされているノードで実行する必要があります。パブリックサブネットにデプロイされたセキュリティグループが割り当てられたポッドは、インターネットにアクセスできないことに注意してください。

ポッド仕様ファイルでterminationGracePeriod秒を確認する

Pod 仕様ファイルで terminationGracePeriodSecondsがゼロ以外であることを確認します (デフォルトは 30 秒）。これは、Amazon がワーカーノードから Pod ネットワークVPCCNIを削除するには不可欠です。ゼロに設定すると、CNIプラグインはホストから Pod ネットワークを削除せず、ブランチENIは効果的にクリーンアップされません。

Fargate での Pod のセキュリティグループの使用

Fargate で実行される Pod のセキュリティグループは、EC2ワーカーノードで実行される Pod と非常によく似ています。例えば、Fargate Pod SecurityGroupPolicy に関連付ける でセキュリティグループを参照する前に、セキュリティグループを作成する必要があります。デフォルトでは、Fargate Pod に を明示的に割り当てない場合、クラスターセキュリティグループはすべての Fargate Pod SecurityGroupPolicy に割り当てられます。簡単にするために、クラスターセキュリティグループを 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 Pods は kube-apiserver、kubelet、Core などのクラスター内サービスと通信できますDNS。また、Fargate Pod とのインバウンド接続とアウトバウンド接続を許可するルールを追加する必要があります。これにより、Pod は 内の他の Pod またはリソースと通信できるようになりますVPC。さらに、Fargate が Amazon ECRまたは などの他のコンテナレジストリからコンテナイメージをプルするためのルールを含める必要があります DockerHub。詳細については、「 全般のリファレンス」のAWS「IP アドレス範囲」を参照してください。 AWS

次のコマンドを使用して、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

📝 でこのページを編集する GitHub