The concept of role-based access control is surrounded by Role, ClusterRole, RoleBinding, and ClusterRoleBinding. By role.yaml and rolebinding.yaml, as we showed previously, Linda should get read-only access to the configmaps resource. To apply authorization rules to [email protected], simply associate a ClusterRole and ClusteRoleBinding with it:
# cat oidc_clusterrole.yaml
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: oidc-admin-role
rules:
- apiGroups: ["*"]
resources: ["*"]
verbs: ["*"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: admin-binding
subjects:
- kind: User
name: [email protected]
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: oidc-admin-role
apiGroup: rbac.authorization.k8s.io
Then, we should be able to see if we can get nodes with the [email protected] user:
# kubectl [email protected] get nodes
NAME STATUS ROLES AGE VERSION minikube Ready <none> 6d v1.9.4
It works like a charm. We didn't encounter the Forbidden error anymore.
Before RBAC, Kubernetes provided Attribute-based access control (ABAC), which allows a cluster administrator to define a set of user authorization polices into a file with one JSON per line format. However, the file has to exist when launching the API server, which makes it unusable in the real world. After RBAC was introduced in Kubernetes 1.6, ABAC became legacy and was deprecated.