EKS Auto Mode でネットワークポリシーを使用する

概要

お客様が EKS を使用してアプリケーション環境をスケールするにつれて、クラスター内外のリソースへの不正アクセスを防ぐ必要があり、そのためにはネットワークトラフィックの分離がますます欠かせないものになります。これは、クラスター内で互いに関連性のない複数のワークロードが並行して動作するマルチテナント環境で特に重要です。Kubernetes ネットワークポリシーを使用すると、Kubernetes ワークロードのネットワークセキュリティ体制を強化し、それをクラスター外のエンドポイントと強固に統合できます。EKS 自動モードは、さまざまなタイプのネットワークポリシーをサポートしています。

レイヤー 3 と 4 の分離

標準の Kubernetes ネットワークポリシーは OSI ネットワークモデルのレイヤー 3 と 4 で動作し、Amazon EKS クラスター内の IP アドレスまたはポートレベルでトラフィックフローを制御できます。

ユースケース

ワークロード間でネットワークトラフィックをセグメント化すると、関連するアプリケーションのみが相互に通信できるようになります。
ポリシーを使用して名前空間レベルでテナントを分離すると、ネットワークを分離できます。

DNS ベースの適用

お客様が EKS にデプロイするワークロードはより広範な分散環境に属しているのが一般的で、その中にはクラスター外のシステムやサービスとの通信を必要とするものもあります (インバウンドトラフィック)。こうしたシステムやサービスは、AWS クラウド内にあっても AWS 外にあってもかまいません。ドメインネームシステム (DNS) ベースのポリシーを使用すると、予測精度の高い安定したアプローチに沿って、ポッドからクラスター外のリソースやエンドポイントへの不正アクセスを防ぎ、セキュリティ体制を強化できます。このメカニズムにより、特定の IP アドレスを手動で追跡して許可リストに登録する必要がなくなります。DNS ベースのアプローチに沿ってリソースを保護することで、アップストリームサーバーやホストを変更する際にセキュリティ体制を緩和することも、ネットワークポリシーを変更することもなく、柔軟に外部インフラストラクチャを更新できます。完全修飾ドメイン名 (FQDN)、または DNS ドメイン名に一致するパターンを使用すると、外部エンドポイントへの出力トラフィックをフィルタリングできます。これにより、クラスター外の特定のエンドポイントに複数のサブドメインが関連付けられている場合に、各サブドメインへのアクセスを柔軟に拡張できます。

ユースケース

Kubernetes 環境からクラスター外のエンドポイントへのアクセスをフィルタリングする場合には、DNS ベースのアプローチを標準とします。
マルチテナント環境で AWS サービスへのアクセスを保護します。
ハイブリッドクラウド環境でポッドからオンプレミスワークロードへのネットワークアクセスを管理します。

管理者 (またはクラスター範囲の) ルール

マルチテナントシナリオのように、ネットワークセキュリティ標準をクラスター全体に適用しなければならないという要件が求められる場合があります。名前空間ごとにポリシーを繰り返し定義して維持するのではなく、単一のポリシーを使用して、名前空間に関係なく、クラスター内のさまざまなワークロードに対するネットワークアクセスコントロールを一元管理できます。こうしたタイプのポリシーでは、レイヤー 3、レイヤー 4、および DNS ルールの使用時に適用されるネットワークフィルタリングルールの適用範囲を拡張できます。

ユースケース

EKS クラスター内のすべての (または一部の) ワークロードに対するネットワークアクセスコントロールを一元管理します。
クラスター全体にわたるデフォルトのネットワークセキュリティ体制を定義します。
組織のセキュリティ標準を運用効率の高い方法でクラスターの範囲へと拡張します。

開始方法

前提条件

EKS Auto Mode が有効になっている Amazon EKS クラスター
kubectl がクラスターに接続するように設定されている

ステップ 1: ネットワークポリシーコントローラーを有効にする

EKS Auto Mode でネットワークポリシーを使用するには、まずクラスターに ConfigMap を適用してネットワークポリシーコントローラーを有効にする必要があります。

以下の内容で enable-network-policy.yaml という名前のファイルを作成します。


apiVersion: v1
kind: ConfigMap
metadata:
  name: amazon-vpc-cni
  namespace: kube-system
data:
  enable-network-policy-controller: "true"

ConfigMap をクラスターに適用します。
```
kubectl apply -f enable-network-policy.yaml
```

ステップ 2: ノードクラスでネットワークポリシーを有効にする

