セキュリティ専門家のための Kubernetes ネットワーク ポリシーの概要

ノート。 翻訳。: この記事の著者である Reuven Harrison は、ソフトウェア開発で 20 年以上の経験があり、現在はセキュリティ ポリシー管理ソリューションを作成する会社 Tufin の CTO 兼共同創設者です。 彼は、Kubernetes ネットワーク ポリシーをクラスター内のネットワーク セグメンテーションのための非常に強力なツールであると考えていますが、実際に実装するのはそれほど簡単ではないとも考えています。 この資料 (非常にボリュームがあります) は、この問題に対する専門家の認識を向上させ、必要な構成の作成を支援することを目的としています。

現在、多くの企業がアプリケーションの実行に Kubernetes を選択することが増えています。 このソフトウェアへの関心は非常に高く、Kubernetes を「データセンター用の新しいオペレーティング システム」と呼ぶ人もいます。 徐々に、Kubernetes (または k8s) が、ネットワーク セキュリティを含む成熟したビジネス プロセスの組織化を必要とするビジネスの重要な部分として認識され始めています。

Kubernetes を使用することに戸惑っているセキュリティ専門家にとって、真の啓示は、プラットフォームのデフォルト ポリシーであるすべてを許可することかもしれません。

このガイドは、ネットワーク ポリシーの内部構造を理解するのに役立ちます。 通常のファイアウォールのルールとどのように異なるかを理解してください。 また、いくつかの落とし穴についても説明し、Kubernetes 上のアプリケーションを保護するための推奨事項も提供します。

Kubernetes ネットワーク ポリシー

Kubernetes ネットワーク ポリシー メカニズムを使用すると、プラットフォームにデプロイされたアプリケーションの対話をネットワーク層 (OSI モデルの 7 番目) で管理できます。 ネットワーク ポリシーには、OSI レイヤ XNUMX の適用や脅威の検出など、最新のファイアウォールの高度な機能の一部が欠けていますが、出発点として適した基本レベルのネットワーク セキュリティが提供されます。

ネットワークポリシーはポッド間の通信を制御します

Kubernetes のワークロードは、一緒にデプロイされた XNUMX つ以上のコンテナーで構成されるポッド全体に分散されます。 Kubernetes は、各ポッドに他のポッドからアクセスできる IP アドレスを割り当てます。 Kubernetes ネットワーク ポリシーは、クラウド内のセキュリティ グループを使用して仮想マシン インスタンスへのアクセスを制御するのと同じ方法で、ポッドのグループのアクセス権を設定します。

ネットワークポリシーの定義

他の Kubernetes リソースと同様に、ネットワーク ポリシーは YAML で指定されます。 以下の例では、アプリケーションは balance へのアクセス postgres:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: balance
  policyTypes:
  - Ingress

(ノート。 翻訳。: このスクリーンショットは、その後の同様のスクリーンショットと同様、ネイティブの Kubernetes ツールを使用せずに、元の記事の著者の会社によって開発され、資料の最後に記載されている Tufin Orca ツールを使用して作成されました。)

独自のネットワーク ポリシーを定義するには、YAML の基本的な知識が必要です。 この言語はインデント (タブではなくスペースで指定) に基づいています。 インデントされた要素は、その上の最も近いインデントされた要素に属します。 新しいリスト要素はハイフンで始まり、他のすべての要素は次の形式になります。 キーと値.

YAML でポリシーを記述したら、次を使用します。 キューブクルクラスター内に作成するには:

kubectl create -f policy.yaml

ネットワークポリシー仕様

Kubernetes ネットワーク ポリシー仕様には、次の XNUMX つの要素が含まれています。

1. podSelector: このポリシー (ターゲット) の影響を受けるポッドを定義します - 必須。
2. policyTypes: これに含まれるポリシーのタイプを示します: 入力および/または出力 - オプションですが、すべての場合に明示的に指定することをお勧めします。
3. ingress: 許可される定義 着信 ターゲットポッドへのトラフィック - オプション。
4. egress: 許可される定義 発信 ターゲット ポッドからのトラフィックはオプションです。

