Kubernetes RBAC
What’s RBAC in Kubernetes ?
RBAC stands for Role-Based Access Control and to quote Kubernetes documentation:
Role-based access control (RBAC) is a method of regulating access to computer or network resources based on the roles of individual users within your organization
So RBAC in Kubernetes is the way that you allow/restrict access to resources within the cluster.
How that works ?
There is 3 elements involved in RBAC mechanism:
- Subjects: A user, group of users or service account
- Resources: Kubernetes object within the cluster (Pods, Deployments, Services, etc..)
- Verbs: Operations that can be executed to the resources (get, create, delete, etc..). In the end all of them are
CRUDoperations (Create, Read, Update, Delete)
Access to the API Server is controlled through authentication, authorization and admission control.
During the authorization phase, the api server will check if the user currently authenticated can perform the operation over the resource asked.
RBAC is only about adding permissions as they are denied by default.
Basically RBAC allows to specify which operation can be executed over a set of resources for a given user.
Why authorization matter ?
Well, obviously this is about security but also keep in mind to follow theses two principle:
Least privilege principle: The users and programs should only have the necessary privileges to complete their tasksSeparation of duty principle: Restricts users from getting more privileges than needed, with the aim of preventing fraud and errors
If you have secured your accesses, you have gone a good way in the security journey.
RBAC objects
RBAC objects are available since Kubernetes 1.8 and use the rbac.authorization.k8s.io API group.
The RBAC API declares four kinds of Kubernetes objects: Role, ClusterRole, RoleBinding and ClusterRoleBinding.
Role and ClusterRole
Role and ClusterRole objects are used to define a set of permissions. Permissions are represented as a list of rules combining apiGroups, resource types and verbs.
A Role is scoped to a namespace, so the set of permissions is applied to the given namespace.
By contrast, a ClusterRole is a cluster-wide resource, so the set of permissions is applied across the entire cluster.
Role example from the Kubernetes documentation that grant read access to pods in the default namespace.
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
resources: ["pods"]
verbs: ["get", "watch", "list"]
For a ClusterRole, you just need to use the kind ClusterRole and omit the namespace as they are not namespaced.
RoleBinding and ClusterRoleBinding
RoleBind and ClusterRoleBindind are the objects used to link the set of permissions defined in a Role or ClusterRole to subjects (user, group or service account).
Both holds a list of subjects and a reference to the role being granted.
RoleBinding is used to grant permission within a specific namespace whereas ClusterRoleBindings grant that access to all the namespaces.
A RoleBinding should refer to a Role in the same namespace but also refers to a ClusterRole and bind it to the namespace of the RoleBinding.
RoleBinding from the Kubernetes documentation that grand the pod-reader role defined previously to the user Jane in the default namespace.
apiVersion: rbac.authorization.k8s.io/v1
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:
kind: Role
name: pod-reader # this must match the name of the Role or ClusterRole you wish to bind to
apiGroup: rbac.authorization.k8s.io
For a ClusterRoleBinding, you need to use the kind ClusterRoleBinding, omit the namespace and use ClusterRole as reference.
The main idea behind RBAC is to provide access to resources for subjects who require it.
Always keep in mind the least privilege principle.