ネットワークポリシーを使用するには、ノードクラスがそれらをサポートするように設定する必要があります。以下の手順に従ってください。

次の内容でノードクラス YAML ファイル (例: nodeclass-network-policy.yaml) を作成または編集します。


apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: network-policy-enabled
spec:
  # Enables network policy support
  networkPolicy: DefaultAllow
  # Optional: Enables logging for network policy events
  networkPolicyEventLogs: Enabled
  # Include other Node Class configurations as needed

ノードクラス設定をクラスターに適用します。
```
kubectl apply -f nodeclass-network-policy.yaml
```
ノードクラスが作成されていることを確認します。
```
kubectl get nodeclass network-policy-enabled
```
このノードクラスを使用するようにノードプールを更新します。詳細については、「EKS 自動モードl 用のノードプールを作成する」を参照してください。

ノードがこのノードクラスを使用していると、ネットワークポリシーを適用できるようになります。これで、クラスター内のトラフィックを制御するネットワークポリシーの作成と適用に進むことができます。すべてのノードクラス設定オプションについては、「Amazon EKS のノードクラスを作成する」を参照してください。

ステップ 3: ネットワークポリシーを作成してテストする

これで、EKS Auto Mode クラスターが Kubernetes ネットワークポリシーをサポートするように設定されました。これは Amazon EKS のネットワークポリシーの星型デモでテストできます。

動作の仕組み

DNS ベースのネットワークポリシー

プラットフォームチームが、DNS ベースのポリシーを EKS クラスターに適用します。
ネットワークポリシーコントローラーが、クラスター内でのポリシーの作成をモニタリングし、ポリシーエンドポイントを調整します。このユースケースの場合、ネットワークポリシーコントローラーは、作成されたポリシーの許可リストに登録されたドメインに基づいて DNS リクエストをフィルタリングするようにノードエージェントに指示します。ドメイン名を許可リストに登録する場合は、FQDN を使用するか、Kubernetes リソース設定に定義されたパターンと一致するドメイン名を使用します。
ワークロード A が、クラスター外のエンドポイントの IP を解決しようとします。DNS リクエストはまずプロキシを通過します。その際に、ネットワークポリシーで適用された許可リストに基づいて該当するリクエストがフィルタリングされます。
DNS フィルター許可リストを通過した DNS リクエストは、CoreDNS にプロキシされます。
CoreDNS は、受け取ったリクエストを外部 DNS リゾルバー (Amazon Route 53 Resolver) に送信して、ドメイン名の背後にある IP アドレスのリストを取得します。
解決した IP が TTL と共に、DNS リクエストへのレスポンスで返されます。こうして解決した IP が eBPF マップに書き込まれて、次のステップで IP レイヤーを適用する際に使用されます。
ポッドの veth インターフェイスにアタッチされた eBPF プローブが、所定のルールに基づいて、ワークロード A からクラスター外のエンドポイントへのエグレストラフィックをフィルタリングします。これにより、ポッドは許可リストに登録されたドメインの IP にのみクラスター外のトラフィックを送信できるようになります。こうした IP の有効性は、外部 DNS リゾルバー (Amazon Route 53 Resolver) から取得した TTL に基づいています。

ApplicationNetworkPolicy を使用する

ApplicationNetworkPolicy は、単一のカスタムリソース定義 (CRD) を使用して、標準の Kubernetes ネットワークポリシーの機能と DNS ベースのフィルタリングを名前空間レベルで結合します。そのため、ApplicationNetworkPolicy は以下の用途に使用できます。

IP ブロックとポート番号を使用して、ネットワークスタックのレイヤー 3 と 4 に制限内容を定義します。
ネットワークスタックのレイヤー 7 で機能するルールを定義し、FQDN に基づいてトラフィックをフィルタリングします。

重要な注記: ApplicationNetworkPolicy を使用して定義した DNS ベースのルールは、EKS 自動モードで起動された EC2 インスタンスで動作するワークロードにのみ適用できます。

例

EKS 自動モードクラスターにワークロードがあり、DNS 名が付与されたロードバランサーの背後にあるオンプレミスのアプリケーションと通信する必要があります。そのために、次のネットワークポリシーを使用します。


apiVersion: networking.k8s.aws/v1alpha1
kind: ApplicationNetworkPolicy
metadata:
  name: my-onprem-app-egress
  namespace: galaxy
spec:
  podSelector:
    matchLabels:
      role: backend
  policyTypes:
  - Egress
  egress:
  - to:
    - domainNames:
      - "myapp.mydomain.com"
    ports:
    - protocol: TCP
      port: 8080

