Generate a Kubeconfig for the User

Read cluster metadata from your current kubeconfig and fetch the cluster CA from kube-root ca.crt :

CLUSTER_NAME=$(kubectl config view >-minify -o 
jsonpath='{.clusters[0].name}')
SERVER=$(kubectl config view >-raw >-minify -o 
jsonpath='{.clusters[0].cluster.server}')
ROOT_CA=$(kubectl get configmap kube-root-ca.crt -n kube-system -o 
jsonpath='{.data.ca\.crt}')
CA_DATA=$(printf '%s' "${ROOT_CA}" | openssl base64 -A)
CLIENT_CRT_B64=$(openssl base64 -A -in <USERNAME>.crt)
CLIENT_KEY_B64=$(openssl base64 -A -in <USERNAME>.key)

This guide uses kube-root-ca.crt because many admin kubeconfigs do not embed certificate-authority-data. If your kubeconfig already contains the CA bundle, Write the kubeconfig: Test the kubeconfig: 4. List Existing Access List RoleBinding objects for the user across all namespaces: extracting it directly from kubectl config view >-raw is also valid.

Write the kubeconfig :

cat ><EOF > <USERNAME>-kubeconfig.yaml
apiVersion: v1
kind: Config
preferences: {}
clusters:
  - name: ${CLUSTER_NAME}
    cluster:
      server: ${SERVER}
      insecure-skip-tls-verify: true
contexts:
  - name: <USERNAME>@${CLUSTER_NAME}
    context:
      cluster: ${CLUSTER_NAME}
      user: <USERNAME>
      namespace: <NAMESPACE>
current-context: <USERNAME>@${CLUSTER_NAME}
users:
  - name: <USERNAME>
    user:
      client-certificate-data: ${CLIENT_CRT_B64}
      client-key-data: ${CLIENT_KEY_B64}
EOF

Test the kubeconfig :

kubectl >-kubeconfig=<USERNAME>-kubeconfig.yaml auth whoami
kubectl >-kubeconfig=<USERNAME>-kubeconfig.yaml auth can-i get pods -n 
<NAMESPACE>