Introduction

If kubectl logs works but kubectl logs -f gives an authorization error, the problem is usually RBAC or identity context, not the -f flag by itself. Log access in Kubernetes is controlled through the pods/log subresource, and the right fix is to check what identity you are using and which verb-resource combination that identity is allowed to perform. Start with authorization checks before guessing at networking or client bugs.

What kubectl logs Actually Calls

kubectl logs does not read log files directly from the node. It talks to the Kubernetes API and requests the pods/log subresource for the target pod.

That means RBAC has to allow access to pods/log, not just to pods.

A common authorization check is:

kubectl auth can-i get pods/log -n my-namespace

If that says no, the error is already explained.

Depending on how you invoke logs, you may also need permission to inspect pods themselves, especially if the client first resolves pod names or selectors.

Confirm Which Identity Is Being Used

Before changing RBAC, verify the current context and user.

kubectl config current-context
kubectl config view --minify
kubectl auth whoami

In clusters that use cloud IAM, OIDC, or short-lived credentials, the identity seen by the cluster may differ from what you expect. If the token expired or the context changed, a command that used to work may suddenly fail.

The RBAC Rule That Usually Matters

To read logs, the typical permission is get on pods/log. If the user or service account also needs to discover pods, add read access on pods too.

A minimal Role example:

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

Bind it to a user, group, or service account:

1apiVersion: rbac.authorization.k8s.io/v1
2kind: RoleBinding
3metadata:
4  name: pod-log-reader-binding
5  namespace: my-namespace
6subjects:
7  - kind: User
8    name: [email protected]
9    apiGroup: rbac.authorization.k8s.io
10roleRef:
11  apiGroup: rbac.authorization.k8s.io
12  kind: Role
13  name: pod-log-reader

That is usually enough for namespaced log access.

Why -f Feels Different

The -f option follows the log stream, so the request stays open and behaves more like a live stream than a one-time fetch. Operationally that can expose issues that a plain one-shot log request does not make obvious:

• the wrong identity was used after a context refresh
• a proxy or gateway blocks long-lived connections
• the permission was never correct for the exact subresource request
• the client is resolving pod selection differently before following

That is why the same operator may say "logs work, but follow does not". The request path is similar, but the interaction pattern is less forgiving.

A Practical Debug Flow

A good order of operations is:

1. test the exact permission
2. verify the namespace
3. confirm the current identity
4. inspect relevant RoleBindings or ClusterRoleBindings
5. retry with a direct pod name instead of a selector

Useful commands:

1kubectl auth can-i get pods/log -n my-namespace
2kubectl get rolebinding,clusterrolebinding -A | grep alice
3kubectl logs my-pod -n my-namespace
4kubectl logs -f my-pod -n my-namespace

If direct pod logs work but selector-based forms do not, the missing permission may be on pod discovery rather than on the log subresource itself.

Service Account Cases

Inside a pod, the failing identity is often a service account rather than a human user. In that case, test authorization as that service account explicitly.

kubectl auth can-i get pods/log \
  --as=system:serviceaccount:my-namespace:my-service-account \
  -n my-namespace

This is much faster than editing roles blindly.

Common Pitfalls

A common mistake is granting access to pods but forgetting pods/log. Log access is a separate subresource in RBAC.

Another mistake is debugging the wrong kube context. If the identity changed, the permissions you think you have may not be the permissions the cluster sees.

People also often assume -f requires a completely different RBAC rule. Usually the key resource is still pods/log; the issue is often context or surrounding request behavior.

Finally, if an API proxy or gateway sits in front of the cluster, long-lived follow connections can expose proxy configuration problems that are not actually RBAC issues.

Summary

• 'kubectl logs -f usually depends on authorization to the pods/log subresource'
• Check permissions directly with kubectl auth can-i get pods/log
• Verify the active context and authenticated identity before editing RBAC
• Grant pods/log and, when needed, pod read permissions in the relevant namespace
• Test with a direct pod name to separate log access from pod discovery issues
• If RBAC looks correct, investigate proxies or gateways that may mishandle long-lived log streams