Kubernetesとネットワークセキュリティ

Kubernetes Network Policies

最後に、コンテナアプリケーションのレイヤで実装できるネットワーク制御の手法として Network Policy について紹介します。Network Policy とは Pod 間の通信、Pod と外部との通信の可否を制御するための仕組みです。

デフォルトでは、AKS クラスタ内ではすべての Pod が制限なく通信することが可能になっていますが、セキュリティ向上の目的で Network Policy のルールを定義してトラフィックフローを制御できます。Network Policy のルールは YAML フォーマットで記述します。

ラベルセレクタを利用して対象としたい Pod や Namespace を選択し、ingress（内向き）またはegress（外向き）の通信の許可・拒否を定義します。

通常、これらルールを複数束ねてルールセットの形で適用します。AKS では以下の2種類の Network Policy の実装が利用可能ですが、サポートする CNI ネットワークプラグインの種類やサポート形態に違いがある点に注意してください。

• Azure ネットワークポリシー
• Calico ネットワークポリシー

Azure ネットワークポリシーは Azure CNI ネットワークモデルのみに対応しており、Azureサポートおよびエンジニアリングチームにてサポートされます。一方、Calico は Azure CNI と kubenet の両方のネットワークモデルで利用できますが、原則的にコミュニティによるサポートとなります。

基本的な使い方としては、トラフィック制御をかけたい対象リソースを Namespace やラベルや Pod 名で特定し、さまざまな送受信に関する許可・拒否のルールを定義して適用するという流れとなります。

定義するルールの一例

• 特定ラベルを持つ Pod からのみ受信を許可(ingress)
• 特定 namespace からのみ受信を許可(ingress)
• インターネットへの送信を許可(egress)
• Node への接続・通信を拒否(egress)

典型的な運用の例としては、まずベースラインとしてすべてのトラフィックを拒否(All Deny)するルールを定義したうえで、明示的に許可ルールを追加で定義する、などの方策が挙げられます。

これにより、明示的に許可されていない送受信トラフィックはすべて想定外のアクセスとして扱われ拒否されるので、不測の事故を未然に防止できるといった効果が期待できるでしょう。

デフォルトでは Network Policy は適用されていないため、任意の送受信が許可されています。必ずしもすべての組織において Network Policy を利用しなければならないということはありませんが、コンテナアプリケーションの粒度でトラフィック制御が容易に実現したいようなケースでは採用を検討してみても良いでしょう。

Nerwork Policy定義ルールの例

次の例では、"role=db" のラベルを持つ Pod を対象とするルールを定義しています。

受信方向では Pod の TCP 6379 番ポートへの接続に関して、 "role=frontend" のラベルを持ち、かつ、 172.17.0.0/16 の範囲の IP アドレスからの接続のみを許可しています。

また送信方向については、前回の最後に紹介した IMDS(Instance Metadata Service) と呼ばれる、仮想マシンのメタデータや Managed Identity データの取得時にアクセスする 169.254.169.254 の IP アドレスへの通信を拒否して、それ以外の通信を許可するというルールを定義しています。

このように、コントロールプレーンや Node のようなクラスタを構成するリソースのレイヤと合わせて、コンテナアプリケーションが稼働する Pod のレイヤでも悪意のある攻撃からの保護が可能です。

```
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379
  egress:
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
        except:
        - 169.254.169.254/32
```

まとめ

ネットワークセキュリティの観点では、クラスタ環境の構成に応じた各種クラウドリソースや Kubernetesのエンドポイントの発見および侵入といった攻撃に特に注意する必要があり、本稿では AKS を題材として、そのネットワーク構成と防御の手法について解説してきました。

第1回でも紹介した MITRE ATT&CK フレームワークをベースとした Kubernetesの脅威マトリクスのようなナレッジベースなども、本稿と合わせて参照いただきつつ、脅威のモデル化や対策立案の一助としていただければ幸いです。