kubernetes
RBAC

KubernetesのRBACについて

RBACとは

RBAC(Role-based access control)とは、役割ベースのアクセス制御機能。

RBACリソースは4つのリソースがある。RoleリソースとClusterRoleリソースとRoleBindingリソースとClusterRoleBindingリソース。

  • RoleClusterRoleは、どのリソースにどんな操作を許可するかを定義するためのリソース
  • RoleBindingClusterRoleBindingはどのRole/ClusterRoleをどのユーザ/グループ/ServiceAcctountに紐付けるかを定義するためのリソース。

リソース、操作とは

  • リソースとは
    • kubernetesのリソースを指す。例えばpod, depoyment, service, secret etc..
  • 操作とは
    • get, create, update, delete, list, watch, deletecollection などがある。

RoleとClusterRoleの違い、そしてRoleBindingとClusterRoleBindingの違い

RoleとClusterRoleの違い、そしてRoleBindingとClusterRoleBindingの違いは、Role/RoleBindingは特定のnamespaceに属するが、ClusterRole/ClusterRoleBindingはnamespaceに属さない(cluster-lebel resource)

namespaceに属する namespaceに属さない
Role
Cluster Role
RoleBinding
ClusterRoleBinding

以下はServiceリソースをget, listできる権限を表したRole

service-reader-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: hoge-ns
  name: service-reader-role
rules:
- apiGroups: [""]
  verbs: ["get", "list"]
  resources: ["services"]

Roleを作成

$ kubectl create -f service-reader-role.yaml

Role: service-reader-roleをServiceAccount: my-app-saに紐付けるためのRoleBinding

service-reader-rolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: service-reader-rolebinding
  namespace: hoge-ns
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: service-reader-role
subjects:
- kind: ServiceAccount
  name: default
  namespace: hoge-ns

RoleBindingを作成

$ kubectl create -f service-reader-rolebinding.yaml

ServiceAccountについて

  • どんなアプリケーションなのか識別するためのもの
  • pod作成時にServiceAccountに紐付けられる
  • ServiceAccountに対してRoleを紐付ける(bindする)ことができる
  • ServiceAccountはどのnamespaceに属するかの情報、及びAPIへ接続するための認証情報をもっている。namespaceca.crttokenの3つ。
  • namespaceを1つ作るとdefaultという名前のServiceAccountが自動的に作成される。
  • Kubernetesクラスタを作るとdefaultというnamespaceが自動で作成されるが、そのnamespaceに属するdefaultという名前のServiceAccountも自動で作成される。podを作成すると紐付けるServiceAccountに指定がなければdefaultのServiceAccountが紐付けられる。
  • defaultのServiceAccount以外にも新しくServiceAccountを手動で作成することができ、podに紐付けることができる
    • たとえばWebアプリケーション用のServiceAccountを作成し、そのWebアプリケーション用Podに作成したServiceAccountを紐付け、そのServiceAccountにKubernetesリソースの参照のみを許可することができる。

その他Tips

  • どんな時にRole/RoleBindingとClusterRole/ClusterRoleBindingを使えばいいかは以下を参考にすればよい
アクセス制限対象 Role種類 Binding種類
Cluster-level resources (Nodes, PersistentVolumes, ...) ClusterRole ClusterRoleBinding
Non-resource URLs (/api, /healthz, ...) ClusterRole ClusterRoleBinding
いくつかのnamespace、もしくは全てのnamaespaceに存在するNamespaced resources ClusterRole ClusterRoleBinding
特定のnamaspaceに存在するNamespaced resources。(共通のRoleを使いたい場合) ClusterRole RoleBinding
特定のnamaspaceに存在するNamespaced resources。(namespaceごとにRoleを定義する場合) Role RoleBinding
  • adminという名前のClusterRoleは そのnamespace内のどんなリソースの操作もできる。ただしResourceQuotasとそのnamespaceリソースを除いて。

  • ClusterRolesのedit と admin の違いは、そのnamespaceの Roles と RoleBindingsを参照/変更できるかどうか。adminはできる。editはできない。

  • kubectl auth can-iを使うと権限が設定されているか、操作が許可されているかを確認することができる。
    例えばhoge-nsというnamespaceにあるdefaultという名前のservice accountがserviceのcreateすることを許可されているかどうかは以下のコマンドで確認できる。
    $ kubectl auth can-i create services --as=system:serviceaccount:hoge-ns:default -n=hoge-ns

  • namespace: kube-systemのRole一覧
    $ kubectl get roles -n=kube-system

  • namespace: kube-systemのClusterRole一覧
    $ kubectl get clusterroles -n=kube-system

  • もしminikube上でRBACを有効にしたい場合は、minikube起動時に、--extra-config=apiserver.Authorization.Mode=RBACを指定する必要がある。

参考: