Kubernetes Role-Based Access Control(RBAC)

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!

• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.

• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

Role-Based Access Control (RBAC)

Kubernetesには、APIサーバーへの利用権限を設定するのに役立つRole-Based Access Control（RBAC）という認可モジュールがあります。

RBACの権限モデルは、3つの個別の部分から構成されています：

1. Role\ClusterRole ­– 実際の権限。_ルール_を含み、これは一連の権限を表します。各ルールにはリソースと動詞が含まれます。動詞はリソースに適用されるアクションです。

2. Subject (ユーザー、グループ、またはServiceAccount) – 権限を受け取るオブジェクト。

3. RoleBinding\ClusterRoleBinding – Role\ClusterRoleとサブジェクトの接続。

「Roles」と「ClusterRoles」の違いは、ロールが適用される場所だけです – 「Role」は1つの特定のnamespaceにのみアクセスを付与しますが、「ClusterRole」はクラスター内のすべてのnamespaceで使用できます。さらに、ClusterRolesは以下へのアクセスも付与できます：

• クラスター範囲のリソース（ノードなど）。

• 非リソースエンドポイント（/healthzなど）。

• すべてのnamespaceにわたる名前空間リソース（Podなど）。

Kubernetes 1.6以降、RBACポリシーはデフォルトで有効になっています。しかし、RBACを有効にするには、次のようなものを使用できます：

kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options

テンプレート

Role または ClusterRole のテンプレートでは、ロールの名前、ネームスペース（ロールの場合）、そして apiGroups、resources、verbs を示す必要があります：

• apiGroups は、このルールが適用される異なる API ネームスペース を含む配列です。例えば、Pod 定義は apiVersion: v1 を使用します。rbac.authorization.k8s.io や [*] などの値を持つことができます。

• resources は、このルールが適用される リソースを定義する 配列です。すべてのリソースは次のコマンドで見つけることができます： kubectl api-resources --namespaced=true

• verbs は、許可された動詞 を含む配列です。Kubernetes の動詞は、リソースに適用する必要がある アクションの種類 を定義します。例えば、list 動詞はコレクションに対して使用され、"get" は単一のリソースに対して使用されます。

ルールの動詞

(この情報は ドキュメント から取得されました)

HTTP 動詞	リクエスト動詞
POST	create
GET, HEAD	get（個々のリソース用）、list（コレクション用、オブジェクトの完全な内容を含む）、watch（個々のリソースまたはリソースのコレクションを監視するため）
PUT	update
PATCH	patch
DELETE	delete（個々のリソース用）、deletecollection（コレクション用）

Kubernetes は、特定の動詞を使用して追加の権限の認可を確認することがあります。例えば：

• PodSecurityPolicy

• policy API グループの podsecuritypolicies リソースに対する use 動詞。

• RBAC

• rbac.authorization.k8s.io API グループの roles および clusterroles リソースに対する bind および escalate 動詞。

• 認証

• コア API グループの users、groups、および serviceaccounts に対する impersonate 動詞、authentication.k8s.io API グループの userextras。

各リソースがサポートするすべての動詞 は、kubectl api-resources --sort-by name -o wide を実行することで見つけることができます。

例

Role

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: defaultGreen
name: pod-and-pod-logs-reader
rules:
- apiGroups: [""]
resources: ["pods", "pods/log"]
verbs: ["get", "list", "watch"]

ClusterRole

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
# "namespace" omitted since ClusterRoles are not namespaced
name: secret-reader
rules:
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get", "watch", "list"]

例えば、特定のユーザーが実行できるようにClusterRoleを使用できます：

kubectl get pods --all-namespaces

RoleBindingとClusterRoleBinding

ドキュメントから: ロールバインディングは、ロールで定義された権限をユーザーまたはユーザーのセットに付与します。これは、主題（ユーザー、グループ、またはサービスアカウント）のリストと、付与されるロールへの参照を保持します。RoleBindingは特定のnamespace内で権限を付与しますが、ClusterRoleBindingはそのアクセスをクラスター全体に付与します。

piVersion: rbac.authorization.k8s.io/v1
# This role binding allows "jane" to read pods in the "default" namespace.
# You need to already have a Role named "pod-reader" in that namespace.
kind: RoleBinding
metadata:
name: read-pods
namespace: default
subjects:
# You can specify more than one "subject"
- kind: User
name: jane # "name" is case sensitive
apiGroup: rbac.authorization.k8s.io
roleRef:
# "roleRef" specifies the binding to a Role / ClusterRole
kind: Role #this must be Role or ClusterRole
name: pod-reader # this must match the name of the Role or ClusterRole you wish to bind to
apiGroup: rbac.authorization.k8s.io

ClusterRoleBinding

apiVersion: rbac.authorization.k8s.io/v1
# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.
kind: ClusterRoleBinding
metadata:
name: read-secrets-global
subjects:
- kind: Group
name: manager # Name is case sensitive
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: secret-reader
apiGroup: rbac.authorization.k8s.io

権限は加算的であるため、「リスト」と「削除」のシークレットを持つclusterRoleがある場合、それに「取得」を持つRoleを追加できます。したがって、常に自分のロールと権限をテストし、許可されているものを明示的に指定してください。デフォルトではすべてが拒否されます。

RBACの列挙

# Get current privileges
kubectl auth can-i --list
# use `--as=system:serviceaccount:<namespace>:<sa_name>` to impersonate a service account

# List Cluster Roles
kubectl get clusterroles
kubectl describe clusterroles

# List Cluster Roles Bindings
kubectl get clusterrolebindings
kubectl describe clusterrolebindings

# List Roles
kubectl get roles
kubectl describe roles

# List Roles Bindings
kubectl get rolebindings
kubectl describe rolebindings

権限昇格のためのRole/ClusterRolesの悪用

Abusing Roles/ClusterRoles in Kubernetes

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE)

HackTricksをサポートする

• サブスクリプションプランを確認してください！

• **💬 DiscordグループまたはTelegramグループに参加するか、Twitter 🐦 @hacktricks_liveをフォローしてください。

• HackTricksおよびHackTricks CloudのGitHubリポジトリにPRを提出してハッキングトリックを共有してください。