Kubernetes Web サイトから引用した例 (置き換えました) role на app) は、XNUMX つの要素すべてがどのように使用されるかを示しています。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:    # <<<
    matchLabels:
      app: db
  policyTypes:    # <<<
  - Ingress
  - Egress
  ingress:        # <<<
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24
    - namespaceSelector:
        matchLabels:
          project: myproject
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379
  egress:         # <<<
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5978

XNUMX つの要素すべてを含める必要はないことに注意してください。 あくまで必須です podSelector、他のパラメータは必要に応じて使用できます。

省略した場合 policyTypesの場合、ポリシーは次のように解釈されます。

• デフォルトでは、入力側を定義すると想定されます。 ポリシーにこれが明示的に記載されていない場合、システムはすべてのトラフィックが禁止されていると想定します。
• 出力側の動作は、対応する出力パラメータの有無によって決まります。

間違いを避けるために私がお勧めするのは 常にそれを明示的にする policyTypes.

上記のロジックによれば、パラメータが ingress および/または egress 省略した場合、ポリシーはすべてのトラフィックを拒否します (下記の「ストリッピング ルール」を参照)。

デフォルトのポリシーは許可です

ポリシーが定義されていない場合、Kubernetes はデフォルトですべてのトラフィックを許可します。 すべてのポッドは、それらの間で情報を自由に交換できます。 これはセキュリティの観点からは直観に反するように思えるかもしれませんが、Kubernetes はもともとアプリケーションの相互運用性を可能にするために開発者によって設計されたものであることを思い出してください。 ネットワーク ポリシーは後で追加されました。

名前空間

名前空間は、Kubernetes コラボレーション メカニズムです。 これらは論理環境を相互に分離するように設計されていますが、スペース間の通信はデフォルトで許可されています。

ほとんどの Kubernetes コンポーネントと同様、ネットワーク ポリシーは特定の名前空間に存在します。 ブロック内 metadata ポリシーが属するスペースを指定できます。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: my-namespace  # <<<
spec:
...

名前空間がメタデータで明示的に指定されていない場合、システムは kubectl で指定された名前空間を使用します (デフォルトでは)。 namespace=default):

kubectl apply -n my-namespace -f namespace.yaml

私はお勧め 名前空間を明示的に指定するただし、一度に複数の名前空間を対象とするポリシーを作成する場合は除きます。

プライマリー 要素 podSelector ポリシー内の は、ポリシーが属する名前空間からポッドを選択します (別の名前空間からのポッドへのアクセスは拒否されます)。

同様に、podSelectors イングレスブロックとエグレスブロック内 もちろんポッドを組み合わせない限り、独自の名前空間からのみポッドを選択できます namespaceSelector (これについては、「名前空間とポッドによるフィルター」セクションで説明します)。

ポリシーの命名規則

ポリシー名は、同じ名前空間内では一意です。 同じスペースに同じ名前の XNUMX つのポリシーを存在させることはできませんが、異なるスペースに同じ名前のポリシーを存在させることはできます。 これは、複数のスペースに同じポリシーを再適用する場合に便利です。

私は特に気に入っている命名方法の XNUMX つです。 これは、名前空間名とターゲット ポッドを組み合わせることで構成されます。 例えば：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres  # <<<
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: admin
  policyTypes:
  - Ingress

ラベル

ポッドや名前空間などの Kubernetes オブジェクトにカスタム ラベルを付けることができます。 ラベル (ラベル - タグ) は、クラウド内のタグに相当します。 Kubernetes ネットワーク ポリシーはラベルを使用して選択します ポッドそれらが適用されるもの:

podSelector:
  matchLabels:
    role: db

… または 名前空間それらが適用されます。 この例では、対応するラベルを持つ名前空間内のすべてのポッドを選択します。

namespaceSelector:
  matchLabels:
    project: myproject

使用上の注意点がXNUMXつあります。 namespaceSelector 選択した名前空間に正しいラベルが含まれていることを確認してください。 次のような組み込みの名前空間があることに注意してください。 default и kube-system、デフォルトではラベルは含まれません。

