Kubernetesのネットワークセキュリティについて

ネットワークはKubernetesの中でも特に複雑な部分です。ネットワークは様々な方法で構成できます。サービスメッシュを使うかもしれませんが、使わないかもしれません。クラスタ内のリソースの中には、内部ネットワークとのみインターフェイスするものもあれば、インターネットへの直接アクセスを必要とするものもあります。ポート、IPアドレス、そしてその他のネットワーク属性は通常動的に構成されるため、ネットワークレベルで何が起こっているかを追跡するのが難しくなる可能性があります。

このように複雑なため、Kubernetesのネットワークセキュリティは特に難しいとされています。Kubernetesのネットワークアーキテクチャを深く理解することに加えて、Kubernetesがネイティブで提供するネットワーク・ポリシーや、ネットワークをさらに強固にするサードパーティ製ツールなど、ネットワークのセキュリティを支援するツールに精通している必要があるからです。

この記事では、Kubernetesのネットワークセキュリティの基礎について説明します。Kubernetesのネットワークがどのように機能するのか、どのようなセキュリティリスクがネットワークリソースに影響を及ぼす可能性があるのか、そしてKubernetesのネットワークをセキュアに保つために従うべきベストプラクティスについて学びます。

Kubernetesネットワーキング入門

ネットワークレベルでKubernetesを保護するための第一歩は、Kubernetesがどのようにネットワークを処理するかを理解することです。これは広範で複雑なトピックですが、ここでは知っておくべきKubernetesネットワーキングのコアな基礎を紹介します。

ネットワークの目的

Kubernetesでは、ネットワークは主に2つの目的を果たします：:

• 内部ネットワーク： ネットワークは、クラスタ内のポッド、Kubernetesノード、およびその他のリソース間の通信を促進する内部トラフィックを処理します。通常、内部ネットワークはプライベートサブネットとIPアドレスを使用し、パブリックインターネットから隔離されています。
• 外部ネットワーク： インターネットに接続する必要があるワークロードは、パブリックIPアドレスを使用します。

Kube-Proxy

Kubernetes内のトラフィックフローを管理するサービスがkube-proxyです。Kube-proxyはKubernetesクラスタの各ノード上で実行され、コンテナのIPアドレスとポートに基づいて、それらのノード上でホストされているコンテナにパケットを転送します。

バックエンドでは、kube-proxyはLinuxのiptablesのようなOSレベルのネットワークサービスに依存してトラフィックを制御します。しかし、kube-proxyはこれらのサービスをKubernetesのリソースから抽象化しているため、Kubernetesのネットワークセキュリティの観点からは、ノードレベルの基礎となるネットワーク管理レイヤーは特に重要ではありません。

CNIプラグイン

多くの場合、KubernetesはContainer Network Interface（CNI）プラグインを使用して、コンテナが使用できる仮想ネットワークインターフェースを作成します。CNIプラグインは、パブリッククラウド上でネイティブに動作するもの（Azure Virtual NetworksやAWS Network Interfacesなど）など、さまざまなサードパーティのネットワーク構成管理プラットフォームとKubernetesを統合するために使用できます。

また、Project CalicoやWeave NetのようなプラットフォームをサポートするCNIプラグインも用意されており、異種環境やハイブリッド環境（Kubernetesとパブリッククラウドやプライベートデータセンターなど、複数の種類のプラットフォームを組み合わせた環境）でネットワーク構成を標準化する方法を提供するように設計されています。

Although it’s technically possible to configure networking in Kubernetes without using a CNI plugin, most production clusters use CNIs to manage networking.

Service Meshes

In addition to CNI plugins, production Kubernetes clusters typically leverage a service mesh to help simplify networking. Service meshes automate the discovery of different resources on a network. Most service meshes also provide network observability and security functionality.

Kubernetes自体は、CNIプラグインを使用せずにネットワーキングを設定することは技術的には可能ですが、ほとんどのプロダクションクラスタはネットワーキングを管理するためにCNIを使用します。

動的な構成（Dynamic Configuration)

どのCNIプラグイン、サービスメッシュ、その他のネットワークツールをKubernetesで使用するにしても、多くの場合、ネットワーク設定は非常に動的です。

つまり、ノード、ポッド、およびサービスのIPアドレスとポートは、それらのリソースが作成されるときに随時設定されます。管理者は、Kubernetesが割り当てに使用するIPアドレスのプールを定義できますが、（少なくともKubernetesのネイティブツールでは）静的IPアドレスを割り当てることはできません。

動的な設定は、ある面でKubernetesのネットワークセキュリティを難しくします。例えば、仮想マシンで作業するときのように、静的なアドレス構成に基づいてホストをホワイトリストやブラックリストに登録することはできません。また、Kubernetes内部でネットワークトラフィックデータを特定のリソースにマッピングすることも難しくなります。たとえば、指定されたIPアドレスが1つのポッドまたはノードだけで使用されたのか、あるいは1つのリソースで使用され、最初のリソースがシャットダウンしたときに別のリソースに再割り当てされたのかを常に把握できるとは限らないからです。

