Amazon EKS のネットワークポリシー機能を強化

この記事は Amazon EKS introduces enhanced network policy capabilities (記事公開日: 2025 年 12 月 15 日) を翻訳したものです。

2025 年 12 月に、Amazon EKS におけるネイティブなネットワークポリシーのサポートを拡張し、Admin Policy と Application Network Policy の両方に対応したことを発表しました。これらの追加されたポリシーにより、クラスター管理者 (プラットフォームチームやセキュリティチームなど) は、Kubernetes ワークロード全体のネットワークセキュリティを強化するために、クラスター全体に適用されるセキュリティルールを設定できます。

さらに、Namespace の管理者 (アプリケーションチームなど) は、ドメイン名をフィルターとして使用して、外部リソースへの Pod のトラフィックを制御できるようになりました。この方法は、頻繁に変化する特定の IP アドレスのリストや、企業のセキュリティポリシーとしばしば衝突する広範な CIDR ブロックの範囲を管理する必要性をなくし、代わりに Pod がアクセスを許可される外部のウェブサイトやサービスの信頼済みリストを作成できるようにします。これは、クラスターのアウトバウンドトラフィックに対する「許可された宛先」リストと考えることができます。

クラスター内の標準的な Kubernetes のネットワークポリシーを使用すると、仮想ファイアウォールを実装してクラスター内のネットワークトラフィックを分割できます。これらのポリシーにより、受信 (Ingress) と送信 (Egress) の両方のトラフィックを制御するルールを作成できます。Pod ラベル、Namespace、IP アドレスの範囲 (CIDR)、特定のポートなど、いくつかのパラメーターに基づいて通信を制限できます。

この種のネットワークポリシーの例を以下に示します。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: webapp-egress-policy
  namespace: sun
spec:
  podSelector:
    matchLabels:
      role: webapp
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          name: moon
      podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 8080
  - to:
    - namespaceSelector:
        matchLabels:
          name: stars
      podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 8080

上記のポリシーでは、sun Namespace 内の webapp Pod からのアウトバウンドトラフィックが制限されます。

このポリシーの適用対象: sun Namespace 内のラベル role: webapp を持つ Pod。許可されるアウトバウンドトラフィック:

moon Namespace 内のラベル role: frontend を持つ Pod への TCP ポート 8080 での通信
stars Namespace 内のラベル role: frontend を持つ Pod への TCP ポート 8080 での通信
ブロックされるトラフィック: webapp Pod からのその他すべてのアウトバウンドトラフィックは暗黙的に拒否されます。

これにより、次のトラフィックフローが生まれます。

ネットワークポリシーは Kubernetes のデフォルトの「すべて許可」の通信設定を改善しますが、いくつかの重要な制限があります。

個々の Namespace 内のトラフィックしか制御できず、クラスター全体にまたがる制御はできません。
ネットワークポリシーには明示的な「拒否」ルールがありません。
ネットワークポリシーの目的は、ネットワークトラフィックのフローを制限することで、誰が自分のアプリケーションと通信できるかをアプリケーション所有者が制御できるようにすることです。

言い換えると、標準のネットワークポリシーは各アプリケーションチームが自分たちのセキュリティルールを管理する場合には適していますが、次のような要件がある状況のために作られたものではありません。

クラスター全体に適用されるセキュリティルール
他者のセキュリティ設定を上書きする機能
一部のポリシーが他のポリシーより優先されるルールの階層

このため、集中管理されたセキュリティ制御や、より複雑なセキュリティ構成を必要とする組織には適していません。

Admin Network Policy とは

Admin Network Policy は、クラスター管理者が、ワークロードが稼働する Namespace に関係なく、クラスター内のすべての EKS ワークロードのトラフィック分離を一元管理し、組織のセキュリティ要件に合わせられるように設計されています。

Amazon VPC CNI を使用する Amazon EKS では、単一の CustomResourceDefinition (CRD) オブジェクトを使用して、クラスター全体に適用される 2 種類のネットワークポリシー、Admin Tier と Baseline Tier をサポートするようになりました。

EKS Auto Mode クラスターを運用している場合は、さらにドメイン名フィルタリングを活用して、ドメイン名を使用して宛先へのトラフィックを許可できます。

Kubernetes のドキュメントによれば、Kubernetes の Admin Network Policy は次のように評価されます。

これはつまり、Admin Tier のポリシーが最初に評価され、上書きできないということです。Admin Tier のポリシーが評価された後、標準の NetworkPolicy を使用して、Namespace またはアプリケーション所有者が望むネットワークの分離が実行されます。最後に、クラスターワークロードのデフォルトの接続性を記述する Baseline Tier のルールが適用されます。このルールは、必要に応じて開発者の NetworkPolicy によって上書きできます。

次のシナリオは、ポリシー評価の階層を示しています。

Admin Tier が「外部インターネットへのアクセスを禁止する」と指定している (上書き不可)。
開発者が「インターネットへのアクセスを許可する」という NetworkPolicy を作成する (Admin ルールによってブロックされる)。
Baseline Tier が「内部通信を許可する」と指定している (ネットワークポリシーによって上書き可能)。

Admin Policy の例

次の例は、Admin Network Policy の一般的なユースケースを示しています。

ユースケース 1: 機密性の高いワークロードの分離

クラスターレベルで Namespace を分離します。たとえば、機密性の高いワークロードがある場合、他の Namespace からのクラスタートラフィックが、その機密性の高いワークロードの Namespace に入らないように明示的にブロックしたい場合があります。

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: {} # すべての Namespace に一致させる。
      name: select-all-deny-all

これにより、次に示すように、他の Namespace からその Namespace へのすべてのトラフィックがブロックされます。

