Consider External Secret Storage

# 1) List all namespaces
# Run on: any machine with kubectl access
kubectl get ns

# 2) List secrets per namespace (excluding service-account token secrets)
# Replace <namespace> with each namespace from the previous command
kubectl get secrets -n <namespace> \
  --field-selector='type!=kubernetes.io/service-account-token'

# 3) Inspect individual secrets for sensitive data patterns
# Replace <secret-name> and <namespace>
kubectl get secret <secret-name> -n <namespace> -o yaml

# 4) See how secrets are consumed by workloads (env vars and volumes)
# Replace <namespace>
kubectl get deploy,sts,ds -n <namespace> -o yaml

# 5) Identify secrets likely holding cloud or external service credentials
# Common keyword search in secret names (namespace by namespace)
kubectl get secrets -n <namespace> | grep -Ei 'aws|gcp|azure|db|mysql|postgres|mongo|redis|api|token|key|cert|tls'

# 6) Check for cluster-wide TLS / CA material stored as regular secrets
kubectl get secrets -A | grep -Ei 'tls|ca|certificate'

#!/usr/bin/env bash
# Run on: any machine with kubectl access and current context set to the target cluster
# Purpose: Report how Kubernetes Secrets are used so you can decide
# whether to move to an external secrets manager.

set -euo pipefail

echo "=== Cluster-wide secret inventory (by namespace and type) ==="
kubectl get secrets --all-namespaces -o json \
  | jq -r '
    .items[]
    | {ns: .metadata.namespace, name: .metadata.name, type: .type}
    | [.ns, .name, .type]
    | @tsv' \
  | column -t

echo
echo "=== Count of secrets per namespace (excluding service-account tokens) ==="
kubectl get secrets --all-namespaces -o json \
  | jq -r '
    .items[]
    | select(.type != "kubernetes.io/service-account-token")
    | .metadata.namespace' \
  | sort \
  | uniq -c \
  | sort -nr

echo
echo "=== Workloads that mount or reference native Kubernetes Secrets ==="
echo "--- Pods (includes Deployments, StatefulSets, etc. via their Pods) ---"
kubectl get pods --all-namespaces -o json \
  | jq -r '
    .items[]
    | {
        ns: .metadata.namespace,
        pod: .metadata.name,
        containers: ([.spec.containers[], (.spec.initContainers[]?)]),
        volumes: .spec.volumes
      }
    | {
        ns,
        pod,
        envSecrets: (
          [ .containers[]
            | .env[]? 
            | select(.valueFrom.secretKeyRef?)
            | .valueFrom.secretKeyRef.name
          ] | unique
        ),
        envFromSecrets: (
          [ .containers[]
            | .envFrom[]?
            | select(.secretRef?)
            | .secretRef.name
          ] | unique
        ),
        volumeSecrets: (
          [ .volumes[]
            | select(.secret?)
            | .secret.secretName
          ] | unique
        )
      }
    | select((.envSecrets + .envFromSecrets + .volumeSecrets) | length > 0)
    | [
        .ns,
        .pod,
        ( ( .envSecrets // [] ) | join(",") | if . == "" then "-" else . end ),
        ( ( .envFromSecrets // [] ) | join(",") | if . == "" then "-" else . end ),
        ( ( .volumeSecrets // [] ) | join(",") | if . == "" then "-" else . end )
      ]
    | @tsv' \
  | column -t \
  | sed '1iNAMESPACE  POD  ENV_SECRETREFS  ENVFROM_SECRETREFS  VOLUME_SECRETS'

echo
echo "=== ConfigMaps that embed data with names suggesting secrets/credentials ==="
kubectl get configmaps --all-namespaces -o json \
  | jq -r '
    .items[]
    | {
        ns: .metadata.namespace,
        name: .metadata.name,
        keys: (.data | keys? // [])
      }
    | select(.keys | length > 0)
    | select(
        ([.keys[]]
          | map( ascii_downcase
                 | test("password|passwd|pass|secret|token|apikey|api_key|key|cert|certificate")
               )
          | any
        )
      )
    | [.ns, .name, (.keys | join(","))]
    | @tsv' \
  | column -t \
  || echo "No suspicious ConfigMaps detected."

echo
echo "=== Namespaces with signs of external secret managers already in use ==="
echo "--- Looking for common CRDs and controllers (external-secrets.io, secrets-store.csi.x-k8s.io, etc.) ---"

echo "- CustomResourceDefinitions related to external secrets:"
kubectl get crd 2>/dev/null | grep -E 'externalsecret|secrets-store|vault|onepassword' || \
  echo "  None of the common external-secret CRDs found."

echo
echo "- Pods in namespaces commonly used by external secret operators:"
kubectl get pods -A \
  | grep -Ei 'external-secret|external.secrets|secrets-store|vault|hashicorp-vault|1password|onepassword' \
  || echo "  No obvious external secret controllers found."

echo
echo "=== SUMMARY: manual interpretation guidance ==="
cat <<'EOF'
Interpretation:

1) High native secret usage
   - Many non-service-account Secrets (see "Count of secrets per namespace") and
     many workloads in the "Workloads that mount or reference native Kubernetes Secrets"
     section indicate heavy reliance on Kubernetes Secrets.
   - That is a SIGNAL to review whether these should instead come from an external
     secrets manager per CIS 5.4.2.

2) Riskier patterns
   Treat the following as *higher concern* and candidates for externalization:
   - Namespaces with:
     - Large counts of Secrets holding long-lived app credentials (DB passwords,
       API keys, tokens, private keys).
   - Workloads where:
     - Secrets are mounted widely across many pods or namespaces.
     - The same sensitive Secret is reused across multiple apps.
   - ConfigMaps that appear to hold passwords/tokens (see the ConfigMap section);
     those should almost always be moved to a secrets manager.

3) Signs external secret storage is already in use
   - If you see CRDs like "externalsecrets.external-secrets.io" or
     "secretproviderclasses.secrets-store.csi.x-k8s.io", or controllers such as
     external-secrets, secrets-store-csi-driver, or vault agents, your cluster
     may already be integrated with an external secrets system.
   - In that case, focus review on namespaces and workloads that still rely
     primarily on native Kubernetes Secrets.

This script does NOT implement an automatic fix.
Use the output to:
- Identify high-value / high-risk secrets.
- Decide which should move to an external secrets manager offered by your cloud
  provider or a third party, in line with CIS 5.4.2.
EOF