Kubernetesネットワークリソースを保護する方法

Kubernetesは通常、内部リソース（kube-proxyなど）と外部サービス（CNIプラグインやサービスメッシュなど）のミックスに依存してネットワーク構成とトラフィックを管理するため、Kubernetesネットワークのセキュリティを確保するには、管理者がネイティブツールとサードパーティツールを組み合わせて活用する必要もあります。

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

ネイティブでは、Kubernetesがネットワークセキュリティのために提供する最も重要なリソースはネットワークポリシーです。簡単に言うと、ネットワークポリシーは、ネットワークレベルでポッドが互いにどのように通信できるかを管理するルールを定義します。

ポッドの通信を制御する体系的な手段を提供するだけでなく、ネットワークポリシーには、管理者がポッドのラベルや名前空間などのコンテキストに基づいてリソースと関連するネットワークルールを定義できるという重要な利点があります。上記で説明したように、Kubernetesのネットワーク構成の動的な性質を考えると、IPアドレスを使用してネットワークルールを管理することはできないため、これは非常に重要です。

ネットワークポリシーはKubernetesのRBACポリシーに似ています。どのネットワークルールを適用するかを指定するファイルで、ルールが適用されるリソース（ネームスペース、ポッドなど）も特定します。

例えば、このネットワークポリシーは、”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: backendCode language: JavaScript (javascript)

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

ネットワークポリシーはKubernetesのネットワークセキュリティにとって重要なツールですが、その限界を認識することが重要です：

• ポッドにフォーカスしている： ネットワークポリシーは基本的にポッドのネットワークアクセスを分離または制限するために設計されています。Kubernetesのノードやその他のリソースのネットワークルールの管理には（少なくとも直接的で単純な方法では）使用できません。
• 不正使用は検出できない： ネットワークポリシーは、ネットワークアクセスをロックし、潜在的なセキュリティホールを塞ぐための素晴らしい方法です。しかし、潜在的なセキュリティ問題を検出したり警告したりすることはできません。
• データを暗号化しない：　 ネットワークポリシーは、Kubernetesのコンポーネント間を移動するデータを暗号化することはできません。ネットワークの暗号化を実現するには、サードパーティのツール（サービスメッシュなど）を使用する必要があります。

サードパーティのネットワークセキュリティツールの活用

Kubernetesのネイティブネットワークセキュリティツールに関しては、基本的にネットワークポリシーがすべてです。ネットワークセキュリティの他の側面に対処するには、外部ツールを活用する必要があります。

Kubernetes用の様々なサードパーティネットワーキングソリューションで利用できる特定のセキュリティツールと機能は様々であるため、外部ツールを使ってネットワークセキュリティ要件に対応するための万能のソリューションはありません。

しかし、一般的には、サービスメッシュを利用することで、トラフィックの暗号化、ネットワークに接続されたリソースの認証と認可の実施、Kubernetesネットワークリソースからのテレメトリデータの収集が可能になります。サービスメッシュの中には、Kubernetesネットワークポリシーを使用して現実的でないネットワークセキュリティルールを実施するために使用できるポリシーフレームワークも提供しています

CNIプラグインは多くの場合、ポリシーフレームワークやネットワーク監視機能など、同様の機能を提供します。そのため、Kubernetesのネットワークセキュリティを最大化するために必要な可視性とポリシーの実施を提供するために、CNIに接続されたネットワーキングプラットフォームか、またはサービスメッシュに主に依存するか、を選択することができます。

Kubernetesセキュリティのベストプラクティスに倣う

Kubernetesネットワークのセキュリティ確保に役立つさまざまなツールを活用するだけでなく、Kubernetesクラスタをホストする環境でネットワークリソース全般を扱う際に従うべき標準的なベストプラクティスがあります。

• RBACの使用： Kubernetes Role-Based Access Control（RBAC）はネットワークセキュリティのフレームワークではありませんが、RBACルールはクラスタ内のリソースへのアクセスを制限することで、ネットワークに起因する脅威の影響を緩和するのに役立ちます。
• デフォルトポートを回避： Kubernetesはそのサービスのほとんどにデフォルトのポートを使用しています。ネットワークセキュリティを強化するには、カスタムポートを選択することで、攻撃者がリソースを見つけにくくなります。
• 外部でネットワークをセグメント化： ネットワークポリシー、サービスメッシュルール、その他のリソースを使用してKubernetes内部のネットワークを分離することができます（そして、そうする必要があります）。クラスタをホスティングしている場所にもよりますが、これはVPCやローカルファイアウォールなどのリソースを活用して、パブリックインターネットへのリソースの露出を最小限に抑えることを意味します。
• 監査ログの活用： Kubernetesの監査ログは、Kubernetes内で実行されたすべてのリソースリクエストの記録を提供します。監査ログを有効にして分析することで、ネットワーク上の侵害の兆候となり得る挙動を検出する可能性を最大限に高めることができます。