In this lesson, you will learn how to enforce the principle of least privilege by restricting user access to specific namespaces using Role-Based Access Control (RBAC).
Now that you know how to use Namespaces to logically isolate your applications, the next challenge is ensuring that users only have the permissions they absolutely need. If you have two different teams—Team A and Team B—working in separate namespaces, you don’t want a member of Team A accidentally deleting a production deployment in Team B’s namespace.
To prevent this, Kubernetes uses Roles and RoleBindings.
Roles: Defining Permissions
A Role is a set of rules that defines what actions can be performed (e.g., "get," "list," or "delete") on which resources (e.g., "pods," "services"). Crucially, a Role is namespaced—it only exists within the namespace where you create it.
RoleBindings: Mapping Users to Roles
A RoleBinding acts as the bridge. It connects a user (or group) to a specific Role within a specific namespace. By creating a RoleBinding in the team-a namespace, you grant that user access to team-a resources while leaving team-b completely invisible or inaccessible to them.
Here is a simple example of a Role that allows a user to only list pods:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: team-a
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list"]
By assigning this via a RoleBinding, the user is locked strictly within the team-a boundary. Even if they have credentials for the cluster, Kubernetes will reject any attempt they make to interact with resources in team-b. This granular control ensures that your multi-tenant environment remains secure and that team members cannot impact infrastructure outside their assigned scope.
Key Takeaway: Role-Based Access Control uses RoleBindings to enforce the principle of least privilege, ensuring users can only interact with resources within the specific namespaces they are authorized to manage.