ユースケース 2: 集中モニタリングアクセスの強制

ローカルのネットワークポリシーがワークロードの可視性を誤ってブロックしないように、集中モニタリングソリューションからすべての Namespace へのアクセスを強制します。
標準の EKS クラスターで、すべての Namespace から kube-system Namespace で稼働している kube-dns への Egress を明示的に許可します。

これを実現するには、次に示すようなネットワークポリシーを記述できます。

apiVersion: networking.k8s.aws/v1alpha1
kind: ClusterNetworkPolicy
metadata:
  name: cluster-wide-allow-example
spec:
  tier: Admin
  priority: 30
  subject:
    namespaces: {}
  ingress:
    - action: Accept
      name: allow-monitoring-ns-ingress
      from:
      - namespaces:
          matchLabels:
            kubernetes.io/metadata.name: monitoring
  egress:
  - action: Accept
    name: allow-kube-dns-egress
    to:
    - pods:
        namespaceSelector:
          matchLabels:
            kubernetes.io/metadata.name: kube-system
        podSelector:
          matchLabels:
            k8s-app: kube-dns

これにより、すべての Namespace が monitoring Namespace からの受信トラフィックを受け入れ、kube-system Namespace に存在する kube-dns のラベルが付いた Pod への Egress を許可するよう強制され、次のトラフィックフローが生まれます。

Application Network Policy とは

Application Network Policy は、従来のネットワークポリシーと DNS フィルタリングを、Namespace を認識する単一の Custom Resource Definition (CRD) に統合することで、Amazon EKS Auto Mode クラスターのネットワークトラフィックの制御を支援します。これは、Pod が EKS クラスター外のリソースにどのように接続するかを制御する必要がある場合に特に便利です。たとえば、Pod が特定のドメイン名にのみアクセスできるようにする場合などです。

Application Network Policy と通常のネットワークポリシーの違い

標準のネットワークポリシーは OSI モデルのレイヤー 3 とレイヤー 4 で動作するため、トラフィックの宛先を制御するには IP ブロックとポート番号を使用するしかありません。しかし、Application Network Policy は OSI モデルのレイヤー 7 でも動作し、完全修飾ドメイン名 (FQDN) に基づいてトラフィックをフィルタリングできます。つまり、次のようなシナリオで Pod からの Egress を管理するのに最適です。

クラウドからオンプレミスへの通信

IP アドレスのリストを管理する代わりに、ドメイン名 (FQDN) を使用するだけで済みます。背後で IP アドレスが変わっても、ポリシーは更新を必要とせずに機能し続けます。たとえば、特定の IP アドレスではなく「internal-api.company.com」を使用するだけです。

SaaS サービスへのアクセス

多くの SaaS プロバイダーは IP アドレスを定期的に変更するため、IP ベースのフィルタリングは実用的ではありません。Application Network Policy は、代わりにドメイン名を使用してルールを作成できるようにすることで、この問題を解決します。たとえば次のとおりです。

"allow traffic to *.salesforce.com"
"allow traffic to *.slack.com"

Application Network Policy の例

EKS Auto Mode クラスターにデプロイされたアプリケーションが、データセンター内のオンプレミスアプリケーションと通信する必要があるとします。このオンプレミスアプリケーションは、DNS 名を持つロードバランサーの背後にあります。

これを実現するには、次に示すような Application Network Policy を記述できます。

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

Kubernetes のネットワークレベルでは、これにより、以下に示すように、「moon」Namespace 内の role: backend のラベルが付いたすべての Pod から、ドメイン名 myapp.mydomain.com への TCP ポート 8080 での Egress が許可されます。また、VPC の外に出て (場合によっては AWS Transit Gateway を経由して) 企業のデータセンターにアクセスできるように、ネットワーク接続を設定する必要もあります。

まとめ

Amazon EKS クラスターで利用できる新しいネイティブなネットワーク制御を発表します。これにより、Amazon EKS 内でクラスターレベルのネットワーク制御をネイティブに適用できるようになり、Amazon EKS Auto Mode クラスターではクラスターレベルと Namespace レベルの両方で FQDN を使用してアウトバウンドアクセスをフィルタリングできるようになります。

これらの新しいネットワーク制御の使用を開始するには、次の要件を確認してください。

これらの機能を使用するには、クラスターで Kubernetes バージョン 1.29 以降が稼働している必要があります。
これらの制御は、新しい EKS クラスターと既存の EKS クラスターの両方で使用できます。(訳注: 原文の公開後に、既存のクラスターにも対応しました。)
標準の EKS クラスターで ClusterNetworkPolicy を使用するには、Amazon VPC CNI プラグインの v1.21.1 以降が稼働していることを確認してください。
EKS Auto Mode (v1.29 以降) を実行している場合は、ClusterNetworkPolicy と ApplicationNetworkPolicy (Auto Mode 専用) の両方を使用できます。DNS ベースのポリシーは EKS Auto Mode によって起動された EC2 インスタンスでのみサポートされます。

標準の EKS クラスターでネットワークポリシーを有効にして Admin 制御を適用するには、AWS のドキュメントを参照してください。EKS Auto Mode クラスターでネットワークポリシーを有効にするには、こちらの AWS のドキュメントを参照してください。

翻訳はシニアパートナーソリューションアーキテクトの市川が担当しました。原文はこちらです。

Amazon Web Services ブログ

Amazon EKS のネットワークポリシー機能を強化

Admin Network Policy とは

Admin Policy の例

Application Network Policy とは

Application Network Policy と通常のネットワークポリシーの違い

Application Network Policy の例

まとめ

お役立ちリンク

フォローお願いいたします

学ぶ

リソース

デベロッパー

ヘルプ