This rule uses a new-terms detection on Google Cloud Platform (GCP) audit logs to identify potential credential access in Google Kubernetes Engine (GKE). It flags get/list operations on Kubernetes secrets (io.k8s.core.v1.secrets.get/list) where the combination of source IP, client.user.email, and user_agent.original is observed for the first time within a 7-day history window. The detection excludes the default Kubernetes client placeholder and anonymous identities, focusing on requests from unfamiliar hosts or clients. The rule targets data from logs-gcp.audit-* with service.name:k8s.io, and relies on the history of previously seen triples (source.ip, client.user.email, user_agent.original) to surface novel access patterns that may indicate a compromised pod, stolen kubeconfig, or unusual client behavior attempting to read service account tokens, registry credentials, or application secrets. It maps to MITRE ATT&CK techniques under Credential Access, specifically T1552 (Unsecured Credentials) and the Container API subtechnique T1552.007. The rule’s severity is low with a risk score of 21, reflecting its potential for early warning of credential access events that require validation. The rule requires the GCP Fleet integration with GKE audit logs enabled. Triage steps include reviewing client.user.email, source.ip, user_agent.original, and gcp.audit.resource_name to determine if the client fingerprint aligns with an approved admin path, CI runner, or controller upgrade; investigate for secret bursts or related pod activity; and pivot on the same identity or IP for token creation or RBAC changes. False positives can arise from legitimate admin workstations, VPN egress, or SDK/version changes introducing new clients; baselining is recommended. Remediation involves revoking compromised credentials, rotating exposed secrets, isolating the source workload, and tightening who can read secrets.