Introduction

In Kubernetes RBAC, get and list are not interchangeable. get allows reading one named resource, while list allows reading a collection of resources. That difference matters operationally because a user who can get a pod by name may still be unable to run commands that enumerate pods across a namespace.

What get Means

get is the permission to read a single resource instance when you already know which object you want.

Example:

kubectl get pod my-pod -n app

For the API, this is roughly equivalent to:

GET /api/v1/namespaces/app/pods/my-pod

If RBAC grants get on pods, this request can succeed even if list is not allowed.

What list Means

list is the permission to retrieve a collection of resources.

Example:

kubectl get pods -n app

This maps more closely to:

GET /api/v1/namespaces/app/pods

That is a different RBAC verb because the caller is not requesting one known object. The caller is enumerating the set.

Why the Distinction Matters

The distinction is important for least privilege.

Granting get means:

• the subject can inspect a specific object if it knows the name.

Granting list means:

• the subject can discover which objects exist in the first place.

That discovery ability is often more sensitive than people assume. In multi-tenant or tightly controlled clusters, enumeration is a meaningful privilege.

Example Roles

Role with only get:

1apiVersion: rbac.authorization.k8s.io/v1
2kind: Role
3metadata:
4  name: pod-reader-single
5  namespace: app
6rules:
7  - apiGroups: [""]
8    resources: ["pods"]
9    verbs: ["get"]

Role with get and list:

1apiVersion: rbac.authorization.k8s.io/v1
2kind: Role
3metadata:
4  name: pod-reader-collection
5  namespace: app
6rules:
7  - apiGroups: [""]
8    resources: ["pods"]
9    verbs: ["get", "list"]

These two roles look similar, but they enable different CLI behavior.

kubectl Often Needs More Than You Think

Some commands that look simple can require list, not just get. For example:

• 'kubectl get pods needs list,'
• dashboards and UIs often need list,
• controllers and operators often need list plus watch.

Meanwhile:

• 'kubectl get pod my-pod needs get.'

That is why users sometimes report “I can fetch one pod but I cannot see all pods.” The RBAC policy is behaving exactly as defined.

watch Is Separate Too

Do not confuse list with watch. Many controllers need both:

• 'list to get the initial state,'
• 'watch to stream changes.'

A common production pattern is:

verbs: ["get", "list", "watch"]

But if your use case is narrower, grant only what the client actually needs.

How to Think About It Operationally

Use get when a subject should inspect a known resource.

Use list when a subject should enumerate resources in a scope.

Use both when the client needs both behaviors.

This is the same mental model many REST APIs use: reading one object and enumerating a collection are different permissions because they expose different amounts of information.

Testing the Difference

You can verify behavior with impersonation if you have the right administrative privileges:

kubectl auth can-i get pods --as alice -n app
kubectl auth can-i list pods --as alice -n app

This makes RBAC debugging much faster than guessing from failed commands alone.

Common Pitfalls

• Assuming get implies list because both are “read-only” permissions.
• Granting list casually without considering that it allows object discovery across a namespace or cluster scope.
• Forgetting that many tools and dashboards need list even when a human only thinks in terms of “read access.”
• Omitting watch for controllers that need ongoing updates after the initial list call.
• Debugging failed kubectl get pods commands without checking whether the real missing verb is list, not get.

Summary

• 'get reads one known resource, while list enumerates a resource collection.'
• A subject can have get without list, and the difference is meaningful in RBAC design.
• 'kubectl get pod my-pod and kubectl get pods map to different permissions.'
• 'list is often paired with watch for controllers and observability tools.'
• Use kubectl auth can-i to confirm exactly which verb is missing.