Kubernetes ネットワークレベルでは、role: backend というラベルが付いた「galaxy」名前空間内のポッドからのエグレスが、TCP ポート 8080 で myapp.mydomain.com というドメイン名に接続できるようになります。また、VPC から社内のデータセンターへのエグレストラフィック用にネットワーク接続をセットアップする必要があります。

管理者 (あるいはクラスター) ネットワークポリシー

ClusterNetworkPolicy を使用する

ClusterNetworkPolicy を使用する場合、管理者階層ポリシーが最初に評価され、このポリシーを上書きすることはできません。管理者階層ポリシーが評価されたら、名前空間範囲の標準ポリシーに従って、適用したネットワークセグメンテーションルールが実行されます。そのためには、ApplicationNetworkPolicy または NetworkPolicy を使用します。最後に、ベースライン階層ルールが適用されます。ここには、クラスターワークロードに対するデフォルトのネットワーク制限が定義されています。こうしたベースライン階層ルールは、必要に応じて名前空間範囲のポリシーで上書きできます。

例

クラスター内にアプリケーションがあり、これを他のテナントワークロードから分離する必要があります。他の名前空間からクラスタートラフィックを明示的にブロックすると、機密性の高いワークロード名前空間へのネットワークアクセスを防ぐことができます。


apiVersion: networking.k8s.aws/v1alpha1
kind: ClusterNetworkPolicy
metadata:
  name: protect-sensitive-workload
spec:
  tier: Admin
  priority: 10
  subject:
    namespaces:
      matchLabels:
        kubernetes.io/metadata.name: earth
  ingress:
    - action: Deny
      from:
      - namespaces:
          matchLabels: {} # Match all namespaces.
      name: select-all-deny-all

考慮事項

ポリシー評価順序を理解する

EKS でサポートされているネットワークポリシー機能は、トラフィックを予測して安全に管理できるように、特定の順序で評価されます。そのため、評価の流れを理解したうえで、ご使用の環境に適した効果的なネットワークセキュリティ体制を設計することが重要です。

管理者層ポリシー (最初に評価): 管理者階層のすべての ClusterNetworkPolicy が他のポリシーよりも先に評価されます。管理者階層内では、優先順位に従って (優先順位番号の最も小さいものから) ポリシーが処理されます。次にどうなるかは、アクションタイプによって決まります。
- 拒否アクション (最も高い優先順位): 拒否アクションを定義した管理者ポリシーがトラフィックと一致すると、そのトラフィックは他のポリシーとは関係なくすぐにブロックされます。ClusterNetworkPolicy や NetworkPolicy ルールはそれ以上処理されません。これにより、組織全体のセキュリティコントロールを名前空間レベルのポリシーで上書きできないようにしています。
- 許可アクション: 拒否ルールが評価されると、許可アクションを定義した管理者ポリシーが優先順位に従って (優先順位番号の最も小さいものから) 処理されます。許可アクションに一致すると、トラフィックは受け入れられ、ポリシーはそれ以上評価されません。これらのポリシーは、ラベルセレクターに基づいて複数の名前空間に対するアクセスを許可して、特定のリソースにどのワークロードがアクセスできるかを一元的に制御できます。
- パスアクション: 管理階層ポリシーにパスアクションを定義すると、意思決定が下位の階層に委任されます。トラフィックがパスルールに一致すると、そのトラフィックの残りの管理者階層ルールの評価がスキップされ、NetworkPolicy 階層に直接進みます。これにより、管理者は特定のトラフィックパターンに対する制御をアプリケーションチームに明示的に委任できます。例えば、パスルールを使用すると、外部アクセスを厳密に制御しつつ、名前空間内のトラフィック管理を名前空間管理者に委任できます。
ネットワークポリシー階層: 拒否または許可に一致する管理者階層ポリシーがない場合や、パスアクションが一致した場合、次は名前空間範囲の ApplicationNetworkPolicy と従来の NetworkPolicy リソースが評価されます。これらは個々の名前空間内できめ細かく制御できるポリシーで、アプリケーションチームによって管理されます。名前空間範囲のポリシーでは、管理者ポリシーよりも厳しく制限を課すことができます。管理者ポリシーによる拒否の判断を上書きすることはできませんが、管理者ポリシーによって許可またはパスされたトラフィックをさらに制限できます。
ベースライン階層管理ポリシー: トラフィックに一致する管理者ポリシーや名前空間範囲のポリシーがない場合、ベースライン階層の ClusterNetworkPolicy が評価されます。これにより、デフォルトのセキュリティ体制を名前空間範囲のポリシーで上書きできるため、管理者が組織全体のデフォルトを設定する一方で、チームが必要に応じて柔軟にカスタマイズできます。ベースラインポリシーは、優先順位に従って (優先順位番号の最も小さいものから) 評価されます。
デフォルト拒否 (一致するポリシーがない場合): この deny-by-default 動作により、明示的に認められた接続のみが許可されるため、強力なセキュリティ体制を維持できます。

