What is RBAC in Kubernetes?
In this post I will show you how you can use RBAC in kubernetes.
What is RBAC?
RBAC stands for Role-Based Access Control. It is an approach that is used for restricting access to resources dor users based on roles. Kubernetes use RBAC for authorization, for example to giving access to users and groups to certain Kubernetes resources. It uses roles to adding or removing permissions. For Kubernetes RBAC is the way to restrict who can access what whitin the cluster.
Why RBAC?
A kubernetes cluster is beeing used by multiple users. This users can be different types od users, for example developers, testers, application administrators and cluster administrators. This groups of userc need different permissions to do there jobs. That is where the notion of RBAC or Role-Based Access Control comes into play. You can create different roles for this groups and associate the roles with the users or groups.
Role
A role defines what you can do to a specific kubernetes resource. So the role is containing two main part, one is representing what permissions you have and another represents the kubernetes resource in the kubernetes api structure.
Here is a simple example for Roles, where the user has permission to just get and list the pods:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: elasticsearch
rules:
- apiGroups:
- ""
resources:
- pods
verb:
- get
- list
ClusterRole
Roles are used to assigning resources for a namespace, but if you need to assign resources on a cluster level, you need to use ClusterRole. It is similar to Roles, but it can grant permissions that are cluster-scoped such as giving resource permissions across all namespaces in the cluster.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
annotations:
rbac.authorization.kubernetes.io/autoupdate: "true"
creationTimestamp: null
labels:
kubernetes.io/bootstrapping: rbac-defaults
name: cluster-admin
rules:
- apiGroups:
- "*"
resources:
- "*"
verbs:
- "*"
RoleBinding
RoleBinding is used for granting permission to a Subject in a Kubernetes cluster. Subjects can be users, service accounts or groups trying to access Kubernetes API.
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: elasticsearch
namespace: default
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: elasticsearch
subjects:
- kind: User
name: John
namespace: default
Below is an example of RoleBinding where roleRef
is being used to bind user John
with the previously created elasticsearch
role in the default
namespace.
ClusterRoleBinding
ClusterRoleBinding is used to grant permission to a subject on a cluster-level in all the namespaces.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: cluster-admin
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: Group
name: masters
What can I bind with what?
Usually you use RoleBinding to bind Role and ClusterRoleBinding to bind ClusterRole, but you can use RoleBinding to bind ClusterRole to a specific namespace. It is a best practice to create global ClusterRoles for specific tasks and bind them to namespaces with RoleBinding.
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: developer-binding-to-default
namespace: default
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: template-namespaced-resources---developer
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: Group
name: developer-team
namespace: default
Aggregated ClusterRoles
You can aggregate several ClusterRoles into one combined ClusterRole. If you create a ClusterRole with aggregationRule the controller in the Kubernetes cluster will search fo the ClusterRoles with the matching labels and combines ther roles into the Aggregated ClusterRole.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: monitoring
aggregationRule:
clusterRoleSelectors:
- matchLabels:
rbac.example.com/aggregate-to-monitoring: "true"
rules: [] # The control plane automatically fills in the rules
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: monitoring-endpoints
labels:
rbac.example.com/aggregate-to-monitoring: "true"
# When you create the "monitoring-endpoints" ClusterRole,
# the rules below will be added to the "monitoring" ClusterRole.
rules:
- apiGroups: [""]
resources: ["services", "endpointslices", "pods"]
verbs: ["get", "list", "watch"]
The default ClusterRoles are using ClusterRole aggregation. This lets you include rules for custom resources defined by CustomResourceDefinition to extend the default roles.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: aggregate-cron-tabs-edit
labels:
# Add these permissions to the "admin" and "edit" default roles.
rbac.authorization.k8s.io/aggregate-to-admin: "true"
rbac.authorization.k8s.io/aggregate-to-edit: "true"
rules:
- apiGroups: ["stable.example.com"]
resources: ["crontabs"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: aggregate-cron-tabs-view
labels:
# Add these permissions to the "view" default role.
rbac.authorization.k8s.io/aggregate-to-view: "true"
rules:
- apiGroups: ["stable.example.com"]
resources: ["crontabs"]
verbs: ["get", "list", "watch"]