RBAC permits reading Secrets

Description

Any allowed read operation among get, list and watch on secrets can reveal Secret contents within its authorized scope. Secrets may contain tokens, passwords, certificates and API keys, so this access requires care.

Although these are read operations, they provide access to credentials. Grant them only to workloads and administrators who need them, at the minimum necessary scope.

Potential impact

• Users may read sensitive passwords, tokens and keys.
• A compromised account may use them to access other systems.
• A large number of Secret readers can make incident attribution more difficult.

Remediation

• Minimize get, list and watch access to secrets.
• Grant access only to workloads that need to read Secrets.
• Treat Secret permissions as a sensitive category during RBAC reviews.

Examples

RoleBindings are omitted. Bind roles only to the required identities and review Secret access granted by other roles.

Before

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: role-secret-reader
rules:
  - apiGroups: [""]
    resources: ["secrets"]
    verbs: ["get", "watch", "list"]

After

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: role-pod-and-logs-reader
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log"]
    verbs: ["get", "watch", "list"]

Explanation:

• Before: Secret read access exposes sensitive credentials directly.
• After: This role permits Pod and log reads instead of Secret reads. Logs can also contain secrets, so grant access only where needed.

References

• CWE-732
• Kubernetes RBAC reference