# Kubernetes Role-Based Access Control(RBAC) {{#include ../../banners/hacktricks-training.md}} ## Role-Based Access Control (RBAC) Kubernetesには、APIサーバーへの利用権限を設定するのに役立つ**Role-Based Access Control**（[**RBAC**](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)）という**認可モジュール**があります。 RBACの権限モデルは、**3つの個別の部分**から構成されています： 1. **Role\ClusterRole ­–** 実際の権限。権限のセットを表す_**ルール**_を含みます。各ルールには[リソース](https://kubernetes.io/docs/reference/kubectl/overview/#resource-types)と[動詞](https://kubernetes.io/docs/reference/access-authn-authz/authorization/#determine-the-request-verb)が含まれます。動詞はリソースに適用されるアクションです。 2. **Subject (ユーザー、グループ、またはServiceAccount) –** 権限を受け取るオブジェクト。 3. **RoleBinding\ClusterRoleBinding –** Role\ClusterRoleと対象の間の接続。 ![](https://www.cyberark.com/wp-content/uploads/2018/12/rolebiding_serviceaccount_and_role-1024x551.png) “**Roles**”と“**ClusterRoles**”の違いは、役割が適用される場所だけです。“**Role**”は**1つの特定の** **namespace**にのみアクセスを付与しますが、“**ClusterRole**”はクラスター内の**すべてのnamespace**で使用できます。さらに、**ClusterRoles**は以下へのアクセスも付与できます： - **クラスター範囲**のリソース（ノードなど）。 - **非リソース**エンドポイント（/healthzなど）。 - 名前空間リソース（Podなど）、**すべてのnamespace**にわたって。 **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 における動詞は、リソースに適用する必要がある **アクションの種類** を定義します。例えば、リスト動詞はコレクションに対して使用され、「get」は単一のリソースに対して使用されます。 ### ルールの動詞 (_この情報は_ [_**ドキュメント**_](https://kubernetes.io/docs/reference/access-authn-authz/authorization/#determine-the-request-verb) _から取得されました_) | HTTP 動詞 | リクエスト動詞 | | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | POST | create | | GET, HEAD | get（個々のリソース用）、list（コレクション用、オブジェクトの完全な内容を含む）、watch（個々のリソースまたはリソースのコレクションを監視するため） | | PUT | update | | PATCH | patch | | DELETE | delete（個々のリソース用）、deletecollection（コレクション用） | Kubernetes は、特定の動詞を使用して追加の権限の認可を確認することがあります。例えば： - [PodSecurityPolicy](https://kubernetes.io/docs/concepts/policy/pod-security-policy/) - `policy` API グループの `podsecuritypolicies` リソースに対する `use` 動詞。 - [RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) - `rbac.authorization.k8s.io` API グループの `roles` および `clusterroles` リソースに対する `bind` および `escalate` 動詞。 - [Authentication](https://kubernetes.io/docs/reference/access-authn-authz/authentication/) - コア API グループの `users`、`groups`、および `serviceaccounts` に対する `impersonate` 動詞、及び `authentication.k8s.io` API グループの `userextras`。 > [!WARNING] > **各リソースがサポートするすべての動詞を見つける** には、`kubectl api-resources --sort-by name -o wide` を実行してください。 ### 例 ```yaml: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"] ``` ```yaml: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** [**ドキュメントから:**](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding) **ロールバインディングは、ロールで定義された権限をユーザーまたはユーザーのセットに付与します**。これは、対象（ユーザー、グループ、またはサービスアカウント）のリストと、付与されるロールへの参照を保持します。**RoleBinding** は特定の **namespace** 内で権限を付与しますが、**ClusterRoleBinding** はそのアクセスを **クラスター全体** に付与します。 ```yaml:RoleBinding 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 ``` ```yaml: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の列挙** ```bash # Get current privileges kubectl auth can-i --list # use `--as=system:serviceaccount::` 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の悪用 {{#ref}} abusing-roles-clusterroles-in-kubernetes/ {{#endref}} {{#include ../../banners/hacktricks-training.md}}