secrets

Overview ¶

Package secrets analyzes Secret metadata and ConfigMap contents for hygiene issues such as legacy service-account tokens, sensitive kube-system data, credential-like keys leaked into ConfigMaps, and risky CoreDNS rules.

ConfigMap credential-key detection (per-key, high-confidence variant).

The existing KUBE-CONFIGMAP-001 rule emits a single finding per ConfigMap listing every credential-shaped key (uses a permissive substring list including "key", which catches many false positives). This rule (KUBE-CONFIGMAP-CREDS-001) instead emits one finding per (ConfigMap, key) pair using a *high-confidence* token list: keys that are almost always real credentials when they appear in a config, e.g. `password`, `passwd`, `secret`, `token`, `apikey` / `api_key`, `dsn`, `connection_string`, `aws_secret_access_key`. Severity is HIGH because matches are rarely false positives (in contrast to KUBE-CONFIGMAP-001's MEDIUM, which has to live with `key`-style false positives).

Per the privacy contract in CLAUDE.md, the collector blanks ConfigMap values to empty strings; this rule operates on key names only.

Content for Secret/ConfigMap hygiene findings. Each builder takes runtime context (namespace, name, matched keys, Corefile snippet) and returns a ruleContent with scope, attacker walkthrough, ordered remediation, and authoritative references.

Sources: Kubernetes Secret docs, KEP-1205 (BoundServiceAccountTokens), CIS Kubernetes Benchmark 5.4.1 / 5.1.5, NSA/CISA Hardening Guide v1.2, MITRE ATT&CK T1552.001/.007, CoreDNS docs, Aqua/Sysdig writeups on DNS rebinding inside clusters.

Cross-namespace secret-read detection: a workload-mounted ServiceAccount has RBAC permission to read Secrets in a *different* namespace from where the workload runs. The namespace boundary is K8s's primary isolation surface, and cross-namespace secret reads collapse it for the secret-read axis without needing any further pivot.

Emit one finding per (subject, target_namespace) pair so the same over-broad ClusterRoleBinding doesn't flood the report with one finding per Secret it could reach. The target_namespace is the namespace the secret-read grant resolves to (or "*" when the grant comes from a ClusterRoleBinding without a Namespace).

Stale-secret detection: a Secret is unreferenced if no Pod env / envFrom / volume names it and no ServiceAccount lists it under `secrets` / `imagePullSecrets`. Stale credentials are pure exposure surface (every subject with `get secrets` in the namespace can still read them) with no operational value, so flagging them is one of the lowest-friction hygiene wins available.

Service-account-token Secrets are intentionally excluded: they have their own dedicated rule (KUBE-SECRETS-001) and the legacy controller often creates ones that look "unreferenced" in the snapshot but are still owned by the SA controller.

TLS-secret expiry detection: a `kubernetes.io/tls` Secret whose annotation metadata reports a certificate NotAfter within 30 days or already in the past. The collector's privacy contract (see CLAUDE.md) means raw Secret values are never read, so we cannot inspect tls.crt directly. Instead we rely on cert-manager's annotation conventions:

• cert-manager.io/not-after (canonical, set by cert-manager v1.5+)
• cert-manager.io/notafter (legacy/alternate spelling)
• cert-manager.io/expiration (older convention seen in third-party ACME controllers)

Secrets without any of those annotations are silently skipped: the rule degrades to a no-op rather than firing on every TLS Secret in the cluster. The remediation prose is explicit about the best-effort framing.