Creating a Kubernetes scoped kubeconfig by hand is 15 steps of pain. It shouldn't be.

Samer Aburabie — Sat, 27 Jun 2026 20:54:06 +0000

Handing someone least-privilege access to a Kubernetes cluster means assembling a scoped kubeconfig by hand — ServiceAccount, Role, RoleBinding, token, CA, YAML. Here's the full gauntlet, and how Kubexer collapses it.

A teammate needs to deploy to one namespace. A CI bot needs read-only access to pods and logs. A contractor needs to poke at team-alpha and nothing else.

The right answer is never "here, use my admin kubeconfig." The right answer is a scoped kubeconfig — least privilege, narrow blast radius, easy to revoke. The problem is that creating one by hand is a genuinely tedious ritual that almost nobody enjoys, and that friction is exactly why over-privileged credentials keep leaking into Slack threads and CI secrets.

Let me walk through the full manual process, because the number of moving parts is the whole point.

What "scoped" actually means

A scoped kubeconfig is just a normal kubeconfig whose identity maps to a ServiceAccount that's been granted a tightly-defined Role. Instead of carrying your broad user credentials, it carries a token that can only do the specific verbs on the specific resources in the specific namespace you allowed.

To build one, you need five things to exist and agree with each other: a ServiceAccount, a Role, a RoleBinding, a token, and the cluster's CA + API endpoint. Then you assemble them into a file.

The manual gauntlet

1. Create the ServiceAccount

kubectl create serviceaccount deploy-bot -n team-alpha

2. Write a Role with exactly the permissions you want

This is the part you actually have to think about — every extra verb is extra blast radius.

cat <<EOF | kubectl apply -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: deploy-bot-role
  namespace: team-alpha
rules:
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "watch", "update", "patch"]
  - apiGroups: [""]
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]
EOF

3. Bind the ServiceAccount to the Role

kubectl create rolebinding deploy-bot-binding \
  --role=deploy-bot-role \
  --serviceaccount=team-alpha:deploy-bot \
  -n team-alpha

4. Mint a token — and here's where 1.24 made it worse

Before Kubernetes 1.24, a ServiceAccount automatically got a long-lived token Secret you could just read. Since 1.24 that auto-generation is gone (LegacyServiceAccountTokenNoAutoGeneration). So now you mint one explicitly:

TOKEN=$(kubectl create token deploy-bot -n team-alpha --duration=24h)

But kubectl create token returns a time-bound token. Great for security, annoying for a credential you wanted to hand off once. If you need something longer-lived, you're back to hand-crafting a kubernetes.io/service-account-token Secret — which reintroduces exactly the long-lived-credential risk the 1.24 change was trying to kill. Pick your poison.

5. Extract the cluster CA and API endpoint

The new kubeconfig has to trust the cluster, so you pull the CA and server out of your current config:

CLUSTER_NAME=$(kubectl config view --minify -o jsonpath='{.clusters[0].name}')
SERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}')
kubectl config view --raw --minify \
  -o jsonpath='{.clusters[0].cluster.certificate-authority-data}' \
  | base64 -d > /tmp/ca.crt

Yes — you base64-decode the CA into a temp file, because the next command wants a file path, not inline data. (And then you get to remember to delete that temp file.)

6. Assemble the kubeconfig, one command at a time

KCFG=./deploy-bot.kubeconfig

KUBECONFIG=$KCFG kubectl config set-cluster "$CLUSTER_NAME" \
  --server="$SERVER" \
  --certificate-authority=/tmp/ca.crt \
  --embed-certs=true

KUBECONFIG=$KCFG kubectl config set-credentials deploy-bot \
  --token="$TOKEN"

KUBECONFIG=$KCFG kubectl config set-context deploy-bot \
  --cluster="$CLUSTER_NAME" \
  --user=deploy-bot \
  --namespace=team-alpha

KUBECONFIG=$KCFG kubectl config use-context deploy-bot

7. Test it before you trust it

KUBECONFIG=./deploy-bot.kubeconfig kubectl auth can-i list pods -n team-alpha   # yes
KUBECONFIG=./deploy-bot.kubeconfig kubectl auth can-i delete secrets -n team-alpha  # no, good

Then clean up the temp CA, and distribute the file securely.

Count the ways this goes wrong

That's roughly fifteen discrete actions across four object kinds, two base64 operations, several jsonpath incantations, and a hand-assembled file. Every step is a place to slip:

Over-scoping — it's faster to grant "*" verbs than to enumerate them, so people do, and least privilege quietly dies.
Wrong CA or server — and the config silently fails to connect with a TLS error that tells you nothing useful.
Token expiry surprises — the 24h token works in your test and dies in production overnight.
Leaked temp files — that /tmp/ca.crt and the token in your shell history.
No record — three weeks later, nobody remembers which SAs and Roles exist or why.

None of this is hard, exactly. It's just fiddly, and fiddly-but-security-critical is the worst combination, because the path of least resistance is the insecure one.

How Kubexer collapses it

This is the workflow I wanted to stop doing by hand, so I built it into Kubexer, a privacy-first Kubernetes desktop IDE.

Instead of the gauntlet above, you describe the intent:

Pick the namespace.
Pick the resources and verbs you want to allow (or start from a least-privilege template like "read-only" or "deploy-only").
Set a token lifetime.

Kubexer creates the ServiceAccount, the Role, and the RoleBinding, mints the token, pulls the cluster CA and endpoint straight from your active context, and assembles a ready-to-hand-off kubeconfig — without you touching base64, jsonpath, or a temp file. Because Kubexer is local-first and bring-your-own-key, none of this round-trips through anyone's cloud; it talks to your cluster with your existing context and writes the result to your machine.

What was fifteen careful steps becomes: choose what they can do, get back a scoped kubeconfig you can actually defend in a security review.

If you've ever fat-fingered a CA cert at 6pm or handed out broader access than you meant to because the narrow path was too tedious, this is the itch I was scratching. I'd love feedback from anyone doing multi-team or regulated cluster access — that's the context that shaped it.

Questions about the RBAC mechanics or the kubeconfig assembly are very welcome in the comments.

Check out Kubexer Kubernetes IDE .. it’s a full fledged feature complete Kubernetes IDE and its free with pro features.

DEV Community: Samer Aburabie