auditing-workload-secret-exposure-surface

name	auditing-workload-secret-exposure-surface
description	Audit how a workload holds its secrets for the exposure that outlives the secret's intent: a secret passed as an environment variable that any process, crash dump, or child inherits and that debug endpoints echo, a secret volume mounted where a sidecar or a shared process can read it, a secret written into logs or an error, and a Kubernetes secret readable by more service accounts than the one workload that needs it. Covers containerized workloads where secrets reach the process through environment, mounted files, or the orchestrator's secret store. Use when a workload consumes secrets and the question is who or what else can read them. The workload secret is the source, the process, sidecar, log, or extra reader that can see it is the sink, and the exposure beyond the intended consumer is the bug.
license	MIT

Auditing workload secret exposure surface: who else can read this secret

A secret a workload needs is safe only if nothing beyond the intended consumer can read it, and containerized delivery quietly widens that set. An environment variable is inherited by every child process, echoed by many debug and introspection endpoints, and captured in crash dumps and process listings, so an env secret is readable by far more than the code that meant to use it. A mounted secret file is readable by every container in the pod that shares the mount, so a sidecar becomes a reader. A secret that lands in a log line or an error message is exposed to whoever reads logs, which is usually a much broader audience than whoever holds the secret. And the orchestrator's secret object is readable by every identity its access rules admit, often more service accounts than the one workload. The audit is not whether the secret exists but who else can see it. You audit this by tracing each secret from its store into the workload and enumerating every other reader.

When to use

• Workloads consume secrets through environment variables, mounted files, or the orchestrator's secret store.
• Sidecars, child processes, debug endpoints, or logs may be able to read a secret meant for one consumer.
• A secret object may be readable by more identities or service accounts than the single workload that needs it.

Scope check

Audit secret exposure only for workloads and clusters you own or are authorized to assess, on non-production secrets. Confirming exposure means reading a real secret through the exposing path, so use non-production credentials and never exfiltrate or reuse a secret you surface. If you can't name the authorization, stop.

The loop

1. Establish the intended consumer first. Name, for each secret, the single process or workload that is supposed to read it and nothing else. This is the false-positive killer: a secret delivered as a file mounted only into the one container that needs it, with the secret object readable by only that workload's service account, is correctly scoped. Name the intended consumer, then enumerate every other reader.

2. Check the delivery mechanism. Determine how each secret reaches the workload: an environment variable, a mounted file, or a fetched value. Environment delivery is the widest exposure, inherited by children and exposed by introspection; a file mounted only where needed is narrower. Note the mechanism, since it sets the default exposure.

3. Enumerate in-pod readers. For each secret, find what else in the pod can read it: sidecar and init containers sharing a mounted secret volume, child processes inheriting an env secret, and any process able to read another's environment. A multi-container pod turns one secret into a secret every container can see unless the mount is scoped.

4. Trace leakage into logs, errors, and endpoints. Follow whether the secret appears in log lines, error messages, stack traces, crash dumps, or debug and introspection endpoints that echo the environment. A secret in a log is exposed to everyone with log access; an endpoint that dumps the environment exposes every env secret to whoever can reach it.

5. Scope the secret object's readers. For the orchestrator's secret store, compute which identities and service accounts can read each secret object through RBAC and namespace access. Compare that to the single intended workload. A secret readable by a broad role, many service accounts, or a shared namespace is exposed to all of them regardless of how narrowly the pod consumes it.

6. Confirm and record. Confirm by reading a secret through an unintended path, a sidecar reading the mount, a debug endpoint echoing an env secret, a log line containing it, or an extra service account fetching the object, in scope and without exfiltrating. Kill the lead if each secret is delivered only to its one consumer, no other in-pod reader or log or endpoint exposes it, and the secret object is readable only by the intended workload's identity. Record the secret source, the extra-reader sink, and the exposure beyond the intended consumer.

Where secret exposure surface leaks

• Environment variables spread the secret. An env secret is inherited by children, shown in process listings and crash dumps, and echoed by introspection endpoints.
• A shared mount makes sidecars readers. A secret volume mounted into a multi-container pod is readable by every container that shares it, not just the consumer.
• Logs and errors carry secrets to a wider audience. A secret in a log line or stack trace is exposed to everyone with log access, which is broader than the secret's holders.
• Debug endpoints dump the environment. An introspection or debug endpoint that echoes the environment exposes every env secret to whoever can reach it.
• A broadly readable secret object exposes to all readers. A secret the orchestrator lets many identities read is exposed to all of them regardless of the pod's narrow use.

Worked example (a confirm and a kill)

Confirm. A workload receives a database password as an environment variable, the pod runs a logging sidecar, and the application exposes a debug endpoint that prints its environment. The debug endpoint returns the password, and because it is an env variable a diagnostic child process also captures it in a crash dump. Confirmed secret exposure beyond the intended consumer via environment and debug endpoint, high, remediation = deliver the secret as a file mounted only into the consuming container, disable or gate the environment-dumping endpoint, and scrub secrets from logs and crash output.

Kill. Each secret is delivered as a file mounted only into the one container that needs it, no sidecar or init container shares the mount, no log line or error contains a secret, no endpoint echoes the environment, and the secret object is readable only by that workload's dedicated service account. Nothing beyond the intended consumer can read the secret. Killed, kill_reason = "secret file-mounted to its sole consumer with no shared mount, no log or endpoint leakage, and a single-identity-readable secret object; no reader exists beyond the intended workload."

Rationalizations to reject

• "It is just an environment variable." → Env secrets are inherited by children, shown in process listings and crash dumps, and echoed by debug endpoints; that is a wide exposure, not a convenience.
• "Only our container is in the pod." → Confirm no sidecar or init container shares the secret mount, and that no future sidecar will; a shared mount makes every container a reader.
• "We do not log secrets." → Confirm error messages, stack traces, and crash dumps do not either; secrets leak into logs through errors more often than through deliberate logging.
• "The debug endpoint is internal." → Internal reachability is still exposure; an environment-dumping endpoint hands every env secret to anyone who reaches it.
• "The secret is in the orchestrator's secret store." → Storage is not scope; compute which identities can read the object and compare to the one intended workload.

Executing this in practice

You need each secret's delivery mechanism, the other containers and child processes that can read it, whether it appears in logs, errors, or introspection endpoints, and the identities that can read the secret object. For each secret, enumerate every reader beyond the intended consumer. Reading the workload spec and RBAC shows the granted exposure; reading the secret through an unintended path shows whether it holds.

Related

• hunting-non-human-identity-and-secret-reachability - the machine-credential reachability discipline; this skill is its in-workload delivery half.
• reviewing-secrets-manager-access-policy-trust - the managed-store companion; moving secrets there with a scoped policy is often the durable remediation.
• auditing-observability-pipeline-collector-trust - the logging side where a leaked secret travels; a secret in a log reaches wherever the pipeline forwards it.
• mapping-pod-to-cloud-credential-reach - what an exposed secret then reaches in the cloud; exposure and reach compound.
• FINDING-SCHEMA.md - source = the workload secret, sink = the extra process, sidecar, log, or reader that can see it, evidence = the exposure beyond the intended consumer.