> For the complete documentation index, see [llms.txt](https://docs.cloudeka.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cloudeka.ai/reference/kubernetes-user-creation-with-rbac/generate-a-kubeconfig-for-the-user.md).

# 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)
```

{% hint style="info" %}
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.
{% endhint %}

**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>
```