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
MediumAddress
SecurityCompliance 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
Remediation
Manual Steps
Manual Steps
-
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.secretKeyRefandvolumes.secret.
- On any machine with kubectl access, list all Secrets and their types:
-
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).
- Look for operators/controllers that integrate with external stores (for example, External Secrets Operator, Secrets Store CSI Driver, or cloud‑specific controllers):
-
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.
-
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).
-
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
ExternalSecretor CSI SecretProviderClass resources), and remove or deprecate direct reliance on native Kubernetes Secrets for those values.
-
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.
- 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:
Using kubectl
Using kubectl
- Many
Opaqueorkubernetes.io/dockerconfigjsonsecrets in app namespaces. - Secrets present in non-critical namespaces where config maps would suffice.
.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.
- 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.
- 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.
Automation
Automation

