Japanese - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

Kubernetes Role-Based Access Control(RBAC)

Support HackTricks

Role-Based Access Control (RBAC)

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

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

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

  2. Subject (ユーザー、グループ、またはサービスアカウント) – 権限を受け取るオブジェクト。

  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 動詞。

  • Authentication

  • コア 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
HackTricksをサポートする
PreviousKubernetes EnumerationNextAbusing Roles/ClusterRoles in Kubernetes

Last updated