Japanese - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

Kubernetes Role-Based Access Control(RBAC)

AWSハッキングの学習と練習：HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングの学習と練習：HackTricks Training GCP Red Team Expert (GRTE)

HackTricksをサポートする

ロールベースアクセス制御（RBAC）

Kubernetesには、APIサーバーへの利用権限を設定するのに役立つロールベースアクセス制御（RBAC）という認可モジュールがあります。

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

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

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

  3. RoleBinding\ClusterRoleBinding – Role\ClusterRoleとSubjectの接続。

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

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

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

  • ネームスペースリソース（Podなど）、すべてのネームスペースをまたいで。

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

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

テンプレート

RoleまたはClusterRoleのテンプレートでは、ロールの名前、名前空間（ロールの場合）、そしてロールのapiGroups、リソース、動詞を指定する必要があります：

  • 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

  • core APIグループ内のusers、groups、serviceaccountsおよびauthentication.k8s.io APIグループ内のuserextrasでimpersonate動詞を使用します。

各リソースがサポートするすべての動詞を見つけるには、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は、ユーザーまたはユーザーのセットに定義された権限を付与します。それはサブジェクト（ユーザー、グループ、またはサービスアカウント）のリストと、付与される役割への参照を保持します。RoleBindingは特定の名前空間内で権限を付与し、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

アクセス許可は追加されますので、"list"と"delete"のシークレットを持つclusterRoleがある場合、それを"get"を持つ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

特権昇格のための役割/ClusterRolesの乱用

Abusing Roles/ClusterRoles in Kubernetes

AWSハッキングの学習と実践:HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングの学習と実践: HackTricks Training GCP Red Team Expert (GRTE)

HackTricksのサポート
PreviousKubernetes EnumerationNextAbusing Roles/ClusterRoles in Kubernetes

Last updated