securing-kubernetes-on-cloud

クラウド上の Kubernetes のセキュリティ保護

使用するタイミング

• セキュリティ要件を満たす本番環境に、新しいマネージド Kubernetes クラスターをデプロイする場合
• セキュリティ監査やペネトレーションテストでの指摘を受けて、既存の EKS、AKS、GKE クラスターを強化する場合
• Pod 内の静的なクラウド認証情報をなくすために、ワークロード ID を導入する場合
• コンテナーエスケープを防ぐために、名前空間全体で Pod セキュリティポリシーを適用する場合
• コンテナーレベルの脅威を検出するために、ランタイムセキュリティ監視を統合する場合

次の場合は使用しないでください。 ECS Fargate や Azure Container Instances など、Kubernetes を使用しないコンテナーデプロイ、コンテナー内のアプリケーションレベルのセキュリティ（securing-serverless-functions を参照）、または CI/CD パイプラインのセキュリティ（implementing-cloud-devsecops を参照）。

前提条件

• 管理者アクセス権のある、EKS、AKS、または GKE 上にプロビジョニングされたマネージド Kubernetes クラスター
• クラスター管理者の認証情報で設定された kubectl
• Kubernetes RBAC、名前空間、セキュリティコンテキストに関する知識
• ネットワークポリシーに対応したコンテナーネットワークインターフェースプラグイン（Calico、Cilium）

ワークフロー

ステップ 1：Pod Security Standards を適用する

名前空間レベルで Pod Security Admission ラベルを適用し、本番環境の名前空間で Restricted プロファイルを強制します。Pod Security Policies は Kubernetes v1.25 で削除され、Pod Security Admission に置き換えられました。

# Production namespace with restricted Pod Security Standard
apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted
---
# Staging namespace with baseline enforcement
apiVersion: v1
kind: Namespace
metadata:
  name: staging
  labels:
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

# Pod spec compliant with restricted profile
apiVersion: v1
kind: Pod
metadata:
  name: secure-app
  namespace: production
spec:
  automountServiceAccountToken: false
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    fsGroup: 1000
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: app
      image: company/app:v2.1@sha256:abc123...
      securityContext:
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        capabilities:
          drop: ["ALL"]
      resources:
        limits:
          cpu: "500m"
          memory: "256Mi"
        requests:
          cpu: "100m"
          memory: "128Mi"

ステップ 2：クラウドネイティブなワークロード ID を設定する

Kubernetes のサービスアカウントをクラウド IAM ロールに紐付け、Pod 内の静的なクラウド認証情報をなくします。

# EKS: IAM Roles for Service Accounts (IRSA)
eksctl create iamserviceaccount \
  --cluster production-cluster \
  --namespace production \
  --name web-app-sa \
  --attach-policy-arn arn:aws:iam::123456789012:policy/WebAppS3ReadOnly \
  --approve

# GKE: Workload Identity
gcloud iam service-accounts create web-app-sa \
  --project=my-gcp-project

gcloud iam service-accounts add-iam-policy-binding \
  [email protected] \
  --role roles/storage.objectViewer \
  --member "serviceAccount:my-gcp-project.svc.id.goog[production/web-app-sa]"

kubectl annotate serviceaccount web-app-sa \
  --namespace production \
  iam.gke.io/gcp-service-account=web-app-sa@my-gcp-project.iam.gserviceaccount.com

# AKS: Azure AD Workload Identity
az identity create --name web-app-identity --resource-group production-rg
az identity federated-credential create \
  --name web-app-federation \
  --identity-name web-app-identity \
  --resource-group production-rg \
  --issuer "$(az aks show -n production-cluster -g production-rg --query oidcIssuerProfile.issuerUrl -o tsv)" \
  --subject system:serviceaccount:production:web-app-sa

ステップ 3：ネットワークポリシーを実装する

最小権限の原則に従って Pod 間の通信を制限するネットワークポリシーをデプロイします。デフォルトでは、Kubernetes はすべての Pod 間の通信を許可します。

# Default deny all ingress and egress in production namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
---
# Allow web-app to receive traffic from ingress controller only
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-ingress-to-web
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: web-app
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              name: ingress-nginx
      ports:
        - protocol: TCP
          port: 8080
---
# Allow web-app to connect to database only
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-web-to-db
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: web-app
  policyTypes:
    - Egress
  egress:
    - to:
        - podSelector:
            matchLabels:
              app: postgres
      ports:
        - protocol: TCP
          port: 5432
    - to:
        - namespaceSelector: {}
          podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - protocol: UDP
          port: 53

ステップ 4：最小権限で RBAC を設定する

Kubernetes RBAC ロールの適用範囲を、特定の名前空間とリソースに限定します。管理者以外のユーザーには ClusterRoleBinding を使用しないでください。

# Developer role scoped to specific namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: developer-role
  namespace: staging
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log", "services", "configmaps"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "watch", "update", "patch"]
  # Explicitly deny secrets access
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developer-binding
  namespace: staging
subjects:
  - kind: Group
    name: developers
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: developer-role
  apiGroup: rbac.authorization.k8s.io

ステップ 5：イメージのアドミッション制御を導入する

アドミッションコントローラーを使用して、信頼できるレジストリの署名済みイメージのみがデプロイされるようにします。ポリシーの適用には OPA/Gatekeeper または Kyverno を導入します。

# Kyverno policy: require images from approved registries
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: restrict-image-registries
spec:
  validationFailureAction: Enforce
  rules:
    - name: validate-registries
      match:
        any:
          - resources:
              kinds: ["Pod"]
      validate:
        message: "Images must come from approved registries"
        pattern:
          spec:
            containers:
              - image: "123456789012.dkr.ecr.us-east-1.amazonaws.com/* | gcr.io/my-gcp-project/*"
