Course contentsShow
← Docker, Kubernetes & CI/CD
Lesson 506 of 8028. Security and ObservabilityFree lesson

Binding Roles to Users and Groups

Use RoleBindings to associate defined roles with specific user identities, granting them the intended access within a namespace.

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

  1. Namespace Scoping: RoleBindings are namespace-specific. If Alice needs to see pods in both development and testing, you must create a separate RoleBinding in each namespace.
  2. The Subject: While we often use User for human developers, you will frequently use ServiceAccount here as well, especially when letting your CI/CD pipelines interact with the cluster.
  3. Atomic Permissions: Because a RoleBinding links 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.