Credential Access: Secrets Accessed in Kubernetes Namespace

This document describes a threat finding type in Security Command Center. Threat findings are generated by threat detectors when they detect a potential threat in your cloud resources. For a full list of available threat findings, see Threat findings index.

Overview

A Pod's default Kubernetes service account was used to access Secret objects in the cluster. The default Kubernetes service account shouldn't have access to Secret objects unless you explicitly granted that access with a Role object or a ClusterRole object.

Event Threat Detection is the source of this finding.

The following response plan might be appropriate for this finding, but might also impact operations. Carefully evaluate the information you gather in your investigation to determine the best way to resolve findings.

How to respond

To respond to this finding, follow these steps:

1. Identify the scope of access:

   • In the finding JSON, note the value of finding.resourceName. This indicates the Kubernetes namespace or resource where the access occurred.
   • Note the value of resource.sourceProperties.affectedResources.gcpResourceName. This is the full resource name of the Kubernetes Secret that was accessed.

2. Investigate Cloud Audit Logs:

   • Go to the Logs Explorer in the Google Cloud console.

   • Filter the logs to find the specific actions taken on Kubernetes secrets. Use the following filter:

     resource.type="k8s_cluster"
     protoPayload.methodName=~"io\.k8s\.core\.v1\.secrets\..*"
     

   • Look for entries with protoPayload.methodName values such as io.k8s.core.v1.secrets.get and io.k8s.core.v1.secrets.list around the time the finding was generated. These logs can provide more context on who or what accessed the secret and what actions were performed.

   • Check for role-based access control (RBAC) changes (which are necessary for a Pod to be able to access the secret) by using the following log filter:

     resource.type="k8s_cluster"
     protoPayload.methodName:"io\.k8s\.authorization\.rbac\.v1\..*"
     

     Specifically, look for logs with methodName of io.k8s.authorization.rbac.v1.roles.create/update or io.k8s.authorization.rbac.v1.rolebindings.create/update.

3. Review Google Kubernetes Engine RBAC Configuration:

   • Go to the Kubernetes Engine section in the Google Cloud console.
   • Navigate to your cluster and select Object Browser.
   • Expand the rbac.authorization.k8s.io group.
   • Inspect the Role and RoleBinding objects (and ClusterRole / ClusterRoleBinding if applicable) within the namespace identified in finding.resourceName.
   • Look for any roles that grant get or list permissions on secrets.
   • Identify the RoleBinding that associates the default service account (or other service accounts) in the namespace with the role granting secret access.

4. Remediate Excessive Permissions:

   • If the default service account has been granted permissions to access secrets and this is not intended, update the Role or RoleBinding to remove these permissions.
   • Follow the principle of least privilege. Only grant service accounts the minimum necessary permissions they need to function. Avoid using the default service account for workloads that require specific permissions; instead, create dedicated service accounts.
   • You can use kubectl edit role [ROLE_NAME] or kubectl edit rolebinding [ROLE_BINDING_NAME] to modify the RBAC resources.

     What's next

     • Learn how to work with threat findings in Security Command Center.
     • Refer to the Threat findings index.
     • Learn how to review a finding through the Google Cloud console.
     • Learn about the services that generate threat findings.