Anyone whose role includes get on the pods/log subresource can read container logs. Pod logs are a subresource, written as pods/log in an RBAC rule, so access must be granted on purpose. Scope it to namespaces, review it regularly, and assume logs may hold sensitive data.
How RBAC names logs
The Kubernetes RBAC documentation explains that some APIs involve a subresource, such as the logs for a pod. A request for logs is a GET on the path for the pod, ending in log. In a role, you write the resource and subresource with a slash. To let a subject read pods and their logs:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: pod-and-pod-logs-reader
rules:
- apiGroups: [""]
resources: ["pods", "pods/log"]
verbs: ["get", "list"]
The documentation also notes you can use resourceNames with the pods/exec subresource, which tells you exec is controlled the same way. Remember that logs and exec are separate permissions and exec is far more powerful than reading.
Why log access deserves review
Logs often contain request URLs, user identifiers and, when something goes wrong, tokens or connection strings. A role that reads logs across every namespace is effectively read access to whatever the applications print. See who should have access to production logs.
| Grant | Meaning | Typical holder |
|---|---|---|
| get on pods only | See pod objects, not logs | Dashboards, many developers |
| get on pods and pods/log | Read logs | Service owners, on call |
| create on pods/exec | Run commands in a container | Few people, break glass |
| Cluster wide log read | Read every namespace | Platform team, audited |
Steps to review log access
- List roles and cluster roles whose rules include pods/log, or a wildcard on resources. Wildcards grant logs too.
- List the bindings for each, and who or what is bound: users, groups, service accounts.
- Replace cluster wide grants with namespace roles where possible.
- Check service accounts. A CI job or a monitoring agent with cluster log read is a common over-grant.
- Move routine reading to a central log store with its own access controls, so people do not need direct cluster access. See should containers log to stdout or files.
- Turn on audit logging for the API server so reads of sensitive subresources are recorded. See Kubernetes audit logging policy starter.
- Repeat the review every quarter and after team changes.
Common mistakes
Granting a broad built-in role for convenience, then forgetting it. Binding a group that has grown. Treating logs as harmless because they are read only. Reading is how data leaves.
Quick check
Does read access to pods include logs?
No. Logs are the pods/log subresource and need their own entry in a rule.
Can I restrict exec by pod name?
The RBAC documentation says you can use resourceNames with the pods/exec subresource.
Safeguard scans container images and dependencies and keeps a record of policy decisions. Try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
