This rule detects clusters of GKE (Google Kubernetes Engine) API calls that read secrets, where the same client identity (fingerprinted by client.user.email, source.ip, and user_agent.original) touches multiple distinct Secret objects within a six-minute lookback window. It targets both successful and failed secret get requests, as failures can indicate RBAC probing or reconnaissance, while successful reads may indicate credential harvesting or exposure to sensitive data (service account tokens, registry credentials, TLS material, or application configuration). System service accounts are excluded only when reads succeed, since failed access by these identities can still signal issues worth investigating. The detection uses a GCP audit log dataset (gcp.audit) with event.action io.k8s.core.v1.secrets.get and aggregates data by identity and client path; the rule flags when at least three distinct secret resource paths are touched by the same identity. It intentionally excludes local loopback addresses and known benign automation (e.g., Helm, controllers) to reduce noise. The result includes the number of distinct resources touched and the list of resource names, along with outcome values and timestamps for investigation. The rule is categorized under Credential Access (MITRE ATT&CK T1552.007 Container API) with a high severity and risk score, reflecting the potential for in-cluster reconnaissance or credential exfiltration. It relies on the GCP Fleet integration with GKE audit logs enabled to be actionable. Triage steps emphasize validating the identity’s RBAC scope, mapping to namespaces, reviewing high-value targets (token or TLS material), and pivoting to related activity (exec, pod creation, role changes, broad secret enumeration) to determine malicious intent. False positives can arise from legitimate automation (startup, Helm, or controllers) touching multiple secrets in a short window, so baselining and exclusions by known automation or IP allowlists are recommended during tuning.