This rule detects clusters of Kubernetes API get requests targeting the secrets API across multiple distinct secret names within a defined lookback window. It groups activity by user.name, source.ip, and user_agent.original and flags when the same identity retrieves or probes at least three different secret names (capturing both successful reads and failures). The detection relies on Kubernetes audit logs (event.dataset == kubernetes.audit_logs) and surfaces fields such as Esql.unique_credentials, Esql.secrets_names, Esql.namespaces, and Esql.outcome to aid investigation. The rule includes both possible malicious activity (credential harvesting or in-cluster reconnaissance) and benign cases (CI/CD or controllers touching secrets). It also accounts for failed/forbidden attempts that can reveal RBAC boundaries or existence checks. Triage guidance emphasizes verifying RBAC scope, identifying high-value targets (tokens, registry credentials, TLS material), and pivoting to related activity (exec, pod creation, role changes, broad list operations). False positives can arise from legitimate bootstrapping, Helm, or controller processes that touch many secrets within a short window; baselining and allowlisting by user, namespace, or IP can reduce noise. This rule is mapped to MITRE ATT&CK Credential Access techniques and is designed to help detect credential targeting and reconnaissance in Kubernetes environments.