Kubernetes RBAC is a vast subject and it continuously evolves as I pen down this article.
In this article let us see some basics of Kubernetes RBAC and move to our objective How to restrict the access of users or groups to a specific namespace.
Kubernetes RBAC is powered by four key resources as
- Role (or) Cluster Role - Define what can be done
- Role Binding (or) Cluster Role binding. - Define who can do it
While the Role and Role binding are bound to a single namespace. Cluster Role and Cluster Role Binding are for the entire cluster. ( that's why there is a
cluster as a prefix)
The following image is self-explanatory and depict the role and role binding clearly.
The same image is applicable for Cluster and Cluster Role binding too. except that it is for cluster scope.
But our objective for this article is to talk about how to limit a user or group to a specific namespace.
when we say namespace, we should think about roles and role binding as they are limited to namespace only.
In case it should be for multiple namespaces or any other cluster resources. it should cluster role and cluster role binding.
So now we are going to do the following things to create a user with limited permission to a specific namespace.
- role - to define what the user can do on the namespace
- role binding - to bind the user to the role
- group (auto-created - if not already exist)
- update the user with a group name ( I am using EKS so I have to update
the preceding diagram explains what we are going to do and the code changes necessary.
The source code of these YAML files is given below.
YAML files for creating a role, role binding and a group
here is the configuration YAML file for creating the role with full access to the namespace.
we are also defining the namespace as
app1within the configuration file
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: NameSpaceApp1-FullAccess namespace: app1 rules: - apiGroups: - '*' resources: - '*' verbs: - get - list - watch - create - update - patch - delete
Here is the configuration file for the role binding
apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: app1-user-access namespace: app1 roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: NameSpaceApp1-FullAccess subjects: - apiGroup: rbac.authorization.k8s.io kind: Group name: app1-ns-group
You can see that role binding takes care of connecting the role to a subject.
- group - you can see we are defining the group as a subject
- role - name of the role to bind to the subject
Now the role binding has mapped the group to the user.
In Kubernetes, user and group information are not stored anywhere, it all comes from the authentication plugin. In the case of EKS, AWS IAM is the authentication plugin
the AWS IAM authentication plugin uses a configmap named
aws-auth where you have to add the user with their IAM arn and their username also the groups.
Now you can map the group name `app1-ns-group` we have used in our role-binding definition
Here is a glimpse of my aws-auth file
- userarn: arn:aws:iam::***********:user/sarav username: sarav groups: - system:masters - userarn: arn:aws:iam::***********:user/readonlyuser username: readonlyuser groups: - app1-ns-group
As I have mentioned earlier, neither the user nor the group are managed or stored in Kubernetes.
It means you cannot list them with
kubectl get user or
kubectl get group as Kubernetes would not be aware of it
to read more about how IAM works with Kubernetes w EKS refer to the following link https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html
How to validate the role and user binding
Now we have created or updated different objects/resources in Kubernetes. how to view their binding to make sure they are bound properly
You can use an opensource project called rbac-lookup
once you have installed rbac-lookup tool, you can simply list your subject (group/user) to know their binding
# rbac-lookup app1-ns-group -o wide
Learn further about Kubernetes RBAC
there are various tools and articles available to understand and master Kubernetes RBAC most of them are collected in a single website
follow this link rbac.dev and learn more about Kubernetes RBAC and the tools available
Signup for Exclusive "Subscriber-only" Content