👨💻
kubernetes RBACについて
RBAC(Role Based Access Control)
RBACはクラスタでどういった操作をできるかRoleで設定し、ユーザーにRoleをRoleBindingで紐づけることで権限を与える。
RBACには4種類のリソースがある
- Role
- RoleBinding
- ClusterRole
- ClusterRoleBinding
Role.RoleBindingとClusterRole.ClusterRoleBinding
- RoleとRoleBindingはnamespaceレベルで設定ができるリソース
- ClusterRoleとClusterRoleBindingはクラスタレベルで設定ができるリソース
下記CLIでNAMESPACEDがtrueかfalseになっているかでnamespaceレベルかクラスタレベルかが他のリソースに関してもわかる。
true=namespceレベル
false=クラスタレベル
$ kubectl api-resources | grep role
NAME SHORTNAMES APIVERSION NAMESPACED KIND
clusterrolebindings rbac.authorization.k8s.io/v1 false ClusterRoleBinding
clusterroles rbac.authorization.k8s.io/v1 false ClusterRole
rolebindings rbac.authorization.k8s.io/v1 true RoleBinding
roles rbac.authorization.k8s.io/v1 true Role
Role
manifestでRoleの作成方法を記載していく。
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: zenn
namespace: default
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list"]
- apiVersionにはRole、RoleBinding、ClusterRole、ClusterRoleBinding全てrbac.authorization.k8s.io/v1を指定。
- kindは作成するリソースを指定。今回はRoleなのでRoleを記載。
- metadataはnameでRoleの名前を記載。
- Roleはnamespaceレベルのリソースなのでmetadata.namespaceで任意のnamespaceを設定。今回はdefaultを設定。
- apiGroupでは今回設定するresourcesのapiVersionを記載する。
- 今回指定してるのpodsのapiVersionはv1なので省略が可能。
- resourcesは操作可能対象のリソースを設定。
※ podsをpodにしたらエラーなるのでお気をつけください。 - verbsはresourcesで指定したリソースの操作可能な内容。
- 上記manifestではpodのget、listの操作が可能。
Roleの複数記載する場合のmanifest
- 上記manifestではpodのget、listの操作が可能。
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: zenn
namespace: default
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list"]
- apiGroups: ["apps"]
resources: ["deployments"]
verbs: ["get", "list"]
- rulesを1つのRoleに複数記載する場合はrule配下に付け足すだけで作成可能。
- 上記manifestではdeploymentsのリソースを指定してるので、apiGroupsでdeploymentsのapiversionを記載する。
- deploymentsのapiversionはapps/v1なので/v1を省略して、appsのみ記載。
CLIでapi-resourcesを確認した時のNAMEがresourcesの値を記載し、APIVERSIONの値をapiGroupsに記載する。 - horizontalpodautoscalersの場合はautoscaling/v2を記載。
- cronjobsの場合はbatchを記載。
- deploymentsのapiversionはapps/v1なので/v1を省略して、appsのみ記載。
$ kubectl api-resources
NAME SHORTNAMES APIVERSION NAMESPACED KIND
pods po v1 true Pod
deployments deploy apps/v1 true Deployment
horizontalpodautoscalers hpa autoscaling/v2 true HorizontalPodAutoscaler
cronjobs cj batch/v1 true CronJob
RoleBinding
manifestでRoleBindingの作成方法を記載していく。
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: zenn
namespace: default
subjects:
- kind: User
name: zenn
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: zenn
apiGroup: rbac.authorization.k8s.io
- apiVersionとkindとmetadataの説明はここでは割愛する。
- subjectについて
- subject内で記載する内容は、Roleを紐づける対象を記載する。
- kindはUser又はGroupを指定。今回はUserを指定。
- nameはUser名又はGroup名を記載する。
- apiGroupはrbac.authorization.k8s.ioを記載する。
- roleRefについて
- roleRef内で記載する内容は、ユーザー又はGroupに紐づけるRoleの内容を記載していく。
- kindはRole又はClusterRoleを指定。紐づけるRoleがRoleかClusterRoleなのかで値を記載する。
- nameはRoleの名前を記載する。
- apiGroupはrbac.authorization.k8s.ioを記載する。
RoleとRoleBindingをまとめて作成する方法
1つのmanifestでRoleとRoleBindingをまとめて記載する場合はmanifestの中で[---]を記載してあげれば作成可能。
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: zenn
namespace: default
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: zenn
namespace: default
subjects:
- kind: User
name: zenn
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: zenn
apiGroup: rbac.authorization.k8s.io
作成したmanifestをapplyしたら作成完了。
$ kubectl apply -f zenn.yaml
clusterrole.rbac.authorization.k8s.io/zenn created
clusterrolebinding.rbac.authorization.k8s.io/zenn created
Discussion