Kubernetes ネットワークポリシーの基礎

[[436076]]
Kubernetes を通じてアプリケーションをデプロイする前に、Kubernetes ネットワークポリシーを理解することが基本的な要件です。

Kubernetes を介して本番環境にデプロイされるクラウドネイティブアプリケーションがますます増えるにつれて、セキュリティは早い段階で考慮する必要がある重要なチェックリストになります。クラウドネイティブアプリケーションを設計するときは、事前にセキュリティポリシーを埋め込むことが重要です。これを怠ると、後で安全上の問題が発生し、プロジェクトの遅延を引き起こし、最終的には不必要なストレスと費用が発生する可能性があります。

長年にわたり、セキュリティはデプロイメントが本番環境にリリースされる直前まで先延ばしにされてきました。この慣行は、すべての組織が遵守すべきセキュリティ標準があり、それが無視されたり遵守されなかったりして、成果物を達成するために多くのリスクを負うことになるため、プロジェクトの納品の遅延につながります。

Kubernetesの実装を学び始めたばかりの方、Kubernetesの理解ネットワークポリシーネットワークポリシーそれは気が遠くなるかもしれません。ただし、これは、アプリケーションを Kubernetes クラスターにデプロイする前に理解しておく必要がある基本的な要件の 1 つです。 Kubernetes とクラウドネイティブアプリケーションについて学習する際には、「セキュリティを置き去りにしないでください」ということを忘れないでください。あなたのマントラ。

ネットワークポリシーの概念

ネットワークポリシーネットワークポリシーデータセンター環境でよく使用されるファイアウォールデバイスを置き換えます。ポッドポッドコンピューティングインスタンス、ルーターとスイッチへのネットワークプラグイン、およびストレージエリアネットワーク (SAN) へのボリューム。

デフォルトでは、Kubernetesネットワークポリシーはポッドポッドどこからでもトラフィックを受信します。ポッドのセキュリティを気にしないのであれば、これで問題ないかもしれません。ただし、重要なワークロードを実行している場合は、ポッドを保護する必要があります。クラスター内のトラフィック (入力トラフィックと出力トラフィックを含む) の制御は、ネットワークポリシーを通じて実現できます。

ネットワークポリシーを有効にするには、ネットワークポリシーをサポートするネットワークプラグインが必要です。そうしないと、適用したルールが役に立たなくなります。

Kubernetes.io にはさまざまなネットワークプラグインがリストされています。

CNIプラグイン: フォローコンテナネットワークインターフェースコンテナネットワークインターフェース相互運用性の実現を目的とした CNI 仕様。
- Kubernetes は CNI 仕様のバージョン v0.4.0 に準拠しています。
Kubernetes プラグイン: ブリッジとホストネイティブの CNI プラグインを使用して基本的なcbr0を実装します。

ネットワークポリシーの適用

ネットワークポリシーを適用するには、ネットワークポリシーをサポートするネットワークプラグインを備えた稼働中の Kubernetes クラスターが必要です。

ただし、まず、Kubernetes 環境でネットワークポリシーを使用する方法を理解する必要があります。 Kubernetes ネットワークポリシーにより、ポッドはどこからでもトラフィックを受信できるようになります。これは理想的な状況ではありません。ポッドのセキュリティを確保するには、ポッドが Kubernetes アーキテクチャ内で通信できるエンドポイントであることを理解する必要があります。

1. ポッド間の通信にはpodSelectorを使用します。

 - namespaceSelector :
    matchLabels :
      project : myproject

2. 名前空間間の通信および名前空間とポッド間の通信には、 namespaceSelectorおよび/またはpodSelectorとnamespaceSelectorの組み合わせを使用します。 :

 - namespaceSelector :
    matchLabels :
      project : myproject
 - podSelector :
    matchLabels :
      role : frontend

3. ポッドの IP ブロック通信の場合、 ipBlockを使用して、送信元と宛先を決定する IP CIDR ブロックを定義します。

 - ipBlock :
        cidr : 172.17 . 0.0 / 16
         except :
         - 172.17 . 1.0 / 24

