Client Certificate Authentication Should Not Be Used For Users

#!/usr/bin/env bash
#
# Purpose:
#   Enumerate where client-certificate authentication is used for *users*
#   (as opposed to internal components), so it can be reviewed and phased
#   out in favor of OIDC or other revocable mechanisms.
#
# Requirements:
#   - Run on any machine with kubectl and (optionally) openssl/jq
#   - KUBECONFIG configured with access to the cluster

set -euo pipefail

echo "=== 1) kubectl user identities (from current kubeconfig) ==="
# Machine: any machine with kubectl access
kubectl config view --flatten --output='jsonpath={.users[*].name}' | tr ' ' '\n' | sort -u | sed '/^$/d' || true

echo
echo "For each user above, inspect its auth mechanism:"
echo

# Show full users section so you can see client-certificate-data / client-key-data use
kubectl config view --flatten -o json | jq '.users' 2>/dev/null || kubectl config view --flatten

cat <<'EOF'

Interpretation:
- Any user entry that has fields like:
    "client-certificate": "path/to/cert"
    "client-key": "path/to/key"
  or:
    "client-certificate-data": "BASE64..."
    "client-key-data": "BASE64..."
  is using client certificate authentication.
- These are *suspect* for this control if they represent human users rather than components
  (e.g. "alice", "devops-admin", "ci-bot" vs "kubernetes-admin", "system:admin", or node identities).

Action:
- Flag human/long‑lived users that rely on client certs and plan migration to OIDC or another
  revocable method.

EOF

echo "=== 2) Detect client‑certificate auth in kubeconfig used by common automation accounts ==="
echo "Checking for client-certificate usage in typical locations (~/.kube/config, KUBECONFIG)..."
echo

for cfg in "$HOME/.kube/config" ${KUBECONFIG:-}; do
  [ -f "$cfg" ] || continue
  echo "---- $cfg ----"
  if grep -E 'client-certificate|client-certificate-data' "$cfg" >/dev/null 2>&1; then
    echo "POTENTIAL PROBLEM: client-certificate auth is in use in this kubeconfig."
    grep -nE 'name:|user:|client-certificate|client-certificate-data' "$cfg" | sed 's/^/  /'
  else
    echo "OK: no client-certificate fields found in this kubeconfig (may be using tokens/OIDC)."
  fi
  echo
done

cat <<'EOF'

Interpretation:
- Lines under a user that reference client-certificate / client-certificate-data indicate use
  of client cert auth. If those users are humans or long-lived service accounts, they are
  non-compliant with this control.
- Kubeconfigs that use:
    - exec: plugins (e.g. aws-iam-authenticator, gcloud, az) or
    - id-token / access-token / auth-provider: oidc
  are generally OK for this control.

EOF

echo "=== 3) Identify client‑certificate usage from apiserver audit logs (if available) ==="
echo "NOTE: This is optional and depends on audit logging configuration and log access."
echo "      Run the following on every control plane node that has API server audit logs:"
cat <<'EOF'

# On every control plane node (adjust paths to your environment):

AUDIT_DIR="/var/log/kubernetes/audit"   # or /var/log/kube-apiserver, /var/log/apiserver, etc.
LOG_FILE_PATTERN="*.log"

# Example grep to show client certificate subjects seen by the apiserver:
sudo find "$AUDIT_DIR" -name "$LOG_FILE_PATTERN" -type f -print0 2>/dev/null | \
  xargs -0 sudo grep -Eo '"user":{"username":"[^"]+","groups":\[[^]]*\],"extra":\{[^}]*"authentication.kubernetes.io/x509name":"[^"]+"' | \
  sed 's/.*"username":"\([^"]\+\)".*"authentication.kubernetes.io\/x509name":"\([^"]\+\)".*/USERNAME=\1  X509_SUBJECT=\2/' | \
  sort -u

EOF

cat <<'EOF'

Interpretation:
- Any USERNAME/X509_SUBJECT pairs you see there are identities that authenticated
  with an X.509 client certificate.
- If those usernames correspond to human or long‑lived users (as opposed to
  system: nodes, controllers, or internal components), they are in scope for this finding.

EOF

echo "=== 4) Summary: what indicates a problem? ==="
cat <<'EOF'
You have a *problem* for this control when:
- A human user or long‑lived non‑system identity (e.g. "alice", "team-admin",
  "jenkins-prod") in kubeconfig or in audit logs is authenticated via a client
  certificate (client-certificate / client-certificate-data).
You are *aligned* with the control when:
- Humans and long‑lived identities authenticate using OIDC or another revocable
  mechanism (tokens tied to IdP or short‑lived cloud IAM credentials), and
- Client certificate authentication is only used for internal Kubernetes
  components where it cannot be disabled.

This script does not and cannot automatically fix the issue; it only surfaces
where client certificate auth is being used so you can plan migration to OIDC
or another revocable mechanism per the benchmark guidance.
EOF