Namespace-Scoped RBAC with Roles and RoleBindings

1. The Core Components of Namespace-Scoped RBAC

Role-Based Access Control (RBAC) in Kubernetes revolves around four main API objects. For today's focus on namespace-scoped permissions, we'll concentrate on two:

• Role: An object that defines a set of permissions. It specifies what actions (verbs) are allowed on a set of API resources (like Pods, ConfigMaps, etc.). A Role exists within a specific namespace and can only grant access to resources within that same namespace.
• RoleBinding: An object that grants the permissions defined in a Role to a set of subjects (like a ServiceAccount, User, or Group). A RoleBinding also exists within a namespace and connects a subject to a Role in that same namespace.

The diagram below shows this relationship. A RoleBinding connects "Dave" to a pod-viewer Role within the "foo" namespace, granting him permission to see Pods only in that namespace. He has no access to the "bar" namespace.

To start, let's get a clear conceptual overview of authentication vs. authorization and how Roles fit in.

2. Defining a Role

A Role contains a list of rules. Each rule defines a set of permissions. Let's break down a manifest.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

• apiGroups: This specifies the API group of the resources. The core Kubernetes objects like Pods, Services, and ConfigMaps are in the core group, represented by "". Other resources like Deployments are in the apps group, and Jobs are in the batch group.
• resources: A list of resource types this rule applies to. You can get a full list with kubectl api-resources.
• verbs: The actions allowed on these resources. Common verbs include get, list, watch, create, update, delete.

Let's see a practical demonstration of creating a Role manifest.

3. Creating a RoleBinding

A Role on its own does nothing. You need a RoleBinding to grant the permissions in that Role to an identity. Following on from our last lesson, our identity will be a ServiceAccount.

Here is a RoleBinding manifest:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods-binding
  namespace: default
subjects:
- kind: ServiceAccount
  name: my-app-sa # The name of the ServiceAccount we're granting permissions to
  namespace: default # The namespace of the ServiceAccount
roleRef:
  kind: Role # Must be Role or ClusterRole
  name: pod-reader # The name of the Role we created above
  apiGroup: rbac.authorization.k8s.io

• subjects: A list of identities receiving the permissions. Here, we target the my-app-sa ServiceAccount in the default namespace.
• roleRef: A reference to the Role (or ClusterRole) whose permissions are being granted.

This RoleBinding gives the my-app-sa ServiceAccount the ability to get, watch, and list Pods within the default namespace.

A crucial point is that these permissions are strictly bound by the namespace.

4. Reusable Permissions: The RoleBinding + ClusterRole Pattern

As a platform engineer, you'll often need to grant the same set of permissions across many different namespaces. For example, you might want every application's ServiceAccount in every namespace to be able to read its own ConfigMap. Creating an identical Role in dozens of namespaces is inefficient and hard to maintain.

A more effective pattern is to:

1. Define the permissions once in a non-namespaced ClusterRole.
2. Use a namespaced RoleBinding in each namespace to grant those permissions to a local ServiceAccount.

Even though you are using a ClusterRole, the RoleBinding ensures the permissions are only active within the RoleBinding's namespace. This gives you a reusable template without granting cluster-wide access.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: config-reader
rules:
- apiGroups: [""]
  resources: ["configmaps", "secrets"]
  verbs: ["get", "list"]

Conclusion

You have now learned how to implement the principle of least privilege for your in-cluster applications. By combining ServiceAccounts, Roles, and RoleBindings, you can grant precise, namespace-scoped permissions, which is a fundamental skill for any platform engineer working with Kubernetes.

Key Takeaways:

• A Role is a namespaced object that defines permissions (verbs on resources).
• A RoleBinding is also namespaced and connects subjects (like a ServiceAccount) to a Role.
• The permissions granted by a RoleBinding are always limited to the namespace in which the RoleBinding is created.
• For efficiency, you can create a reusable ClusterRole and bind it within a specific namespace using a RoleBinding to grant namespace-scoped access.

Next Up:
We've controlled what a Pod can do to the Kubernetes API. But what about what the processes inside the Pod's container can do to the underlying host node? In the next lesson, you will learn to configure basic security contexts for Pods and containers, adding another critical layer of security to your deployments.