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 GKE Autopilot clusters still rely on Kubernetes RBAC to authorize access to Kubernetes API resources such as Secrets.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 ServiceAccounts and least privilege bindings rather than shared or default service accounts. For access to 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 gives workloads fine grained access to Google Cloud APIs without relying 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 ServiceAccounts. 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 where the workload needs access to Google Cloud secrets or APIs.
-
Validate application, controller, operator, and platform workflows before removing access, and avoid modifying required ystem: RBAC resources because they support normal cluster functionality.
Impact:
Removing Secret access without review can disrupt applications, controllers, operators, or platform workflows that legitimately require Secret read or management permissions. Before making changes, validate the subject, namespace, resource, and verb requirements, then replace broad access with least privilege RBAC where possible. Avoid modifying required system: RBAC roles or bindings because they support normal cluster functionality.
See Also
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: 2d920f221f6b85ae0b242d86f06b4f5d2b6cd07db07c5968227c455c7af552e7