In kubernetes, we can use Role-Based Access Control (RBAC) to restrict access to Kubernetes API resources within a Kubernetes cluster using rbac.authorization.k8s.io API. This API states four types of Kubernetes objects: Role, RoleBinding, ClusterRole, and ClusterRoleBinding.
Defines a set of allow permissions consisting of rules that indicate which actions are allowed to perform on certain Kubernetes API objects like Pod, Deployment, Secret, DaemonSet or a specific object identified by its name (e.g: payroll app in finance namespace).
Role bindings are used to grant permissions defined in Role or ClusterRole to Kubernetes subjects. Kubernetes subject can be a user, ServiceAccount or a group.
Suppose the dev-user in the default namespace needs to be able to access Pods in the dev namespace but not in the prod namespace. Here’s how you might set up the necessary roles and bindings.
> Create pod-reader Role with necessary permissions to get Pods in dev namespace.
kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods --namespace dev
role.rbac.authorization.k8s.io/pod-reader created
> Create pod-reader-binding RoleBinding for pod-reader Role and bind to dev-user.
kubectl create rolebinding pod-reader-binding --role=pod-reader --serviceaccount=default:dev-user --namespace dev
rolebinding.rbac.authorization.k8s.io/pod-reader-binding created
> Can dev-user get pods in the dev namespace?
kubectl auth can-i get pods --namespace dev --as=system:serviceaccount:default:dev-user
yes
> Can dev-user get pods in the prod namespace?
kubectl auth can-i get pods --namespace prod --as=system:serviceaccount:default:dev-user
no
As we grant permission for dev-user to get Pods only in the dev namespace,it can only get Pods in dev namespace.
Kubernetes Role-Based Access Control allows users to keep track of who has access on what resource to perform which actions. This improves the visibility of authorization and accountability while reducing risk and maintaining the protection of sensitive data.