Introduction

If a pod needs to read pod information across the whole cluster, the service account needs cluster-scoped RBAC. The normal pattern is to create a ClusterRole with the required pod permissions and bind it to the service account with a ClusterRoleBinding.

Why a Role is not enough

A Kubernetes Role is namespaced. It can grant access only within one namespace. If your application needs to list or watch pods in all namespaces, a namespaced Role cannot express that permission.

This is exactly what ClusterRole is for. Kubernetes RBAC documentation uses ClusterRole when the access target is cluster-wide, such as reading pods across all namespaces.

The next question is which verbs you actually need:

• 'get if you only fetch a known pod by name'
• 'list if you need to enumerate pods'
• 'watch if you need streaming updates'

Most controllers and monitoring-style components need list and watch, not just get.

Create the service account

First create the service account in the namespace where the workload runs.

1apiVersion: v1
2kind: ServiceAccount
3metadata:
4  name: pod-reader
5  namespace: observability

A pod using serviceAccountName: pod-reader will authenticate to the API server as that identity.

Grant cluster-wide pod read access

Now create a ClusterRole and ClusterRoleBinding.

1apiVersion: rbac.authorization.k8s.io/v1
2kind: ClusterRole
3metadata:
4  name: pod-reader-cluster
5rules:
6  - apiGroups: [""]
7    resources: ["pods"]
8    verbs: ["get", "list", "watch"]
9---
10apiVersion: rbac.authorization.k8s.io/v1
11kind: ClusterRoleBinding
12metadata:
13  name: pod-reader-cluster-binding
14subjects:
15  - kind: ServiceAccount
16    name: pod-reader
17    namespace: observability
18roleRef:
19  apiGroup: rbac.authorization.k8s.io
20  kind: ClusterRole
21  name: pod-reader-cluster

Apply it:

kubectl apply -f pod-reader-rbac.yaml

That binding gives the pod-reader service account permission to read pods across the cluster, not just in observability.

Test the permission explicitly

Before debugging application code, verify the RBAC decision directly.

1kubectl auth can-i list pods \
2  --all-namespaces \
3  --as=system:serviceaccount:observability:pod-reader
4
5kubectl auth can-i watch pods \
6  --all-namespaces \
7  --as=system:serviceaccount:observability:pod-reader

If the answer is yes, the RBAC part is correct. If the answer is no, fix the binding before looking anywhere else.

Example pod using the service account

1apiVersion: v1
2kind: Pod
3metadata:
4  name: pod-auditor
5  namespace: observability
6spec:
7  serviceAccountName: pod-reader
8  containers:
9    - name: app
10      image: bitnami/kubectl:latest
11      command: ["sleep", "3600"]

Once that pod is running, you can exec into it and verify access:

kubectl exec -n observability pod-auditor -- kubectl get pods -A

In a real application, the client library inside the pod would use the mounted service account token automatically when it talks to the Kubernetes API.

Keep permissions as narrow as possible

Even when cluster-wide access is required, keep the rule minimal. If the application only needs pod metadata, do not grant write verbs such as create, update, patch, or delete.

Also think about whether it really needs all namespaces. If the true requirement is "several namespaces," separate RoleBinding objects in those namespaces may be safer than a cluster-wide grant.

A good rule is:

• start with read-only verbs
• grant only the resource types needed
• use ClusterRole only when the scope truly crosses namespaces

Common Pitfalls

A common mistake is creating a Role and expecting it to apply to all namespaces. It never does.

Another mistake is granting only get and then wondering why list operations fail. If your code calls list or watch APIs, the RBAC verbs must match.

A third mistake is binding the correct ClusterRole to the wrong namespace or service account name. In ClusterRoleBinding, the subject namespace still matters because the service account identity is namespaced.

Summary

• Use a ClusterRole when a service account must read pods across all namespaces.
• Bind that role with a ClusterRoleBinding to the specific service account.
• Include list and watch when the workload enumerates or observes pod changes.
• Verify the result with kubectl auth can-i before debugging the application.
• Keep the grant read-only and as narrow as the real requirement allows.