implementing-rbac-hardening-for-kubernetes について
Kubernetes 管理者やセキュリティチーム向けの RBAC 強化ガイドです。最小権限、バインディングの監査、ワークロード別サービスアカウント、危険な権限、OIDC 認証を扱います。
主な機能
- 01ClusterRole バインディングの監査
- 02名前空間スコープのロールを優先
- 03専用サービスアカウントの割り当て
- 04権限昇格につながる権限の制限
- 05OIDC ユーザー認証の設定
活用シーン
- 01過剰な cluster-admin バインディングの確認と削除
- 02過剰な権限を持つサービスアカウントの特定
- 03Kubernetes ワークロードへの最小権限の適用
- 04クラスター RBAC セキュリティの評価
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ mukul975/ anthropic-cybersecurity-skills --skill implementing-rbac-hardening-for-kubernetesインストール後、Claude Code で/implementing-rbac-hardening-for-kubernetesを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
LICENSEassets/template.mdreferences/api-reference.mdstandards.mdworkflows.mdscripts/agent.pyprocess.py詳細
Kubernetes の RBAC 強化の実装
概要
Kubernetes の RBAC は、ユーザー、グループ、サービスアカウントに割り当てられたロールに基づいて、クラスターリソースへのアクセスを制御します。デフォルトの設定では過剰な権限が付与されていることが多く、積極的な強化を行わないと、RBAC は権限昇格、ラテラルムーブメント、データ窃取の主要な攻撃ベクトルになります。強化には、最小権限の原則の適用、不要な ClusterRole バインディングの排除、サービスアカウントの分離、外部 ID プロバイダーとの統合、継続的な監査が必要です。
使用するタイミング
- 環境に Kubernetes の RBAC 強化機能をデプロイまたは設定する場合
- コンプライアンス要件に沿ったセキュリティ制御を確立する場合
- この分野のセキュリティアーキテクチャを構築または改善する場合
- この実装が必要となるセキュリティ評価を実施する場合
前提条件
- RBAC が有効な Kubernetes クラスター v1.24 以降(v1.6 以降はデフォルトで有効)
- 初回監査用の cluster-admin 権限を持つ kubectl アクセス
- ユーザー認証用の外部 ID プロバイダー(OIDC)
- API サーバーで監査ログが有効になっていること
強化の基本原則
1. cluster-admin の乱立を解消する
監査を実施し、不要な cluster-admin バインディングを削除します。
# List all cluster-admin bindings
kubectl get clusterrolebindings -o json | jq -r '
.items[] |
select(.roleRef.name == "cluster-admin") |
"\(.metadata.name) -> \(.subjects[]? | "\(.kind)/\(.name) (\(.namespace // "cluster"))")"
'
2. ClusterRole よりも名前空間スコープのロールを優先する
ClusterRole と ClusterRoleBinding の代わりに、Role と RoleBinding を使用します。
# Good: Namespace-scoped role
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: application
name: app-developer
rules:
- apiGroups: ["apps"]
resources: ["deployments"]
verbs: ["get", "list", "watch", "create", "update", "patch"]
- apiGroups: [""]
resources: ["pods", "pods/log"]
verbs: ["get", "list", "watch"]
- apiGroups: [""]
resources: ["configmaps"]
verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
namespace: application
name: app-developer-binding
subjects:
- kind: Group
name: dev-team
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: app-developer
apiGroup: rbac.authorization.k8s.io
3. ワークロードごとに専用のサービスアカウントを用意する
apiVersion: v1
kind: ServiceAccount
metadata:
name: payment-processor
namespace: payments
automountServiceAccountToken: false # Disable auto-mount
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: payment-processor
namespace: payments
spec:
template:
spec:
serviceAccountName: payment-processor
automountServiceAccountToken: true # Only mount when explicitly needed
containers:
- name: processor
image: payments/processor:v2.1@sha256:abc...
4. 危険な権限を制限する
権限昇格を可能にする権限をブロックします。
# Dangerous verbs/resources to restrict:
# - secrets: get, list, watch (exposes all secrets in namespace)
# - pods/exec: create (enables command execution in pods)
# - pods: create with privileged securityContext
# - serviceaccounts/token: create (generates new tokens)
# - clusterroles/clusterrolebindings: create, update (self-escalation)
# - nodes/proxy: create (bypasses API server authorization)
# Safe read-only role example
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: security-viewer
rules:
- apiGroups: [""]
resources: ["pods", "services", "namespaces", "nodes"]
verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
resources: ["deployments", "daemonsets", "statefulsets"]
verbs: ["get", "list", "watch"]
- apiGroups: ["networking.k8s.io"]
resources: ["networkpolicies"]
verbs: ["get", "list", "watch"]
5. ユーザー認証に OIDC を統合する
# API server flags for OIDC integration
apiVersion: v1
kind: Pod
metadata:
name: kube-apiserver
spec:
containers:
- name: kube-apiserver
command:
- kube-apiserver
- --oidc-issuer-url=https://idp.company.com
- --oidc-client-id=kubernetes
- --oidc-username-claim=email
- --oidc-groups-claim=groups
- --oidc-ca-file=/etc/kubernetes/pki/oidc-ca.crt
RBAC 監査プロセス
ステップ 1:すべてのバインディングを列挙する
# All ClusterRoleBindings with subjects
kubectl get clusterrolebindings -o json | jq -r '
.items[] | select(.subjects != null) |
.subjects[] as $s |
"\(.metadata.name) | \(.roleRef.name) | \($s.kind)/\($s.name)"
' | sort | column -t -s '|'
# All RoleBindings across namespaces
kubectl get rolebindings --all-namespaces -o json | jq -r '
.items[] | select(.subjects != null) |
.subjects[] as $s |
"\(.metadata.namespace) | \(.metadata.name) | \(.roleRef.name) | \($s.kind)/\($s.name)"
' | sort | column -t -s '|'
ステップ 2:過剰な権限を持つサービスアカウントを特定する
# Find service accounts with cluster-admin or admin roles
kubectl get clusterrolebindings -o json | jq -r '
.items[] |
select(.roleRef.name == "cluster-admin" or .roleRef.name == "admin") |
select(.subjects[]?.kind == "ServiceAccount") |
"\(.subjects[] | select(.kind == "ServiceAccount") | "\(.namespace)/\(.name)")"
'
ステップ 3:デフォルトのサービスアカウントの使用状況を確認する
# Find pods using the default service account
kubectl get pods --all-namespaces -o json | jq -r '
.items[] |
select(.spec.serviceAccountName == "default" or .spec.serviceAccountName == null) |
"\(.metadata.namespace)/\(.metadata.name)"
'
ステップ 4:トークンの自動マウントを確認する
# Find pods with auto-mounted service account tokens
kubectl get pods --all-namespaces -o json | jq -r '
.items[] |
select(.spec.automountServiceAccountToken != false) |
"\(.metadata.namespace)/\(.metadata.name) sa=\(.spec.serviceAccountName // "default")"
'
ツール
rbac-lookup
# Install rbac-lookup
kubectl krew install rbac-lookup
# View RBAC for a specific user
kubectl rbac-lookup [email protected]
# View all RBAC bindings wide format
kubectl rbac-lookup --kind user -o wide
rakkess(アクセス権の確認)
# Install rakkess
kubectl krew install access-matrix
# Show access matrix for current user
kubectl access-matrix
# Show access for a specific service account
kubectl access-matrix --sa payments:payment-processor
参考資料
コメント
Markdown 対応