次のようにスペースにラベルを追加できます。

kubectl label namespace default namespace=default

同時に、セクション内の名前空間 metadata ラベルではなく、実際のスペース名を参照する必要があります。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default   # <<<
spec:
...

送信元と宛先

ファイアウォール ポリシーは、送信元と宛先を含むルールで構成されます。 Kubernetes ネットワーク ポリシーは、ターゲット (適用先のポッドのセット) に対して定義され、イングレス トラフィックやエグレス トラフィックのルールを設定します。 この例では、ポリシーのターゲットは名前空間内のすべてのポッドになります。 default ラベル付き 鍵付き app と意味 db:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: db   # <<<
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24
    - namespaceSelector:
        matchLabels:
          project: myproject
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5978

サブセクション ingress このポリシーでは、ターゲット ポッドへの受信トラフィックを開きます。 つまり、イングレスはソースであり、ターゲットは対応する宛先です。 同様に、出力は宛先であり、ターゲットはその送信元です。

これは、XNUMX つのファイアウォール ルール (Ingress → Target) に相当します。 ゴール→出口。

Egress と DNS (重要!)

送信トラフィックを制限することで、 DNSには特に注意してください - Kubernetes は、このサービスを使用してサービスを IP アドレスにマッピングします。 たとえば、次のポリシーは、アプリケーションを許可していないため機能しません。 balance DNS にアクセスします:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: postgres
  policyTypes:
  - Egress

DNS サービスへのアクセスを開くことでこの問題を修正できます。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: postgres
  - to:               # <<<
    ports:            # <<<
    - protocol: UDP   # <<<
      port: 53        # <<<
  policyTypes:
  - Egress

最後の要素 to は空であるため、間接的に選択されます すべての名前空間のすべてのポッド、許可します balance DNS クエリを適切な Kubernetes サービス (通常はスペースで実行されている) に送信します。 kube-system).

このアプローチは機能しますが、 過度に寛容で不安これにより、DNS クエリをクラスターの外部に送信できるようになるためです。

XNUMX つの連続したステップで改善できます。

1. DNS クエリのみを許可する 内部 追加によるクラスター化 namespaceSelector:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: postgres
  - to:
    - namespaceSelector: {} # <<<
    ports:
    - protocol: UDP
      port: 53
  policyTypes:
  - Egress

2. ネームスペース内のみで DNS クエリを許可する kube-system.

これを行うには、名前空間にラベルを追加する必要があります kube-system: kubectl label namespace kube-system namespace=kube-system - そしてそれをポリシーに書き留めます namespaceSelector:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: postgres
  - to:
    - namespaceSelector:         # <<<
        matchLabels:             # <<<
          namespace: kube-system # <<<
    ports:
    - protocol: UDP
      port: 53
  policyTypes:
  - Egress

3. 偏執的な人々はさらに進んで、DNS クエリを特定の DNS サービスに制限する可能性があります。 kube-system。 「名前空間とポッドによるフィルター」セクションでは、これを実現する方法について説明します。

もう XNUMX つのオプションは、名前空間レベルで DNS を解決することです。 この場合、サービスごとに開く必要はありません。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.dns
  namespace: default
spec:
  podSelector: {} # <<<
  egress:
  - to:
    - namespaceSelector: {}
    ports:
    - protocol: UDP
      port: 53
  policyTypes:
  - Egress

ヌル podSelector 名前空間内のすべてのポッドを選択します。

最初の試合とルールの順序

従来のファイアウォールでは、パケットに対するアクション (許可または拒否) は、パケットが満たす最初のルールによって決定されます。 Kubernetes では、ポリシーの順序は重要ではありません。

デフォルトでは、ポリシーが設定されていない場合、ポッド間の通信が許可され、自由に情報を交換できます。 ポリシーの策定を開始すると、少なくとも XNUMX つのポリシーの影響を受ける各ポッドは、それを選択したすべてのポリシーの論理和 (論理和) に従って分離されます。 どのポリシーにも影響を受けないポッドは開いたままになります。

ストリッピング ルールを使用して、この動作を変更できます。

