Kubernetes Role-Based Access Control(RBAC)

Reading time: 9 minutes

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など）。
• 名前空間リソース（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」は単一のリソースに対して使用されます。

ルールの動詞

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

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。

例

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"]

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

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