Oracle Cloud Hangout Cafe Season5 #3「Kubernetes のセキュリティ」(2022年3月9日開催)

はじめに

「Oracle Cloud Hangout Cafe」(通称「おちゃかふぇ」/以降、OCHaCafe)は、日本オラクルが主催するコミュニティの1つです。定期的に、開発者・エンジニアに向けたクラウドネイティブな時代に身につけておくべきテクノロジーを深堀する勉強会を開催しています。

連載第4回の今回は、2022年3月9日に開催された「Oracle Cloud Hangout Cafe Season5 #3『 Kubernetes のセキュリティ』」の発表内容に基づいて紹介していきます。

2022年3月時点の Kubernetes のセキュリティとして、The Cloud Native Computing Foundation(CNCF)の資格であるCertified Kubernetes Security Specialist(CKS)の範囲をベースに、デモを交えてKubernetesのセキュリティを整理しました。

アジェンダ

今回は、以下アジェンダの「CKS」「Kubernetes Security」を中心に解説します。

• CKS
  • CKSとは?
  • CKSの範囲
  • CKS対策
• Kubernetes Security
  • Cluster Setup
    • NetworkPolicy
    • CIS Benchmark
  • Cluster Hardening
    • RBAC
  • System Hardening
    • AppArmor
    • seccomp
  • Minimize Microservice Vulnerabilities
    • SecurityContext
    • Open Policy Agent
    • Pod Security Standards & Pod Security Admission
    • Container Runtime Sandboxes
  • Supply Chain Security
    • Trivy
  • Monitoring, Logging and Runtime Security
    • Falco
• 参考資料

※Pod Security Standards & Pod Security Admissionは、発表時はPodSecurityPolicyでしたが、Kubernetes v1.25以降から廃止となりました。発表時は、Kubernetes v1.25以前のため解説しましたが、本記事ではPod Security Standards & Pod Security Admission の内容に変更します。

※Open Policy Agentについては、本連載第1回「CI/CD最新事情」にある「CI & CD Security」の「3.ポリシーチェック」の箇所と同内容のため、割愛します。

発表資料と動画については、下記のリンクを参照してください。
【資料リンク】
【動画リンク】

CKS

最初に、CKS概要と発表時点の範囲、試験対策及び発表時のデモ環境の構築について説明します。

CKSとは?

CKS(Certified Kubernetes Security Specialist)は、CNCF(The Cloud Native Computing Foundation)が主催する、コンテナベースのアプリケーションとKubernetesプラットフォームのビルド、デプロイ、ランタイム時のセキュリティを確保する幅広いベストプラクティスの実行能力を証明する認定試験です。

受験するには、CNCFが主催するCKA(Certified Kubernetes Administrator)を認定していることが前提となります。認定試験の詳細については、以下を参照ください。
【Certified Kubernetes Security Specialist(CKS)】

CKSの範囲

発表時(2022年3月)は、その時点の試験範囲から以下の項目と内容をピックアップして発表しました。

※上記は発表時(2022年3月)の試験範囲を基にしているため、最新情報と異なる場合があります。最新情報は、こちらを参照ください。

CKSの対策

CKSの対策では、発表時のデモを含め、コントロールプレーンとワーカーノードの両方を操作できる環境を準備しました。kubeadmとOracle Cloud Infrastructure(Always-Free)を利用して、以下の環境を構築しました。

環境構築手順、デモで利用したソースコードやマニフェストファイルは、以下で公開しています。
【ochacafe-s5-3】

Kubernetes Security

Cluster Setup

Kubernetesクラスタ上で稼働するPod同士が通信するトラフィックを制御するNetworkPolicyとCIS Benchmarkを使用して、Kubernetesのコンポーネントのセキュリティ対策について学びます。

NetworkPolicy

NetworkPolicyは、Kubernetesクラスタ内における、Pod同士が通信するトラフィックルールを規定できる仕組みです。Pod間の通信、Namespaceを跨いだPod間の通信をIPアドレスまたはポートレベル(OSI参照モデルレイヤ3/レイヤ4)で制御します。