ストリッピング ルール (「拒否」)

通常、ファイアウォール ポリシーは、明示的に許可されていないトラフィックを拒否します。

Kubernetes には拒否アクションはありませんただし、ソース ポッドの空のグループ (イングレス) を選択することで、通常の (寛容な) ポリシーでも同様の効果を達成できます。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Ingress

このポリシーは、名前空間内のすべてのポッドを選択し、イングレスを未定義のままにして、すべての受信トラフィックを拒否します。

同様の方法で、名前空間からのすべての送信トラフィックを制限できます。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-egress
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress

注意してください 名前空間内のポッドへのトラフィックを許可する追加のポリシーは、このルールよりも優先されます。 (ファイアウォール構成で拒否ルールの前に許可ルールを追加するのと似ています)。

すべてを許可 (Any-Any-Any-Allow)

すべて許可ポリシーを作成するには、上記の拒否ポリシーを空の要素で補足する必要があります。 ingress:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all
  namespace: default
spec:
  podSelector: {}
  ingress: # <<<
  - {}     # <<<
  policyTypes:
  - Ingress

からのアクセスを許可します すべての名前空間 (およびすべての IP) のすべてのポッドから名前空間内の任意のポッドへ default。 この動作はデフォルトで有効になっているため、通常はさらに定義する必要はありません。 ただし、問題を診断するために、一部の特定のアクセス許可を一時的に無効にする必要がある場合があります。

ルールは、アクセスのみを許可するように絞り込むことができます。 特定のポッドのセット (app:balance) 名前空間内 default:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all-to-balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  ingress: 
  - {}
  policyTypes:
  - Ingress

次のポリシーは、クラスター外部の IP へのアクセスを含む、すべての受信トラフィックと送信トラフィックを許可します。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all
spec:
  podSelector: {}
  ingress:
  - {}
  egress:
  - {}
  policyTypes:
  - Ingress
  - Egress

複数のポリシーの結合

ポリシーは XNUMX つのレベルで論理 OR を使用して結合されます。 各ポッドの権限は、それに影響するすべてのポリシーの論理和に従って設定されます。

1. 畑で from и to XNUMX 種類の要素を定義できます (すべて OR を使用して結合されます)。

• namespaceSelector — 名前空間全体を選択します。
• podSelector — ポッドを選択します。
• ipBlock — サブネットを選択します。

さらに、サブセクション内の要素の数（同じ要素であっても） from/to 無制限。 それらはすべて論理和で結合されます。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres
  namespace: default
spec:
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: indexer
    - podSelector:
        matchLabels:
          app: admin
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
  - Ingress

2. ポリシーセクション内 ingress 多くの要素を含めることができます from (論理和で結合)。 同様に、セクション egress 多くの要素が含まれる場合があります to (選言によって結合することもできます):

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres
  namespace: default
spec:
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: indexer
  - from:
    - podSelector:
        matchLabels:
          app: admin
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
  - Ingress

3. 異なるポリシーも論理 OR で結合されます

