Check ID: core_no_secrets_envs
Provider: Kubernetes
Service: core
Severity: HIGH
Categories: secrets
Resource type: Pod

​
What this check verifies

Kubernetes Pods containers define environment variables sourced from Secrets via secretKeyRef instead of mounting them as files.

​
Risk

Secrets in env vars weaken confidentiality:
  • Leak via logs, dumps, /proc/*/environ, debug UIs, and pod metadata
  • Propagate to child processes; rotation is hard Attackers can steal credentials for unauthorized access and lateral movement, risking data integrity and service availability.

​
Recommendation

Use Secrets as files (read-only volumes) and load at runtime.
  • Apply least privilege RBAC to Secret access
  • Scope Secrets to required containers; avoid logging env
  • Prefer short-lived creds and regular rotation; set immutable: true when suitable
  • Layer defense in depth with network and runtime controls

​
Remediation

# Use a Secret as a volume (no secretKeyRef in env) to pass the check
resource "kubernetes_pod" "<example_resource_name>" {
  metadata { name = "<example_resource_name>" }
  spec {
    container {
      name  = "<example_resource_name>"
      image = "busybox"
      volume_mount {
        name       = "<example_resource_name>-secret"  # critical: mount Secret as files instead of env vars
        mount_path = "/etc/secret"
        read_only  = true
      }
    }
    volume {
      name = "<example_resource_name>-secret"
      secret { secret_name = "<example_resource_name>" }  # critical: reference the Secret via a volume
    }
  }
}

​
References

​
Where this check fires

This check runs on every scheduled scan against your Kubernetes account. Findings appear at Cloud Security → Findings filterable by Check ID = core_no_secrets_envs. To re-evaluate after a fix, hit Run now on the account’s schedule under Cloud Security → Schedules — the next scan re-checks this control and marks the finding fixed or keeps it persistent.
← Back to Kubernetes checks