In this lesson, you will learn how to connect the permissions defined in your Kubernetes Role objects to actual human users or service accounts using RoleBinding.
The Bridge Between Intent and Identity
In our previous lesson, we defined a Role which acts as a "permission set"—it lists what actions (like get, list, or update) are allowed on specific resources. However, a Role by itself is just a set of rules hanging in the void; it does not grant access to anyone until it is attached to an identity.
This is where the RoleBinding comes in. It serves as the bridge that connects a Role to a Subject (a user, a group, or a service account) within a specific namespace.
Anatomy of a RoleBinding
A RoleBinding is a simple manifest that points to the role you want to grant and the user who should receive that power. Consider this example, where we grant a developer named "alice" read-only access to a namespace:
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-only-binding
namespace: development
subjects:
- kind: User
name: alice
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io
Key Considerations
- Namespace Scoping:
RoleBindingsare namespace-specific. If Alice needs to see pods in bothdevelopmentandtesting, you must create a separateRoleBindingin each namespace. - The Subject: While we often use
Userfor human developers, you will frequently useServiceAccounthere as well, especially when letting your CI/CD pipelines interact with the cluster. - Atomic Permissions: Because a
RoleBindinglinks a subject to a role, you can grant multiple roles to a single user by creating multiple bindings, or assign one role to an entire group of users (if your Kubernetes cluster is integrated with an external identity provider like OIDC).
By creating these links, you enforce the Principle of Least Privilege, ensuring that users only have the access necessary to perform their specific tasks without broad, cluster-wide permissions.
Key Takeaway: A RoleBinding acts as the crucial link that assigns a defined set of permissions to a specific user or service account within the boundaries of a namespace.