ただし、それらを組み合わせる場合、どれを組み合わせるかという制限が XNUMX つあります。 示された クリス・クーニー: Kubernetes は、異なるポリシーのみを組み合わせることができます。 policyTypes (Ingress または Egress）。 イングレス (またはエグレス) を定義するポリシーは相互に上書きされます。

名前空間間の関係

デフォルトでは、ネームスペース間での情報共有が許可されています。 これは、名前空間に送受信されるトラフィックを制限する拒否ポリシーを使用することで変更できます (上記の「ストリッピング ルール」を参照)。

ネームスペースへのアクセスをブロックすると (上記の「ストリッピング ルール」を参照)、次のコマンドを使用して特定のネームスペースからの接続を許可することで、拒否ポリシーの例外を作成できます。 namespaceSelector:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database.postgres
  namespace: database
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - namespaceSelector: # <<<
        matchLabels:
          namespace: default
  policyTypes:
  - Ingress

その結果、名前空間内のすべてのポッドが default ポッドにアクセスできるようになります postgres 名前空間内 database。 しかし、アクセスをオープンにしたい場合はどうすればよいでしょうか postgres 名前空間内の特定のポッドのみ default?

名前空間とポッドによるフィルター

Kubernetes バージョン 1.11 以降では、演算子を組み合わせることができます namespaceSelector и podSelector 論理 AND を使用すると、次のようになります。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database.postgres
  namespace: database
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          namespace: default
      podSelector: # <<<
        matchLabels:
          app: admin
  policyTypes:
  - Ingress

これが通常の OR ではなく AND として解釈されるのはなぜですか?

ご了承ください podSelector ハイフンで始まっていません。 YAML では、これは次のことを意味します podSelector そして彼の前に立っている namespaceSelector 同じリスト要素を参照します。 したがって、それらは論理積で結合されます。

前にハイフンを追加する podSelector 新しいリスト要素が出現し、前の要素と結合されます。 namespaceSelector 論理和を使用します。

特定のラベルが付いたポッドを選択するには すべての名前空間で、空白を入力してください namespaceSelector:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database.postgres
  namespace: database
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - namespaceSelector: {}
      podSelector:
        matchLabels:
          app: admin
  policyTypes:
  - Ingress

複数のレーベルが I と提携

複数のオブジェクト (ホスト、ネットワーク、グループ) を含むファイアウォールのルールは、論理 OR を使用して結合されます。 パケットソースが一致する場合、次のルールが機能します。 Host_1 OR Host_2:

| Source | Destination | Service | Action |
| ----------------------------------------|
| Host_1 | Subnet_A    | HTTPS   | Allow  |
| Host_2 |             |         |        |
| ----------------------------------------|

それどころか、Kubernetes ではさまざまなラベルが podSelector または namespaceSelector たとえば、次のルールは両方のラベルを持つポッドを選択します。 role=db И version=v2:

podSelector:
  matchLabels:
    role: db
    version: v2

同じロジックが、ポリシー ターゲット セレクター、ポッド セレクター、名前空間セレクターなど、すべてのタイプの演算子に適用されます。

サブネットと IP アドレス (IPBlock)

ファイアウォールは、VLAN、IP アドレス、およびサブネットを使用してネットワークをセグメント化します。

Kubernetes では、IP アドレスはポッドに自動的に割り当てられ、頻繁に変更される可能性があるため、ネットワーク ポリシーでポッドと名前空間を選択するためにラベルが使用されます。

サブネット (ipBlocks) は、受信 (イングレス) または送信 (エグレス) 外部 (南北) 接続を管理するときに使用されます。 たとえば、このポリシーは名前空間のすべてのポッドに対して開かれます。 default Google DNS サービスへのアクセス:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: egress-dns
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 8.8.8.8/32
    ports:
    - protocol: UDP
      port: 53

この例の空のポッド セレクターは、「名前空間内のすべてのポッドを選択する」ことを意味します。

このポリシーは 8.8.8.8 へのアクセスのみを許可します。 他の IP へのアクセスは禁止されています。 つまり、本質的には、内部 Kubernetes DNS サービスへのアクセスがブロックされたことになります。 それでも開きたい場合は、そのことを明示的に指定してください。

通常 ipBlocks и podSelectors ポッドの内部 IP アドレスは使用されないため、相互に排他的です。 ipBlocks。 示すことによって 内部 IP ポッド、実際には、これらのアドレスを持つポッドとの接続を許可します。 実際には、どの IP アドレスを使用すればよいかわからないため、ポッドの選択に IP アドレスを使用すべきではありません。

反例として、次のポリシーにはすべての IP が含まれるため、他のすべてのポッドへのアクセスが許可されます。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: egress-any
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0

ポッドの内部 IP アドレスを除く、外部 IP へのアクセスのみを開くことができます。 たとえば、ポッドのサブネットが 10.16.0.0/14 の場合:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: egress-any
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
        except:
        - 10.16.0.0/14

ポートとプロトコル

通常、ポッドは XNUMX つのポートをリッスンします。 つまり、ポリシーでポート番号を指定せず、すべてをデフォルトのままにすることができます。 ただし、場合によってはポートを指定できるように、ポリシーをできるだけ制限することをお勧めします。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres
  namespace: default
spec:
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: indexer
    - podSelector:
        matchLabels:
          app: admin
    ports:             # <<<
      - port: 443      # <<<
        protocol: TCP  # <<<
      - port: 80       # <<<
        protocol: TCP  # <<<
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
  - Ingress

セレクターに注意してください ports ブロック内のすべての要素に適用されます to または from、 を含む。 要素の異なるセットに異なるポートを指定するには、分割します。 ingress または egress いくつかのサブセクションに分かれています to または from そして、各レジスタでポートを次のようにします。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres
  namespace: default
spec:
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: indexer
    ports:             # <<<
     - port: 443       # <<<
       protocol: TCP   # <<<
  - from:
    - podSelector:
        matchLabels:
          app: admin
    ports:             # <<<
     - port: 80        # <<<
       protocol: TCP   # <<<
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
  - Ingress

デフォルトのポート操作:

• ポート定義を完全に省略した場合 (ports)、これはすべてのプロトコルとすべてのポートを意味します。
• プロトコル定義を省略した場合(protocol)、これは TCP を意味します。
• ポート定義を省略した場合(port)、これはすべてのポートを意味します。

ベスト プラクティス: デフォルト値に依存せず、必要なものを明示的に指定します。

サービス ポートではなく、ポッド ポートを使用する必要があることに注意してください (これについては次の段落で詳しく説明します)。

ポリシーはポッドまたはサービスに対して定義されていますか?

通常、Kubernetes のポッドは、サービス (サービスを実装するポッドにトラフィックをリダイレクトする仮想ロード バランサー) を通じて相互にアクセスします。 ネットワーク ポリシーによってサービスへのアクセスが制御されると思われるかもしれませんが、そうではありません。 Kubernetes ネットワーク ポリシーは、サービス ポートではなくポッド ポートで機能します。

たとえば、サービスがポート 80 をリッスンし、トラフィックをそのポッドのポート 8080 にリダイレクトする場合、ネットワーク ポリシーで正確に 8080 を指定する必要があります。

このようなメカニズムは最適とは言えません。サービスの内部構造 (ポッドがリッスンするポート) が変更された場合、ネットワーク ポリシーを更新する必要があります。

Service Mesh を使用した新しいアーキテクチャ アプローチ (たとえば、以下の Istio についてを参照してください。おおよその翻訳です。) を使用すると、この問題に対処できます。

IngressとEgressの両方を登録する必要がありますか?

簡単な答えは「はい」です。ポッド A がポッド B と通信するには、発信接続の作成を許可する必要があり (このためには出力ポリシーを構成する必要があります)、ポッド B は受信接続を受け入れることができなければなりません (したがって、このためには、イングレスポリシー).ポリシー)が必要です。

