Client Certificate Authentication Should Not Be Used For Users

#!/usr/bin/env bash
#
# Check for use of client certificate authentication for USERS in a GKE cluster.
# Runs with kubectl from any machine that has access to the cluster.
#
# Requirements:
#   - kubectl configured with cluster-admin level access
#   - jq installed
#
# This script does NOT make any changes. It only reports findings for review.

set -euo pipefail

echo "=== 1. Cluster info ==="
kubectl config view --minify -o json | jq '{cluster: .clusters[0].name, user: .users[0].name, context: .contexts[0].name}' || true
echo

###############################################################################
# 2. Detect kubectl contexts/users that use client certificates
###############################################################################
echo "=== 2. kubectl users in local kubeconfig using client certificates ==="
kubectl config view -o json | jq -r '
  .users[]?
  | {
      name: .name,
      clientCertificate: (.user."client-certificate" // ""),
      clientCertificateData: (if .user."client-certificate-data" then "INLINE" else "" end),
      authProvider: (.user.auth-provider.name // ""),
      execCommand: (.user.exec.command // "")
    }
' | sed 's/^/  /'
cat <<'EOF'

Interpretation:
- Any user entry with "clientCertificate" set to a path OR "clientCertificateData": "INLINE"
  indicates a context using client certificate authentication.
- For HUMAN users, this is against CIS GKE 2.1.1 and should be migrated to OIDC or another
  revocable mechanism.
- Service accounts using "token" or "auth-provider" (e.g., gcp) are NOT in scope of this finding.

Action:
- Identify which of the above "name" entries correspond to human users.
- Flag those with clientCertificate/clientCertificateData for remediation (migrate to OIDC).

EOF

###############################################################################
# 3. Inspect cluster RoleBindings/ClusterRoleBindings that might imply user cert use
###############################################################################
echo "=== 3. ClusterRoleBindings & RoleBindings that bind to explicit user subjects ==="
echo "ClusterRoleBindings with user subjects:"
kubectl get clusterrolebindings -o json \
  | jq -r '
    .items[]
    | {name: .metadata.name, subjects: (.subjects // [])}
    | select(.subjects[]? | select(.kind == "User"))
  ' 2>/dev/null | sed 's/^/  /' || echo "  None found"
echo

echo "RoleBindings with user subjects (all namespaces):"
kubectl get rolebindings --all-namespaces -o json \
  | jq -r '
    .items[]
    | {namespace: .metadata.namespace, name: .metadata.name, subjects: (.subjects // [])}
    | select(.subjects[]? | select(.kind == "User"))
  ' 2>/dev/null | sed 's/^/  /' || echo "  None found"
cat <<'EOF'

Interpretation:
- Any subject with "kind": "User" represents a user principal that could be
  authenticated via a client certificate, password, or external IdP.
- This output does NOT prove client certificate use, but:
  * If user names here match CNs used in client certs from section 2,
    that strongly indicates client certificate-based access for those roles.
- Focus on bindings that grant high-privilege roles (cluster-admin, admin, edit, etc.).

Action:
- Cross-reference the user "name" values here with the client-certificate-based users
  from section 2 and with your identity directory.
- Where those represent human users, plan to migrate them to OIDC-based authentication.

EOF

###############################################################################
# 4. GKE-specific: Check API server authentication configuration (read-only)
###############################################################################
echo "=== 4. GKE API server authn-related flags (read-only view) ==="
echo "NOTE: On managed GKE, API server flags cannot be changed from nodes; this is informational only."
echo "Attempting to show current API server container command/args from kube-system (may be empty on Autopilot/GKE managed masters)..."
kubectl -n kube-system get pod -l component=kube-apiserver -o json 2>/dev/null \
  | jq -r '
    .items[]?
    | {
        name: .metadata.name,
        node: .spec.nodeName,
        command: .spec.containers[0].command,
        args: .spec.containers[0].args
      }
  ' | sed 's/^/  /' || echo "  API server pods are not visible in this cluster (expected for fully managed control plane)."
cat <<'EOF'

Interpretation:
- On GKE, you generally cannot disable client certificate auth for control-plane components.
- This section is NOT about component-to-component auth; it is acceptable and required.
- The CIS requirement is about avoiding client certificates for HUMAN users, not internal components.

EOF

###############################################################################
# 5. Optional: Extract CNs from known client certificates (if accessible)
###############################################################################
echo "=== 5. Optional: Inspect local client certificate files referenced in kubeconfig ==="
echo "Looking for client-certificate file paths in kubeconfig and dumping subjects (CN)..."
CERT_PATHS=$(kubectl config view -o json \
  | jq -r '.users[]?.user."client-certificate" // empty' | sort -u)

if [ -z "$CERT_PATHS" ]; then
  echo "  No client-certificate file paths found in current kubeconfig."
else
  for cert in $CERT_PATHS; do
    if [ -f "$cert" ]; then
      echo "  Certificate: $cert"
      openssl x509 -in "$cert" -noout -subject -issuer || echo "    Failed to read certificate"
    else
      echo "  Certificate path not found on disk: $cert"
    fi
  done
fi

cat <<'EOF'

Interpretation:
- Any certificate whose subject CN / O fields match human identities (e.g., personal names or
  email-like identifiers) indicates client certificate auth in use for users.
- Certificates that clearly represent system identities (e.g., "system:masters", "system:node:*")
  are typically internal and not in scope of this finding.

EOF

###############################################################################
# 6. Summary guidance
###############################################################################
cat <<'EOF'

=== 6. What indicates a PROBLEM (non-compliance with CIS GKE 2.1.1) ===

Flag as needing remediation when you observe ALL of the following:
1. A kubeconfig user entry (section 2) has:
   - "clientCertificate" set to a file path, OR
   - "clientCertificateData" present (INLINE),
   AND that user represents a HUMAN user (engineer, operator, etc.), not a system identity.

2. That user has RoleBindings or ClusterRoleBindings (section 3) granting any meaningful
   Kubernetes permissions (especially cluster-admin/admin/edit/custom high-privilege roles).

3. The certificate subject CN (section 5, where accessible) corresponds to a human identity.

These cases violate the intent of CIS GKE 2.1.1: human users should not authenticate to
the cluster using client certificates because they cannot be revoked reliably.
They should instead be moved to OIDC (or another revocable, central identity mechanism).

This script does NOT implement an automatic fix. Use its output to:
- Inventory all human users currently depending on client certificates.
- Prioritize migration of those users to OIDC-based authentication and update their kubeconfigs.
EOF