Role-based access control(RBAC) is a way of regulating access to computer/network resources.
RBAC authorization uses the rbac.autherization.k8s.io API group to drive authorization decisions.
To enable RBAC, start the api-server with the --authorization-mode flag set to comma separated list that includes RBAC as below,
- kube-apiserver --authorization-mode=Example,RBAC--other-options --more-options
RBAC Resources:
- Role
- ClusterRole
- RoleBinding
- ClusterRoleBinding
Role/ClusterRole:
- A ClusterRole/Role defines a set of permissions and where is available, in the whole cluster or just in the namespace.
- Role always sets permissions within a specific namespace.
- When we create a Role we have to mention the namespace where it belongs.
- ClusterRole is a non-namespaced resource.
- To define a role with in namespace, use Role; To define role cluster-wide, use ClusterRole
Role Example:
ClusterRole Example:
ClusterRoleBinding/RoleBInding:
- A ClusterRoleBinding/RoleBinding connects a set of permissions with an account and defines where it applied, in the whole cluster or just a single namespace.
- Role binding holds a list of subjects (users, groups, and service accounts) and a reference to the role being granted
- RoleBinding grants permissions within the namespace whereas ClusterRoleBinding grants access cluster-wide.
- A RoleBinding may reference any role in the same namespace. Alternatively, a RoleBinding can reference ClusterRole and bind that ClusterRole to the namespace of the RoleBinding.
RoleBinding Example:
ClusterRoleBinding Example:
4 different RBAC combinations and 3 valid ones:
- Role + RoleBinding (available in single Namespace, applied in single Namespace)
- ClusterRole + ClusterRoleBinding (available cluster-wide, applied cluster-wide)
- ClusterRole + RoleBinding (available cluster-wide, applied in single Namespace)
- Role + ClusterRoleBinding (NOT POSSIBLE: available in single Namespace, applied cluster-wide)