📗
owasp-kubernetes-top-ten-ja
  • OWASP Kubernetes Top Ten ja
  • OWASP Kubernetes Top 10 日本語版
    • 概要
    • リーダー
    • OWASP Kubernetes Top 10
      • K00:2022 Kubernetes Security Top Ten へようこそ
      • K01:2022 安全でないワークロード設定
      • K02:2022 サプライチェーンの脆弱性
      • K03:2022 過度に許可を与える RBAC 設定
      • K04:2022 一元化されたポリシー施行の欠如
      • K05:2022 不十分なログ記録と監視
      • K06:2022 認証メカニズムの不備
      • K07:2022 ネットワークセグメンテーションコントロールの欠落
      • K08:2022 機密管理の不備
      • K09:2022 クラスタコンポーネントの設定ミス
      • K10:2022 古くて脆弱な Kubernetes コンポーネント
      • その他考慮すべきリスク
Powered by GitBook
On this page
  • 概要
  • 説明
  • 防止方法
  • 攻撃シナリオの例
  • 参考資料
  1. OWASP Kubernetes Top 10 日本語版
  2. OWASP Kubernetes Top 10

K07:2022 ネットワークセグメンテーションコントロールの欠落

PreviousK06:2022 認証メカニズムの不備NextK08:2022 機密管理の不備

Last updated 4 months ago

概要

複数のマイクロサービスやテナントで Kubernetes を運用する場合、重要な懸念事項はネットワークトラフィックのコントロールです。 Kubernetes クラスタのコンテキスト内でトラフィックを分離することはポッド、名前空間、ラベルなどの間のいくつかのレベルで行われます。

説明

Kubernetes ネットワークはデフォルトでフラットです。 つまり、追加のコントロールが行われていない場合、どのワークロードも制約なしで別のワークロードと通信できます。 実行中のワークロードを悪用する攻撃者は、このデフォルトの動作を利用して内部ネットワークを調べたり、他の実行中のコンテナに移動したり、プライベート API を呼び出したりできます。

防止方法

クラスタ内のワークロードはいずれは互いにだけでなく、さまざまな内外のエンドポイントとも通信する必要があります。 Kubernetes 内のネットワークセグメンテーションの目標は、コンテナが侵害された場合の被害範囲を最小化し、有効なトラフィックを期待通りにルーティングしながら、ラテラルムーブメントを止めることです。

ネイティブコントロール (マルチクラスタ): Kubernetes 内でネットワークの分離を真に強制するには、適切に個別のクラスタを利用することです。 これは密接に結合したマイクロサービスを扱う際には複雑さを増しますが、リスクに基づいて異なるテナントを分離する場合にはありえる選択肢となります。

ネイティブコントロール (ネットワークポリシー): ネットワークポリシーは Kubernetes 自体にビルトインされており、ファイアウォールのルールのように動作します。 これぱポッドがどのように通信するかをコントロールします。 ネットワークポリシーがなければ、どのポッドも他のどのポッドとも会話できます。 ネットワークポリシーはポッドの通信を定義されたアセットのみに制限し、明示的に設定されていないものはすべて拒否するように定義すべきです。 以下は "default" 名前空間を実行しているポッド間のバックエンドイーグレスを防ぐネットワークポリシーの例です。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-backend-egress
  namespace: default

spec:
    podSelector:
    matchLabels:
      tier: backend
      policyTypes:
      - Egress
      egress:
      - to:
         - podSelector:
        matchLabels:
        tier: backend
apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: "shoes-writer"
  namespace: default
spec:
  selector:
    matchLabels:
      app: shoes
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/default/sa/inventory-sa"]
    to:
    - operation:
        methods: ["POST"]
  • shoes の selector は app:shoes でラベル付けされたすべてのデプロイメントを矯正することを意味します。

  • HTTP 操作は POST だけが許可しており、GET や PUT などの他の HTTP 操作は拒否することを意味します。

CNI プラグイン:

CNI を選択する場合には、セキュリティの観点から求めている機能セットと、そのプラグインを使用することに関連するリソースのオーバーヘッドとメンテナンスについて理解することが最も重要です。

攻撃シナリオの例

Wordpress ポッドはネットワークセグメンテーションがないクラスタ上で侵害され、攻撃者はネットワークを探索するために dig や curl といったネットワークユーティリティを利用できるとします (結局は Ubuntu ベースイメージなのです) 。 彼らは一般的に Redis であるポート 6379 で動作する、内部アクセス可能な API を発見します。 彼らは curl を使用して、内部でバックエンド API にのみ使用されることを意図していた Redis マイクロサービスをプローブできます。 データが盗まれ改変されます。

ロックダウンした NetworkPolicy やサービスメッシュ実装では Wordpress などから Redis へのネットワーク接続は不可能だったでしょう。

ネットワークセグメンテーションがないクラスタ上でそれほど重要ではないウェブアプリケーションが侵害されます。 攻撃者はメタデータ URL へのリクエストを行い、ブートストラッププロセスのすべての詳細を持つ証明書鍵を含む kube-env ファイルを取得できます。 この攻撃は自分自身をノードとして登録し、さらなるエスカレーションのためにシークレットを盗む可能性があります。

以下に記載したシンプルな NetworkPolicy でユーザーがメタデータ URL を呼び出すことをブロックできます。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: block-1
spec:
  egress:
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
        except:
        - 169.254.169.254/32
  podSelector: {}
  policyTypes:
  - Egress

参考資料

サービスメッシュ: さまざまなユースケースに対して , , などの数多くのさまざまなサービスメッシュプロジェクトが利用可能です。 これらのサービスメッシュテクノロジはそれぞれ Kubernetes クラスタ内のネットワークトラフィックをセグメント化するさまざまな方法を提供し、すべてに長所と短所があります。以下は Istio の AuthorizationPolicy の例です。

私たちが許可している source ワークロードは inventory-sa というアイデンティティを持っています。 Kubernetes 環境では、inventory-sa を持つポッドだけが shoes にアクセスできることを意味します。

Container Network Interface (CNI) はネットワークリソースへのアクセスを設定するために使用されるオープンソース です。 CNI は Kubernetes 内のネットワークアクセスを許可または拒否するためのソフトウェア定義のメカニズムであり、サポートされるプラグインは多岐にわたります。 や などのソリューションはすべて Kubernetes のコンテキスト内でネットワークトラフィックを分離するためのさまざまなメカニズムを提供しています。 オペレータが Kubernetes ネットワークポリシー (上記) を実装したい場合、一般的に CNI が必要となります。

Istio Authorization:

Kubernetes CNI Explained:

Kubernetes Network Policies:

Hacking kubelet on GKE:

Istio
Linkerd
Hashicorp Consul
サービスアカウント
仕様
Project Calico
Cilium
https://istiobyexample.dev/authorization/
https://www.tigera.io/learn/guides/kubernetes-networking/kubernetes-cni/
https://kubernetes.io/docs/concepts/services-networking/network-policies/
https://www.4armed.com/blog/hacking-kubelet-on-gke/
Network Segmentation - Illustration
Network Segmentation - Mitigation