Skip to main content

More Info:

Native Kubernetes Secrets are only base64-encoded and stored in etcd. Consider a dedicated external secrets management solution to improve secret protection and lifecycle management.

Risk Level

Medium

Address

Security

Compliance Standards

  • APRA CPS 234 (Australia)
  • BSI C5 (Germany)
  • Brazil LGPD
  • CCPA / CPRA (California)
  • CIS Critical Security Controls v8
  • CIS GKE
  • 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 how Kubernetes Secrets are currently used
    • On any machine with kubectl access, list all Secrets and their types:
    • Inspect a few representative secrets (workload-related, not service-account tokens):
    • Note where secrets are consumed (Pods, Deployments, StatefulSets, Jobs) via env.valueFrom.secretKeyRef and volumes.secret.
  2. Check for existing external secret management integrations
    • Look for operators/controllers that integrate with external stores (for example, External Secrets Operator, Secrets Store CSI Driver, or cloud‑specific controllers):
    • If such components exist, inspect their configuration to see which backend is in use (e.g., AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, HashiCorp Vault).
  3. Review cloud provider secret-management options and policies
    • In your cloud console and/or IaC, identify whether a managed secret store is already configured for this cluster’s workloads (e.g., IAM roles, Workload Identity, KMS keys, Secret Manager/Key Vault/Secrets Manager resources).
    • Confirm if organizational policy requires use of that store instead of (or in addition to) Kubernetes Secrets for application credentials.
  4. Decide which secrets must move to external storage
    • Based on the inventory, classify secrets by sensitivity (database passwords, API keys, encryption keys vs. low‑risk config).
    • For highly sensitive or regulated data, decide to migrate them to a supported external secret store, following your cloud provider’s recommended integration pattern (operator, CSI driver, or sidecar).
  5. Plan and implement the migration pattern
    • For each selected workload, design how it will obtain secrets from the external store (environment variables injected by a controller, mounted files via CSI, or app‑level API calls).
    • Update or create manifests (via kubectl and IaC) to consume secrets from the chosen integration (for example, defining ExternalSecret or CSI SecretProviderClass resources), and remove or deprecate direct reliance on native Kubernetes Secrets for those values.
  6. Verify reduced reliance on native Kubernetes Secrets
    • After changes, confirm that sensitive values are now sourced via external mechanisms and that corresponding Kubernetes Secrets are no longer needed or only store references/tokens as designed:
    • Ensure applications start successfully and retrieve expected secret values via the external store before removing any legacy Kubernetes Secrets.
Review which namespaces are used for applications (beyond kube-system, kube-public, etc.); these are likely to contain sensitive Secrets.
Potential problems indicated by:
  • Many Opaque or kubernetes.io/dockerconfigjson secrets in app namespaces.
  • Secrets present in non-critical namespaces where config maps would suffice.
Look at the .data entries (base64-encoded). Problems indicated by:
  • Keys like password, token, apikey, ssh-privatekey, tls.key, db_url, etc.
  • Large numbers of such sensitive values stored as native Secrets instead of a dedicated external store.
Problems indicated by:
  • Critical workloads (auth, payments, PII, production databases) consuming many Secrets via env vars or volumes.
  • Secrets used across many Pods/namespaces, suggesting centralized secrets would be better managed in an external vault.
Interpretation:
  • If you see CRDs like externalsecrets.external-secrets.io, clusterssecrets, vaultsecrets, the cluster may already integrate with an external secrets manager.
  • If no such resources exist and Steps 2–4 show widespread in-cluster storage of high-value credentials, that suggests a stronger case for adopting an external secrets management solution as recommended by the benchmark.