Skip to main content

More Info:

Storing secrets in an external, dedicated secrets manager reduces exposure compared to native Kubernetes secrets. Evaluate cloud provider or third-party secrets management solutions.

Risk Level

Medium

Address

Security

Compliance Standards

  • APRA CPS 234 (Australia)
  • AWS Startup Security Baseline
  • BSI C5 (Germany)
  • Brazil LGPD
  • CCPA / CPRA (California)
  • CIS Critical Security Controls v8
  • CIS EKS
  • CMMC 2.0
  • CSA Cloud Controls Matrix v4
  • DPDPA
  • Digital Operational Resilience Act (EU)
  • Essential 8
  • ISO/IEC 27017
  • ISO/IEC 27018
  • ISO/IEC 27701
  • KSA PDPL
  • MAS Technology Risk Management (Singapore)
  • MITRE ATT&CK (Cloud)
  • NIS2 Directive
  • NIST SP 800-171
  • NYDFS 23 NYCRR 500
  • SWIFT Customer Security Controls Framework
  • Sarbanes-Oxley IT General Controls
  • UK NCSC Cyber Assessment Framework

Triage and Remediation

Remediation

Manual Steps

  1. Inventory current Kubernetes Secrets usage
    Run these on any machine with kubectl access:
    If allowed in your environment, spot-check contents (never export broadly in shared terminals/logs):
  2. Identify workloads depending on Kubernetes Secrets
    Record which applications, namespaces, and service accounts rely on Secrets, and which specific secrets are high sensitivity (DB creds, API keys, encryption keys, etc.).
  3. Evaluate current secret protection controls
    On any machine with kubectl access, check if secret data at rest is protected (for managed EKS, review in cloud console/IaC if envelope encryption for secrets is enabled and with which KMS key). For cluster-scoped view:
    In your cloud console / IaC, review:
    • Whether Kubernetes Secrets are encrypted with a customer-managed KMS key.
    • Who can access that KMS key (IAM roles/policies).
    • Who can list/get Secrets via cluster RBAC.
  4. Assess need and options for external secret storage
    Based on steps 1–3, decide which secrets should move to an external manager (e.g., all production / highly sensitive secrets). For your environment, review in cloud console/IaC:
    • Availability of cloud-native secret managers (e.g., AWS Secrets Manager / Parameter Store, GCP Secret Manager, Azure Key Vault, HashiCorp Vault).
    • Native integrations or operators for Kubernetes (e.g., External Secrets Operator, Secrets Store CSI Driver).
    • Compliance or audit requirements that may mandate external secret storage or HSM-backed keys.
  5. Design the integration pattern and update manifests
    Choose one pattern (examples, adapt to your platform and tooling):
    • Secrets Store CSI Driver / external secrets operator: pods mount secrets from external store as volumes or sync to Kubernetes Secrets.
    • Sidecar / init container that fetches secrets from the external manager and writes them to a tmpfs volume.
      For the chosen pattern, update deployment manifests to stop embedding static credentials and instead reference the external source. Example (CSI driver style – conceptual, not a one-size-fits-all fix):
    Apply updated manifests from a machine with kubectl access:
  6. Verify and decommission in-cluster secrets where appropriate
    a. Verify workloads now retrieve secrets from the external store and still function:
    b. Confirm that application pods no longer list the previous Kubernetes Secrets in env or volume mounts:
    c. After confirming safe cutover and rollback plan, carefully delete or reduce high-sensitivity Kubernetes Secrets that are no longer needed:
    Document which applications now depend on the external secrets manager and ensure access to the external secrets is governed via cloud/IAM policies instead of (or in addition to) in-cluster RBAC.
Review all non-system namespaces (ignore kube-system, kube-public, kube-node-lease).
Indicators of higher risk from this output:
  • Large numbers of application-owned Opaque secrets (not just service account or TLS certs).
  • Secrets holding long‑lived credentials (database users, API keys, cloud access keys).
  • Same secret reused across many workloads or namespaces.
  • Secrets embedded as env vars in many pods (easy to leak via logs, debug, etc.).
Human review guidance:
  • Names like *-db-password, *-api-key, *-aws-credentials, *-token usually indicate external system secrets that are good candidates for an external manager.
  • If those secrets are long‑lived and manually rotated, that strengthens the case for an external secrets manager.
Problem indicators in this cluster-wide view:
  • Many Opaque secrets in application namespaces storing business‑critical or external credentials.
  • Same‑name secrets across namespaces that obviously mirror the same external system (e.g., db-credentials in many namespaces) instead of being sourced from a dedicated secrets manager.
  • No evidence of any integration with an external secrets operator (e.g., no CRDs like externalsecret), suggesting everything is native Kubernetes secrets.
Interpretation:
  • If there are no CRDs or controllers related to external secrets and you see many high‑sensitivity Opaque secrets as described above, that is a strong signal that external secret storage should be considered.
  • If external secret tooling is present, verify whether the high‑sensitivity secrets identified earlier are actually sourced from it or still managed as plain Kubernetes secrets.