最小特権の原則を適用する

制限ポリシーから開始し、必要に応じて徐々にアクセス許可を追加する - まずはクラスターレベルで deny-by-default ポリシーを実装し、次に正当な接続要件の検証に合わせて許可ルールを段階的に追加していきます。このアプローチにより、チームは外部接続ごとにその正当性を明示的に評価して、より安全で監査可能な環境を構築できるようになります。
未使用のポリシールールを定期的に監査して削除する - ネットワークポリシーは、アプリケーションの進化に伴い時間が経つにつれて増えていきます。そのために、古いルールが残ってアタックサーフェスが不必要に拡大する可能性があります。ポリシールールを定期的に見直すプロセスを実装して、不要になったものを特定して削除するようにすると、厳格で管理しやすいセキュリティ体制を維持できます。
可能であれば、広範なパターンではなく特定のドメイン名を使用する - *.amazonaws.com のようなワイルドカードパターンは便利ですが、同時に幅広いサービスへのアクセスも許可することになります。可能な限り、s3.us-west-2.amazonaws.com のような厳密なドメイン名を指定して、アプリケーションが必要とする特定のサービスにのみアクセスを制限して、ワークロードが侵害された場合に横展開されるリスクを軽減します。

EKS での DNS ベースのポリシーを使用する

ApplicationNetworkPolicy を使用して定義した DNS ベースのルールは、EKS 自動モードで起動された EC2 インスタンスで動作するワークロードにのみ適用できます。混合モードクラスター (EKS 自動ワーカーノードと非 EKS 自動ワーカーノードの両方で構成) を実行している場合、DNS ベースのルールは EKS 自動モードのワーカーノード (EC2 マネージドインスタンス) でのみ有効です。

DNS ポリシーを検証する

ステージングクラスターを使用してテスト用に本番稼働のネットワークトポロジをミラーリングする - ステージング環境では、ポリシーを正確にテストできるように、本番稼働のネットワークアーキテクチャ、外部依存関係、および接続パターンをレプリケートする必要があります。例えば、VPC 設定、DNS 解決動作、本番稼働のワークロードで必要になるのと同じ外部サービスへのアクセスを一致させます。
重要なネットワークパスを自動的にテストする機能を実装する - CI/CD パイプラインの一部として、必要不可欠な外部サービスへの接続を検証する自動テストを構築します。自動テストでは、正当なトラフィックフローは許可され、不正な接続はブロックされることを検証します。インフラストラクチャが進化しても、ネットワークポリシーにより、正しいセキュリティ体制が維持されていることを継続的に検証する必要があります。
ポリシーが変更されたらアプリケーションの動作をモニタリングする - 新規または変更後のネットワークポリシーを本番稼働にデプロイしたら、アプリケーションログ、エラー率、パフォーマンスメトリクスを注意深くモニタリングして、接続の問題があればすばやく特定できるようにします。明確なロールバック手順を確立して、予期しないアプリケーションの動作やサービスの中断が発生したら、ポリシーへの変更をすばやく元に戻せるようにします。

Amazon Route 53 DNS ファイアウォールとのインタラクション

EKS 管理者ポリシーとネットワークポリシーは、トラフィックの開始時にポッドレベルで最初に評価されます。EKS ネットワークポリシーで特定のドメインへのエグレスを許可している場合、ポッドは Route 53 Resolver に到達する DNS クエリを実行します。この時点で、Route 53 DNS ファイアウォールルールが評価されます。DNS ファイアウォールがドメインクエリをブロックしている場合、EKS ネットワークポリシーで許可していたとしても、DNS 解決は失敗し、接続を確立できません。そのため、セキュリティレイヤーをいくつか作成して補完します。EKS DNS ベースのネットワークポリシーではアプリケーションに固有のアクセス要件とマルチテナントセキュリティ境界に応じてポッドレベルでエグレスを制御し、DNS ファイアウォールでは既知の悪意のあるドメインから VPC 全体を保護して組織全体のブロックリストを適用します。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

重要なアドオンを実行する

サブネットにタグを付ける