ただし、実際には、デフォルトのポリシーを利用して一方向または両方向の接続を許可できます。

ポッドがあれば-ソース XNUMX人以上によって選択されます 下り-政治家、それに課される制限は彼らの選言によって決定されます。 この場合、ポッドへの接続を明示的に許可する必要があります。受取人に。 ポッドがどのポリシーでも選択されていない場合、その送信 (エグレス) トラフィックはデフォルトで許可されます。

同様に、ポッドの運命は宛先、XNUMX 人以上が選択 進入-政治家は、彼らの選言によって決定されます。 この場合、ソース ポッドからのトラフィックの受信を明示的に許可する必要があります。 ポッドがどのポリシーでも選択されていない場合、そのポッドに対するすべての入力トラフィックがデフォルトで許可されます。

以下のステートフルまたはステートレスを参照してください。

ログ

Kubernetes ネットワーク ポリシーではトラフィックをログに記録できません。 このため、ポリシーが意図したとおりに機能しているかどうかを判断することが難しくなり、セキュリティ分析が非常に複雑になります。

外部サービスへのトラフィックの制御

Kubernetes ネットワーク ポリシーでは、出力セクションで完全修飾ドメイン名 (DNS) を指定することはできません。 この事実は、固定 IP アドレスを持たない外部宛先 (aws.com など) へのトラフィックを制限しようとする場合に、重大な不便を引き起こします。