---
# Kyverno policy: require image digest (no mutable tags)
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-image-digest
spec:
  validationFailureAction: Enforce
  rules:
    - name: require-digest
      match:
        any:
          - resources:
              kinds: ["Pod"]
      validate:
        message: "Images must use digest references, not tags"
        pattern:
          spec:
            containers:
              - image: "*@sha256:*"

ステップ 6：ランタイムセキュリティ監視を有効にする

コンテナー内でのプロセス実行、ファイルシステムの変更、ネットワーク接続など、異常な動作を検出するランタイムセキュリティツールをデプロイします。

# Deploy Falco for runtime threat detection
helm repo add falcosecurity https://falcosecurity.github.io/charts
helm install falco falcosecurity/falco \
  --namespace falco-system --create-namespace \
  --set falcosidekick.enabled=true \
  --set falcosidekick.config.slack.webhookurl="https://hooks.slack.com/services/xxx"

# Run kube-bench for CIS Kubernetes Benchmark assessment
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job-eks.yaml
kubectl logs -l app=kube-bench

重要な概念

用語	定義
Pod Security Standards	Pod Security Admission を通じて適用される 3 つのプロファイル（Privileged、Baseline、Restricted）で、Pod のセキュリティコンテキスト機能を制御します
ワークロード ID	Kubernetes のサービスアカウントをクラウド IAM ロールに紐付け、認証情報なしでクラウド API にアクセスできるようにするクラウドネイティブな仕組みです（IRSA、GKE WI、AKS MI）
Network Policy	Pod 間で許可されるイングレスおよびエグレスのトラフィックフローを定義し、CNI プラグインによって適用される Kubernetes リソースです
Admission Controller	API リクエストを永続化の前にインターセプトし、セキュリティポリシーに照らしてリソースを検証または変更する Kubernetes プラグインです
RBAC	Kubernetes のロールベースアクセス制御で、どの名前空間のどのリソースに対して、どのような操作（動詞）を ID が実行できるかを定義します
Seccomp Profile	コンテナープロセスが実行できるシステムコールを制限し、カーネルの攻撃対象領域を縮小する Linux カーネル機能です
Service Mesh	サービス間通信に相互 TLS、トラフィックポリシー、可観測性を提供するインフラストラクチャ層です（Istio、Linkerd）

ツールとシステム

• Falco：カーネルレベルのシステムコール監視を使用して、コンテナ内の異常な動作を検知するオープンソースのランタイムセキュリティエンジン
• Kyverno：セキュリティポリシーに基づいてリソースのアドミッション制御、変更、生成を行う、Kubernetes ネイティブのポリシーエンジン
• kube-bench：クラスタ構成をセキュリティのベストプラクティスに照らして確認する、CIS Kubernetes Benchmark 評価ツール
• Trivy：SBOM 生成機能を備えた、コンテナイメージ、ファイルシステム、Kubernetes リソース向けの脆弱性スキャナー
• Calico/Cilium：ネットワークポリシーの適用や、eBPF ベースの監視などの高度なネットワークセキュリティ機能を提供する CNI プラグイン

よくあるシナリオ

シナリオ：侵害されたコンテナイメージによるクリプトマイナーのデプロイ

コンテキスト：GuardDuty Extended Threat Detection が AttackSequence:EKS/CompromisedCluster 検出結果を生成します。開発者が、コンテナの起動時に実行される XMRig クリプトマイナーを埋め込んだ公開 Docker イメージを取得しました。

アプローチ：

1. 対象のラベルを指定する全通信拒否ネットワークポリシーを適用して、影響を受けた Pod を隔離します
2. コンテナイメージのダイジェストを取得し、Trivy でスキャンして埋め込まれたバイナリを特定します
3. Kubernetes の監査ログを確認し、侵害されたイメージをデプロイした人物と時刻を特定します
4. 承認済みのプライベートレジストリのイメージのみを必須とする Kyverno ClusterPolicy をデプロイします
5. タグの変更を悪用する攻撃を防ぐため、イメージダイジェストのピン留めを有効にします
6. クリプトマイニングプロセスのシグネチャ（/usr/bin/xmrig、stratum+tcp 接続）を検知するルールを設定した Falco をデプロイします

落とし穴：イメージダイジェストと監査ログを取得する前に Pod を削除すると、フォレンジックの証拠が失われます。特定のイメージタグだけをブロックすると、攻撃者は別のタグで再プッシュできます。

出力形式

Kubernetes Security Assessment Report
=======================================
Cluster: production-cluster (EKS 1.29)
Provider: AWS (us-east-1)
Assessment Date: 2025-02-23
Tool: kube-bench v0.8.0 + manual review

CIS KUBERNETES BENCHMARK RESULTS:
  Total Controls: 124
  Passed: 98 (79%)
  Failed: 18 (15%)
  Warnings: 8 (6%)

CRITICAL FINDINGS:
  [K8S-001] 3 namespaces lack Pod Security Standards enforcement
    Namespaces: monitoring, logging, default
    Remediation: Apply restricted PSA labels

  [K8S-002] Default service account tokens auto-mounted in 12 deployments
    Risk: Credential theft if container is compromised
    Remediation: Set automountServiceAccountToken: false

  [K8S-003] No network policies in production namespace
    Risk: Unrestricted lateral movement between all pods
    Remediation: Deploy default-deny policy with explicit allow rules

HIGH FINDINGS:
  [K8S-004] 5 pods running as root with privileged security context
  [K8S-005] Images deployed using mutable tags (:latest) in 8 deployments
  [K8S-006] RBAC ClusterRoleBinding grants cluster-admin to developers group