NetworkPolicyを利用するには、NetworkPolicyに対応したネットワークプラグイン(CNIプラグイン)が必要です。主なネットワークプラグインは以下となります。発表時のデモ環境では、calicoをKubernetesクラスタにインストールしました。

• cilium
• calico
• Weave Net
• Kube-Router

実際にNetworkPolicyを行う上で、まずはホワイトリストとブラックリストから整理していきます。

ホワイトリストは、予め全てのトラフィックを遮断して特定のトラフィックのみを許可する形式です。ブラックリストは、予め全てのトラフィックを許可して特定のトラフィックのみを遮断する形式です。実際のところ、必要な通信以外は遮断するホワイトリストを使用するユースケースが多いと思われます。

以下は、全ての送受信トラフィックを許可および拒否するマニフェストの例です。

【全ての送受信トラフィックの許可】

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

【全ての送受信トラフィックを拒否】

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

Kubernetesクラスタ上で、このマニフェストを適用することでトラフィックを制御できます。基本的に設定対象となるPodに対して、Ingress/Egressのルールを定義します。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
    name: example-networkpolicy
spec:
  podSelector: 
  # 設定対象 Pod のラベルセレクタを定義
  policyTypes:
  - Ingress # Ingress ルールを指定する場合明示
  - Egress # Egress ルールを指定する場合明示
  ingress:
  - from:
    # Ingress ルールを定義
    ports:
    # 許可する受信ポート番号とプロトコルを定義
  egress:
  - to:
　　# Egress ルールを定義
    ports:
    # 許可する宛先ポート番号とプロトコルを定義

IngressとEgressの各ルールの指定方法は同じ形式です。

デモで実施したNetworkPolicyを見ていきます。

1. 全ての送信トラフィックを許可、受信トラフィックは拒否
Namespace defaultとNamespace testを作成し各ネームスペースにNginx Podを2個配備して、全ての送信トラフィックを許可、受信トラフィックは拒否するマニフェストを各ネームスペースに適用します。

【マニフェストファイル:egress-only-allow-networkpolicy.yaml】

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

Namespace defaultから内外への送信はできますが、受信はできなくなります。

2.「app: pod1」から「app: pod2」のみ受信許可
Namespace defaultにあるapp: pod1のPodからapp: pod2のPodへの受信のみを許可し、それ以外は拒否するNetwork PolicyをNamespace defaultに適用します。IngressルールにpodSelectorを利用した例です。

【マニフェストファイル:sp-pod-allow-networkpolicy.yaml】

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: sp-pod-allow-networkpolicy
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: pod2
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: pod1
    ports:
    - protocol: TCP
      port: 80

3. Namespace defaultのPodから「app: pod3」のみ受信許可
Namespace defaultから「app: pod1」と「app: pod2」のPodから「app: pod3」のPodへのアクセスは許可、「app: pod4」のPodへのアクセスは拒否するNetworkPolicyをNamespace defaultに適用します。IngressルールにnamespaceSelectorを利用した例です。

【マニフェストファイル:sp-namespace-allow-networkpolicy.yaml】

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: sp-namespace-allow-networkpolicy
  namespace: test
spec:
  podSelector:
    matchLabels:
      app: pod3
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: default
    ports:
    - protocol: TCP
      port: 80

4. 特定のIP Podから「app: pod3」のみ受信許可
Namespace testにある「app: pod3」のPodは、Namespace defaultにある192.168.173.130のIPアドレスを持つPodからのみ受信を許可するNetworkPolicyを適用します。IngressルールにipBlockを利用した例です。

【マニフェストファイル:sp-ip-allow-networkpolicy.yaml】

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: sp-ip-allow-networkpolicy
  namespace: test
spec:
  podSelector:
    matchLabels:
      app: pod3
  policyTypes:
  - Ingress
  ingress:
  - from:
    - ipBlock:
        cidr: 192.168.173.130/32
    ports:
    - protocol: TCP
      port: 80

IngressのルールにpodSelector、namespaceSelector、ipBlockを用いた簡単なNetworkPolicyですが、基本的なPodの通信制御です。