ポリシーチェック

ファイアウォールは警告を発したり、間違ったポリシーの受け入れを拒否したりすることもあります。 Kubernetes はいくつかの検証も行います。 kubectl を介してネットワーク ポリシーを設定すると、Kubernetes はそれが正しくないと宣言し、受け入れを拒否する場合があります。 他の場合には、Kubernetes はポリシーを取得し、不足している詳細を入力します。 これらは次のコマンドを使用して確認できます。

kubernetes get networkpolicy <policy-name> -o yaml

Kubernetes 検証システムは完全ではなく、一部の種類のエラーを見逃す可能性があることに注意してください。

実行

Kubernetes 自体はネットワーク ポリシーを実装しませんが、制御の負担を Container Networking Interface (CNI) と呼ばれる基盤となるシステムに委任する API ゲートウェイにすぎません。 適切な CNI を割り当てずに Kubernetes クラスターにポリシーを設定することは、ファイアウォールにインストールせずにファイアウォール管理サーバーにポリシーを作成することと同じです。 適切な CNI を確保するか、Kubernetes プラットフォームの場合はクラウドでホストされるかを確認するのはあなた次第です。 (プロバイダーのリストが表示されます) ここで — 約トランス）、CNI を設定するネットワーク ポリシーを有効にします。

適切なヘルパー CNI を使用せずにネットワーク ポリシーを設定した場合、Kubernetes は警告を表示しないことに注意してください。

ステートフルかステートレスか?

私が遭遇したすべての Kubernetes CNI はステートフルです (たとえば、Calico は Linux conntrack を使用します)。 これにより、ポッドは、再確立することなく、開始した TCP 接続上で応答を受信できるようになります。 ただし、ステートフル性を保証する Kubernetes 標準については知りません。

高度なセキュリティ ポリシー管理

Kubernetes でのセキュリティ ポリシーの適用を改善する方法をいくつか紹介します。

1. サービス メッシュ アーキテクチャ パターンは、サイドカー コンテナーを使用して、サービス レベルで詳細なテレメトリとトラフィック制御を提供します。 例として、 イスティオ.
2. CNI ベンダーの中には、Kubernetes ネットワーク ポリシーを超えてツールを拡張しているものもあります。
3. トゥフィンオルカ Kubernetes ネットワーク ポリシーの可視性と自動化を提供します。

Tufin Orca パッケージは、Kubernetes ネットワーク ポリシーを管理します (上記のスクリーンショットのソースでもあります)。

追加情報

• GKE の Ahmet Alp Balkan が作成したネットワーク ポリシーの例;
• Kubernetes 公式 Web サイトのドキュメント;
• Kubernetes ネットワーキング モデルのガイド;
• ネットワークポリシーをチェックするためのスクリプト.

まとめ

Kubernetes ネットワーク ポリシーは、クラスターをセグメント化するための優れたツール セットを提供しますが、直感的ではなく、多くの微妙な点があります。 この複雑さのため、既存のクラスター ポリシーの多くにはバグがあると思われます。 この問題に対する考えられる解決策には、ポリシー定義を自動化するか、他のセグメンテーション ツールを使用することが含まれます。

このガイドがいくつかの疑問を解決し、遭遇する可能性のある問題の解決に役立つことを願っています。

翻訳者からの追伸

私たちのブログもお読みください:

• 「Istio でマイクロサービスに戻る」: パート 1 (主な機能の紹介), パート 2 (ルーティング、トラフィック制御), パート 3 (セキュリティ);
• 「Kubernetes でのネットワークの図解ガイド」: パート 1 および 2 (ネットワーク モデル、オーバーレイ ネットワーク), パート 3 (サービスとトラフィック処理);
• «セキュリティが要求される環境における Docker と Kubernetes";
• «9 Kubernetes セキュリティのベスト プラクティス";
• «Kubernetes ハッキングの被害者にならない (被害者にならない) 11 の方法'。

出所： habr.com