Consider External Secret Storage

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

# 2) List all Secrets in each namespace
# Run once per namespace of interest
kubectl get secrets -n default
kubectl get secrets -n kube-system
kubectl get secrets -n production

# 3) Inspect individual Secrets (metadata only)
kubectl get secret my-secret -n production -o yaml

# 4) Check for use of external secret controllers
kubectl get crd | grep -iE 'secret|vault|external|csi'

# 5) List known external secret resources (if present)
kubectl get externalsecrets -A 2>/dev/null
kubectl get secretproviderclasses -A 2>/dev/null

# 6) Identify Secrets likely used for application credentials
kubectl get secrets -A -o jsonpath='{range .items[*]}{.metadata.namespace}{" "}{.metadata.name}{" "}{.type}{"\n"}{end}' \
  | grep -E 'Opaque|kubernetes.io/basic-auth|kubernetes.io/ssh-auth'

# 7) Spot-check Pods that mount/use Secrets
kubectl get pods -n production -o yaml | grep -nE 'secretRef|secretName'

#!/usr/bin/env bash
set -euo pipefail

# This script runs on: any machine with kubectl access and appropriate RBAC.
# It reports where and how native Kubernetes Secrets are used, so you can
# review what should be migrated to an external secrets manager.

# 1) List all Secrets (namespaced and cluster-scoped fields)
echo "=== ALL SECRETS (namespace, type, name, age, size-of-data-keys) ==="
kubectl get secrets --all-namespaces -o json \
  | jq -r '
    .items[]
    | [
        .metadata.namespace,
        .type,
        .metadata.name,
        (now - (.metadata.creationTimestamp | fromdate)) as $age,
        ($age/86400|floor|tostring + "d"),
        ( .data | keys | length ) as $keys,
        ($keys|tostring)
      ]
    | @tsv
  ' 2>/dev/null \
  | awk 'BEGIN{OFS="\t"; print "NAMESPACE","TYPE","NAME","AGE","DATA_KEY_COUNT"} {print $1,$2,$3,$5,$6}'
echo

# 2) Highlight Secrets that are very likely to hold sensitive credentials
# (these warrant special review for moving to an external manager)
echo "=== POTENTIALLY SENSITIVE SECRETS (by common name patterns) ==="
kubectl get secrets --all-namespaces -o json \
  | jq -r '
    .items[]
    | select(
        (
          .metadata.name
          | test("(?i)(password|passwd|secret|token|key|cert|tls|ssh|api|auth)")
        )
        or
        (
          (.type|tostring)
          | test("(?i)(tls|dockercfg|dockerconfigjson|basic|ssh)")
        )
      )
    | [.metadata.namespace, .type, .metadata.name]
    | @tsv
  ' 2>/dev/null \
  | awk 'BEGIN{OFS="\t"; print "NAMESPACE","TYPE","NAME"} {print $1,$2,$3}'
echo

# 3) Find workloads that mount or reference Secrets directly
echo "=== WORKLOADS USING SECRETS (envFrom, env.valueFrom, volumes.secret) ==="
for kind in deployments statefulsets daemonsets jobs cronjobs replicasets pods; do
  kubectl get "$kind" --all-namespaces -o json 2>/dev/null \
    | jq -r --arg KIND "$kind" '
      .items[]?
      | . as $obj
      | ($obj.spec.template // $obj) as $tpl
      | [
          $obj.metadata.namespace,
          $KIND,
          $obj.metadata.name,
          (
            ($tpl.spec.containers // []) as $cs
            | ($tpl.spec.initContainers // []) as $ics
            | ($cs + $ics)
            | map(
                [
                  .name,
                  (
                    ((.envFrom // [])[]?.secretRef.name? // empty),
                    ((.env // [])[]?.valueFrom.secretKeyRef.name? // empty)
                  ) | unique | join(",")
                ] | @tsv
              )
            | unique
            | join(";")
          ),
          (
            ($tpl.spec.volumes // [])
            | map(select(.secret != null) | .secret.secretName)
            | unique
            | join(",")
          )
        ]
      | @tsv
    ' 2>/dev/null
done \
  | awk 'BEGIN{
      OFS="\t";
      print "NAMESPACE","KIND","WORKLOAD","CONTAINERS->SECRET_ENV","VOLUME_SECRETS";
    } {print $1,$2,$3,$4,$5}'
echo

# 4) Summarize Secrets usage by namespace to show “hot spots”
echo "=== SUMMARY: SECRETS COUNT BY NAMESPACE ==="
kubectl get secrets --all-namespaces \
  | awk 'NR>1 {cnt[$1]++} END {OFS="\t"; print "NAMESPACE","SECRET_COUNT"; for (ns in cnt) print ns,cnt[ns]}' \
  | sort -k2,2nr
echo

# 5) Optional: show if EncryptionConfiguration is configured for Secrets (best-effort)
# NOTE: This only works if you can access the API server manifest on control plane nodes.
# Here we only check the API server config seen by kubectl (may be empty on managed control planes).
echo "=== NOTE: Encryption at rest for Secrets must be verified on control-plane hosts ==="
echo "Run on every control plane node (over SSH), for example:"
echo "  sudo grep -E \"encryption-provider-config\" /etc/kubernetes/manifests/kube-apiserver.yaml || true"
echo

echo "=== INTERPRETING OUTPUT ==="
cat <<'EOF'
Output indicating higher priority for external secret storage review:

1) ALL SECRETS:
   - Namespaces with a high SECRET_COUNT (in the summary) or many Secrets of type:
       * Opaque
       * kubernetes.io/basic-auth
       * kubernetes.io/ssh-auth
       * kubernetes.io/tls
       * kubernetes.io/dockerconfigjson
   suggest heavier reliance on native Secrets.

2) POTENTIALLY SENSITIVE SECRETS:
   - Any Secret listed here likely contains credentials or keys.
   - These are prime candidates for moving to an external secrets manager that:
       * Requires strong authentication
       * Audits access and use
       * Encrypts data and supports rotation

3) WORKLOADS USING SECRETS:
   - Workloads with many SECRET_ENV or VOLUME_SECRETS entries are tightly coupled
     to Kubernetes Secrets.
   - Namespaces where most workloads consume such Secrets should be evaluated for
     integration with an external secrets solution (e.g., syncing or injecting
     from a cloud/third-party secrets manager instead of manual Secret objects).

This script does not apply any changes. Use it to:
   - Identify which secrets and namespaces should move first.
   - Scope the impact of introducing an external secrets manager.
EOF