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

Kubernetes はコンテナの大規模なオーケストレーションと管理に革命をもたらし、クラウドネイティブ アプリケーションをデプロイするためのデファクトスタンダードとなりましたが、その分散アーキテクチャと 本質的な複雑さは、従来のデプロイメントモデルと比較して、攻撃対象領域を大幅に拡大 させます。一般的な Kubernetes クラスタには、相互接続された数十のコンポーネント ——API server、etcd、scheduler、controller manager、kubelet、kube-proxy——が関与し、それぞれが 固有の潜在的な脆弱性と特定のハードニング要件を持っています。pods が絶えず 作成・破棄され、workloads が nodes 間を移行し、ネットワークポリシーをリアルタイムで 適用しなければならない K8s の動的な性質は、セキュリティを多次元的な課題とし、 多層防御のアプローチを必要とします。RBAC における過度に 寛容な権限、pods 間の無制限な通信を許可する network policies の欠如、 特権 capabilities を持つ root として実行されるコンテナ、暗号化されていない etcd に平文で保存される secrets といった安全でないデフォルト設定は、不適切に 構成された K8s 環境で一般的に悪用される攻撃ベクトルを表します。本記事では、Kubernetes クラスタのハードニングに関する基本的なプラクティスを取り上げ、 ロールベースのアクセス制御（RBAC）、pod security standards、マイクロセグメンテーションのための network policies、 安全なシークレット管理、ポリシー適用のための admission controllers、 Falco などのツールによるランタイムセキュリティ監視、そして CIS Kubernetes Benchmark などの業界ベンチマークへの準拠を網羅し、本番環境で安全な Kubernetes クラスタを 構築・運用するための完全なロードマップを提供します。

K8s セキュリティアーキテクチャ

Kubernetes クラスタには複数の重要なコンポーネントがあります：

  • Control Plane： API Server、etcd、scheduler、controller manager
  • Nodes： kubelet、kube-proxy、container runtime
  • Add-ons： DNS、dashboard、ingress controllers

RBAC（Role-Based Access Control）

RBAC は K8s セキュリティの基盤であり、API server を介して誰が何にアクセスできるかを制御します。

RBAC の設定

      # 特定の namespace 内の pods を読み取るための Role
      apiVersion: rbac.authorization.k8s.io/v1
      kind: Role
      metadata:
      namespace: production
      name: pod-reader
      rules:
      - apiGroups: [""]
      resources: ["pods"]
      verbs: ["get", "list"]
      ---
      # RoleBinding は role をユーザーに関連付ける
      apiVersion: rbac.authorization.k8s.io/v1
      kind: RoleBinding
      metadata:
      name: read-pods
      namespace: production
      subjects:
      - kind: User
      name: jane
      apiGroup: rbac.authorization.k8s.io
      roleRef:
      kind: Role
      name: pod-reader
      apiGroup: rbac.authorization.k8s.io

RBAC の原則

  • Least privilege： 必要な権限のみを付与する
  • ClusterAdmin を避ける： 機能ごとに特定の roles を作成する
  • Service accounts： 各 pod は専用の SA を持つべき
  • Namespace isolation： ClusterRoleBindings ではなく RoleBindings を使用する

Pod Security

Pod Security Standards

Kubernetes 1.25+ は非推奨の PSPs に代わり Pod Security Admission を使用します：

  • Privileged： 制限なし、信頼された workloads 向け
  • Baseline： 最小限の制限、既知の権限昇格を防止
  • Restricted： 大幅に制限され、ハードニングのベストプラクティスに従う

Security Context

      apiVersion: v1
      kind: Pod
      metadata:
      name: secure-pod
      spec:
      securityContext:
      runAsNonRoot: true
      runAsUser: 1000
      fsGroup: 2000
      seccompProfile:
      type: RuntimeDefault
      containers:
      - name: app
      image: myapp:latest
      securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
      drop:
      - ALL

Network Policies

デフォルトでは、pods は自由に通信できます。Network Policies はセグメンテーションを実装します： 

      apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
      name: api-allow-from-frontend
      namespace: production
      spec:
      podSelector:
      matchLabels:
      app: api
      policyTypes:
      - Ingress
      ingress:
      - from:
      - podSelector:
      matchLabels:
      app: frontend
      ports:
      - protocol: TCP
      port: 8080

シークレット管理

  • secrets を決してハードコードしない： Kubernetes Secrets または外部 vaults を使用する
  • etcd encryption： etcd の encryption-at-rest を有効にする
  • External Secrets Operator： Vault、AWS Secrets Manager と統合する
  • secrets をローテーションする： 自動ローテーションを実装する
  • secrets 向けの RBAC： secrets を読み取れる対象を制限する

Image Security

  • Private registries： 本番環境で public registries を使用しない
  • Image scanning： 脆弱性スキャンに Trivy、Clair、Anchore を使用する
  • Image signing： 完全性を検証するために Cosign を使用する
  • Admission controllers： デプロイ前に images を検証する
  • Distroless images： 攻撃対象領域を最小化する

Admission Controllers

  • OPA/Gatekeeper： コンプライアンスのための Policy-as-code
  • Kyverno： Kubernetes ネイティブのポリシー管理
  • ImagePolicyWebhook： image の署名を検証する
  • ResourceQuota： namespace ごとにリソースを制限する
  • LimitRanger： CPU/メモリの制限を強制する

API Server ハードニング

  • audit logging を有効にする
  • すべての通信に TLS を使用する
  • anonymous auth を無効にする
  • API rate limiting を実装する
  • API server へのアクセスを制限する（network ACLs）

Runtime Security

  • Falco： K8s 向けのランタイム脅威検出
  • Sysdig Secure： ランタイム保護とコンプライアンス
  • Aqua Security： ライフサイクル全体のコンテナセキュリティ

コンプライアンスと監査

  • CIS Kubernetes Benchmark： ハードニングフレームワーク
  • kube-bench： 自動化された CIS コンプライアンスチェック
  • kube-hunter： K8s 向けのペネトレーションテストツール
  • Audit logs： 分析のために SIEM に集約する

Service Mesh Security

Service meshes（Istio、Linkerd）はセキュリティレイヤーを追加します：

  • pods 間の自動 mTLS
  • きめ細かな認可ポリシー
  • 転送中のトラフィック暗号化
  • Observability と auditability

最終的な推奨事項

K8s セキュリティは共有責任です。多層防御を実装してください：RBAC、 network policies、pod security、シークレット管理、ランタイム保護。 自動化されたコンプライアンスツール（kube-bench）を使用し、継続的に監視してください。 チームに K8s セキュリティのトレーニングを行ってください——複雑さには専門的な expertise が必要です。