ポッド、名前空間、IP ベースのポリシーの違いに注意してください。ポッドベースおよび名前空間ベースのネットワークポリシーでは、セレクターを使用してトラフィックを制御しますが、IP ベースのネットワークポリシーでは、IP ブロック (CIDR 範囲) を使用して制御を定義します。

すべてをまとめると、ネットワークポリシーは次のようになります。

 apiVersion : networking . k8s . io / v1
 kind : NetworkPolicy
 metadata :
  name : test - network - policy
   namespace : default
 spec :
  podSelector :
    matchLabels :
      app : backend
  policyTypes :
   - Ingress
   - Egress
  ingress :
   - from :
     - ipBlock :
        cidr : 172.17 . 0.0 / 16
         except :
         - 192.168 . 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

上記のネットワークポリシーを参照し、 spec部分に注意してください。このセクションでは、ラベルapp=backendを持つpodSelectorネットワークポリシーのターゲットになります。つまり、ネットワークポリシーは、 backend呼ばれる特定の名前空間内のアプリケーションを保護します。

このセクションでは、 policyTypesも定義されています。このフィールドは、特定のポリシーが、選択したポッドへの入力トラフィック、選択したポッドへの出力トラフィック、またはその両方に適用されるかどうかを示します。

 spec :
  podSelector :
    matchLabels :
      app : backend
  policyTypes :
   - Ingress
   - Egress

次に、 IngressとEgressセクションを見てみましょう。この定義は、ネットワークポリシーの制御を指定します。

まず、 ingress fromセクションを確認します。

この例では、ネットワークポリシーにより、次の場所からのポッド接続が許可されます。

ipBlock
- 172.17.0.0/16 を許可する
- 192.168.1.0/24を拒否
namespaceSelector
- myproject : この名前空間から同じラベル project=myproject を持つすべてのポッドを許可します。
podSelector
- frontend : ラベルrole=frontendに一致するポッドを許可します。

 ingress :
 - from :
   - ipBlock :
      cidr : 172.17 . 0.0 / 16
       except :
       - 192.168 . 1.0 / 24
   - namespaceSelector :
      matchLabels :
        project : myproject
   - podSelector :
      matchLabels :
        role : frontend

次に、 egress toセクションを確認します。これにより、ポッドからの送信接続が決定されます。

ipBlock
- 10.0.0.0/24: この CIDR への接続を許可する
- ポート: TCP とポート 5978 を使用した接続を許可する

 egress :
 - to :
   - ipBlock :
      cidr : 10.0 . 0.0 / 24
  ports :
   - protocol : TCP
    port : 5978

ネットワークポリシーの制限

ネットワークポリシーだけでは Kubernetes クラスターを完全に保護することはできません。既知の制限を克服するには、オペレーティングシステムコンポーネントまたはレイヤー 7 ネットワークテクノロジを使用できます。ネットワークポリシーは、IP アドレスとポートレベル、つまり、オープンシステム相互接続 (OSI) アーキテクチャのレイヤー 3 または 4 のセキュリティのみに対応することを覚えておく必要があります。

ネットワークポリシーで処理できないセキュリティ要件に対処するには、他のセキュリティソリューションを使用する必要があります。ここでは、ネットワークポリシーを他のテクノロジーで拡張する必要がある、知っておく必要のあるユースケースをいくつか示します。

要約する

Kubernetes ネットワークポリシーを理解することは重要です。これは、データセンター環境で通常使用するファイアウォールロールを Kubernetes 用に適応させて実装する方法 (置き換えるのではなく) であるためです。これをコンテナセキュリティの最初のレイヤーと考えてください。ネットワークポリシーだけに頼るのは完全なセキュリティソリューションにはなりません。

ネットワークポリシーは、セレクターとラベルを使用して、ポッドと名前空間にセキュリティを実装します。さらに、ネットワークポリシーでは IP 範囲ごとにセキュリティを強制できます。

ネットワークポリシーを適切に理解することは、Kubernetes 環境でコンテナ化を安全に導入するための重要なスキルです。

<<: Kubernetes のマルチコンテナ Pod 設計パターン

>>: AWS、GCP、Azure との交渉時に避けるべき 6 つのリスク