Detections
Analytics

4.1.2 Ensure access to Secrets is minimized and granted only where required

Information

Kubernetes Secrets can contain sensitive application credentials, configuration values, certificates, and legacy service account tokens. Access to these secrets should be restricted to the smallest practical set of users, groups, service accounts, and workloads to reduce the risk of credential exposure, privilege escalation, and unauthorized access to cluster or external resources. GKE RBAC supports fine grained permissions over Kubernetes resources, and Google's RBAC guidance emphasizes least privilege for users and workloads.

Inappropriate access to Secrets stored in the cluster can allow an attacker to retrieve credentials used by applications, automation, or workloads, and then use those credentials to access Kubernetes resources or external systems. RBAC permissions for Secrets should be granted only through explicit Roles or ClusterRoles that define the required API group, resource, and verbs, such as get, list, watch, create, update, or delete . Wildcards should be avoided because they can unintentionally grant broader Secret access than intended.

Where possible, workloads should use dedicated Kubernetes service accounts and least privilege bindings rather than shared or default service accounts. For access to Google Cloud Secret Manager or other Google Cloud APIs, Workload Identity Federation for GKE is preferred over storing long lived service account keys as Kubernetes Secrets, because it reduces reliance on static credentials stored inside the cluster.

NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance.

Solution

Remediate Secret access by replacing broad or unnecessary RBAC permissions with narrowly defined access that supports only the required workload, user, or operational function. The remediation process should focus on reducing get, list, and watch permissions on the core API secrets resource, especially where access is inherited through broad roles, wildcard rules, shared service accounts, or default service accounts. Changes should be validated before removal to avoid disrupting applications, controllers, operators, or required platform services.

 -

Remove unnecessary Secret access by updating or replacing RBAC roles that grant get, list, or watch on secrets, especially where the access is inherited through wildcard resources or wildcard verbs

 -

Replace broad Secret permissions with least privilege Roles or ClusterRoles that grant only the required API group, resource, and verb. Avoid list and watch when a subject only needs to read a specific Secret

 -

Bind Secret access only to approved users, groups, or dedicated Kubernetes service accounts. Avoid binding Secret access to the default service account because Pods that do not explicitly specify a service account can inherit that access

 -

Move sensitive external credentials out of Kubernetes Secrets and use Secret Manager with Workload Identity Federation for GKE

 -

Validate application, controller, operator, and platform workflows before removing access, and avoid modifying required system: RBAC resources because they support normal cluster functionality

Impact:

Do not to remove Secret access from GKE managed components, system workloads, controllers, operators, or application service accounts that require it for normal operation. Before making changes validate access and replace broad Secret permissions with least privilege RBAC, and avoid modifying required system: RBAC roles or bindings.

See Also

https://workbench.cisecurity.org/benchmarks/24956

Item Details

Category: CONFIGURATION MANAGEMENT, SYSTEM AND SERVICES ACQUISITION

References: 800-53|CM-2, 800-53|CM-6, 800-53|CM-7, 800-53|CM-7(1), 800-53|CM-9, 800-53|SA-3, 800-53|SA-8, 800-53|SA-10, CSCv7|5.2

Plugin: GCP

Control ID: 8a12d38052f2548da8f80fe710fa8c3b129b31c55ba0e3e12260e670eb69a703