※本記事にはアフィリエイトリンクが含まれます。詳しくはプライバシーポリシー・広告掲載についてをご覧ください。
# Kubernetesセキュリティ実践ガイド：RBAC・NetworkPolicy・Secrets管理【2026年版】 ## 概要 Kubernetes（K8s）はコンテナオーケストレーションの事実上の標準となり、クラウドネイティブ開発の中心に位置している。しかし、その複雑なアーキテクチャと多数のコンポーネントは、設定ミスによるセキュリティリスクを生みやすい。Kubernetes固有の攻撃手法（RBAC権限昇格・コンテナエスケープ・Secrets漏洩など）を理解し、適切な対策を講じることが2026年のクラウドネイティブセキュリティの核心だ。 — ## Kubernetesの攻撃対象（Attack Surface） K8s環境の主な攻撃対象は以下の通り: “` ┌─────────────────────────────────────────┐ │ Kubernetes Cluster │ │ │ │ ┌──────────┐ ┌──────────────────┐ │ │ │ API Server│ │ etcd（暗号化DB） │ │ │ │ ← 認証・認可 │ ← Secretsを格納 │ │ │ └──────────┘ └──────────────────┘ │ │ │ │ ┌──────────┐ ┌──────────────────┐ │ │ │ kubelet │ │ コンテナランタイム│ │ │ │ ← ノードAPI│ │ ← エスケープリスク│ │ │ └──────────┘ └──────────────────┘ │ └─────────────────────────────────────────┘ “` — ## 1. RBAC（ロールベースアクセス制御） RBACはK8sにおける最重要のアクセス制御機能だ。ユーザー・サービスアカウントに必要最小限の権限のみを付与する「最小権限の原則」を徹底する。 ### よくある設定ミス “`yaml # 危険: cluster-adminをサービスアカウントに付与 apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: bad-practice subjects: – kind: ServiceAccount name: my-app namespace: default roleRef: kind: ClusterRole name: cluster-admin # ← 絶対NG apiGroup: rbac.authorization.k8s.io “` ### 安全な設定例 “`yaml # 推奨: Podの読み取りのみに限定したRole apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: production name: pod-reader rules: – apiGroups: [“”] resources: [“pods”] verbs: [“get”, “list”, “watch”] # 必要なverb のみ — apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: read-pods namespace: production # 特定namespaceに限定 subjects: – kind: ServiceAccount name: my-app roleRef: kind: Role name: pod-reader apiGroup: rbac.authorization.k8s.io “` ### RBACチェックポイント | チェック項目 | 確認コマンド | |————|————| | 過剰なClusterRoleBinding | `kubectl get clusterrolebindings -o yaml | grep -A2 cluster-admin` | | 匿名ユーザーの権限 | `kubectl auth can-i –list –as=system:anonymous` | | ServiceAccountの権限棚卸し | `kubectl get rolebinding,clusterrolebinding –all-namespaces` | — ## 2. NetworkPolicy（ネットワーク分離） デフォルトのK8s環境では、Pod間の通信は無制限だ。NetworkPolicyを定義することで、不要な通信経路を遮断し、攻撃者が侵入後に横移動（Lateral Movement）することを防ぐ。 “`yaml # 特定Podへのアクセスを制限するNetworkPolicy apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: restrict-db-access namespace: production spec: podSelector: matchLabels: app: database policyTypes: – Ingress ingress: – from: – podSelector: matchLabels: role: backend # backendからのみ接続許可 ports: – protocol: TCP port: 5432 “` **実装のポイント:** – まず「デフォルト拒否」ポリシーを適用し、必要な通信のみを許可リストで開放 – CNI（Calico/Cilium等）がNetworkPolicyをサポートしていること確認 — ## 3. Secrets管理 K8s Secretsはデフォルトでbase64エンコードされるだけで暗号化されない。etcdへの直接アクセスや権限昇格で簡単に参照できてしまう。 ### 対策1: etcd暗号化の有効化 “`yaml # /etc/kubernetes/encryption-config.yaml apiVersion: apiserver.config.k8s.io/v1 kind: EncryptionConfiguration resources: – resources: – secrets providers: – aescbc: keys: – name: key1 secret:✅ おすすめのセキュリティソフト
※ アフィリエイトリンクを含みます。料金・詳細は各公式サイトでご確認ください。
コメント