RBAC, is a security feature in Kubernetes that provides fine-grained control over access to resources within a Kubernetes cluster. It allows you to define roles, role bindings to manage user and service account permissions, enabling secure access to Kubernetes resources based on user roles and responsibilities.
No RBAC
Typically for your local clusters created by either kind or minikube you ended up with admin context. Moreover, some guys call it God mode which allows you to perform anything on the cluster.
In production-ready clusters admin access is restricted to few admins because with great power comes great responsibility.
Role
Everything starts with defining the role
--- kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: namespace: default name: log-reader rules: - apiGroups: [""] resources: ["pods", "pods/log"] verbs: ["get", "list"]
This Role, named "log-reader," grants permissions to users or service accounts within the "default" namespace to get information about pods and read logs from pods using the "get" and "list" verbs. It does not allow other actions such as creating, updating, or deleting pods.
Role Binding
Defined role we have to connect somehow with user. To do that RoleBinding is required.
--- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: log-reader-binding namespace: default roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: log-reader subjects: - apiGroup: rbac.authorization.k8s.io kind: User name: user1
This RoleBinding, named "log-reader-binding," links the user "user1" with the "log-reader" Role within the "default" namespace. As a result, "user1" will inherit the permissions granted by the "log-reader" Role, which includes the ability to get information about pods and read logs from pods in the "default" namespace. Other actions beyond those defined in the "log-reader" Role will not be permitted for "user1" in this namespace.
But where can I defined the user?
Certificate
To be honest there is no such resource like user in kubernetes ecosystem. However, TLS certificate are being used to connect to cluster and such certificate can have details which links it to the username. And now is a time to do that.
Firstly, the key need to be generated.
openssl genrsa -out user1.key 2048
Next create CSR with information about user.
openssl req -new -key user1.key -out user1.csr -subj "/CN=user1/O=devs"
Sign CSR using CA of the kubernetes cluster. How to get it? This is a stuff for another post
openssl x509 -req -in user1.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out user1.crt -days 180
Context
Context, these few fields in ~/.kube/config is the last thing to created before checking the access role
kubectl config set-credentials user1 --client-certificate=user1.crt --client-key=user1.key kubectl config set-context <NAME_OF_CONTEXT> --cluster=kind-kind --namespace=default --user=user1
Usage
In order to test the role permission, new context needs to be assign. I prefer kubectx to that kind of stuff.
kubectx <NAME_OF_CONTEXT> kubecrl logs <POD_NAME>
And time for a homework: What do you get running below command?
kubectl get deploy
Summary
RBAC provides fine-grained control over access to resources within a Kubernetes cluster. It allows you to define roles, role bindings to manage user and service account permissions, enabling secure access to Kubernetes resources.
