Use context: kubectl config use-context k8s-c1-H
Create a new ServiceAccount processor
in Namespace project-hamster
. Create a Role and RoleBinding, both named processor
as well. These should allow the new SA to only create Secrets and ConfigMaps in that Namespace.
Understanding and Setting Up Kubernetes RBAC with Roles and RoleBindings
In Kubernetes, Role-Based Access Control (RBAC) is a method of regulating access to resources based on the roles of individual users or service accounts. In this guide, we’ll walk through the key concepts of RBAC and demonstrate how to create and bind roles to service accounts.
Understanding RBAC Resources
RBAC in Kubernetes is built around four key resources:
- Role: Defines a set of permissions that are available within a specific Namespace.
- ClusterRole: Defines a set of permissions that are available cluster-wide.
- RoleBinding: Binds a Role to a user or service account within a specific Namespace.
- ClusterRoleBinding: Binds a ClusterRole to a user or service account cluster-wide.
There are three valid RBAC combinations:
- Role + RoleBinding: Permissions are available and applied within a single Namespace.
- ClusterRole + ClusterRoleBinding: Permissions are available and applied cluster-wide.
- ClusterRole + RoleBinding: Permissions are available cluster-wide but applied within a single Namespace.
Note that the combination of Role + ClusterRoleBinding is not possible, as Roles are Namespace-scoped and cannot be applied cluster-wide.
Step 1: Create the ServiceAccount
To start, we’ll create a ServiceAccount named processor
in the project-hamster
Namespace:
1 2 3 |
kubectl -n project-hamster create sa processor |
This command will create a ServiceAccount that we will later bind to a Role.
Step 2: Create the Role
Next, we create a Role named processor
in the project-hamster
Namespace with permissions to create secrets and configmaps:
1 2 3 4 5 6 7 8 |
kubectl -n project-hamster create role processor \ --verb=create \ --resource=secret \ --resource=configmap |
The command above generates a Role with the following YAML configuration:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: processor namespace: project-hamster rules: - apiGroups: - "" resources: - secrets - configmaps verbs: - create |
Step 3: Bind the Role to the ServiceAccount
Now, we’ll bind the processor
Role to the processor
ServiceAccount using a RoleBinding:
1 2 3 4 5 6 7 |
kubectl -n project-hamster create rolebinding processor \ --role processor \ --serviceaccount project-hamster:processor |
This creates a RoleBinding with the following configuration:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: processor namespace: project-hamster roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: processor subjects: - kind: ServiceAccount name: processor namespace: project-hamster |
Step 4: Test the RBAC Setup
To test our RBAC setup, we can use the kubectl auth can-i
command. This command checks if a specific action is allowed for a user or service account. Let’s run a few checks for the processor
ServiceAccount:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
kubectl -n project-hamster auth can-i create secret \ --as system:serviceaccount:project-hamster:processor # Output: yes kubectl -n project-hamster auth can-i create configmap \ --as system:serviceaccount:project-hamster:processor # Output: yes kubectl -n project-hamster auth can-i create pod \ --as system:serviceaccount:project-hamster:processor # Output: no kubectl -n project-hamster auth can-i delete secret \ --as system:serviceaccount:project-hamster:processor # Output: no kubectl -n project-hamster auth can-i get configmap \ --as system:serviceaccount:project-hamster:processor # Output: no |
As expected, the processor
ServiceAccount can create secrets and configmaps but cannot create pods, delete secrets, or get configmaps because the Role we defined only allows the creation of secrets and configmaps.
Conclusion
In this guide, we’ve successfully created an RBAC setup in Kubernetes. We’ve defined a Role with specific permissions, bound it to a ServiceAccount, and verified the permissions using the kubectl auth can-i
command. Understanding and configuring RBAC is crucial for maintaining secure and well-organized Kubernetes environments.