kubeconfig: contexts, the merge, and the prod you almost touched
The situation
Init dropped two kubeconfig files in /tmp/kubelings-kubeconfig/:
DIR=/tmp/kubelings-kubeconfig
kubectl config get-contexts --kubeconfig $DIR/main
# CURRENT NAME CLUSTER NAMESPACE
# * prod … default
# staging … kubelings
# dev … dev
kubectl config get-contexts --kubeconfig $DIR/extra
# observability … monitoring
A context is just a named triple: cluster (server + CA) + user
(credentials) + default namespace. The file's current-context decides
where every bare kubectl command lands — and right now it's prod. Every
kubectl delete you type without --context goes to production. This exact
default has starred in several of this course's incident files (Spotify's
cluster deletion began with a terminal pointed at the wrong cluster).
┌───────────────┐
┌──▶│cluster + user │
┌────────────────┐───┘ │ │
│current-context │ └───────────────┘
│ │───┐ ┌──────────────────┐
└────────────────┘ └──▶│default namespace │
│ │
└──────────────────┘
Your task
All against the files in $DIR (leave your real ~/.kube/config alone):
- Switch off prod — make
stagingthe current context of$DIR/main:kubectl config use-context staging --kubeconfig $DIR/main - Merge the teammate's
extrafile into a single self-contained file at$DIR/merged, keeping all four contexts. The merge operator is theKUBECONFIGpath list plus--flatten:KUBECONFIG=$DIR/main:$DIR/extra kubectl config view --flatten > $DIR/merged - Prove the merged file works:
kubectl --kubeconfig $DIR/merged config get-contexts kubectl --kubeconfig $DIR/merged --context=staging get pods
Hint
--flatten matters: plain kubectl config view redacts certificate data
(DATA+OMITTED), and a merged file full of redactions can list contexts but
can't authenticate. --flatten inlines every cert and key so the file stands
alone. Precedence in KUBECONFIG=a:b: first file wins conflicts —
including current-context.
Solution
Fix
DIR=/tmp/kubelings-kubeconfig
kubectl config use-context staging --kubeconfig $DIR/main
KUBECONFIG=$DIR/main:$DIR/extra kubectl config view --flatten > $DIR/merged
kubectl --kubeconfig $DIR/merged --context=staging auth can-i list pods
The mechanics worth remembering
- Merge rules:
KUBECONFIGis a colon-separated list; entries are merged left-to-right, first occurrence of a name wins,current-contextcomes from the first file that sets one.--flatteninlines credentials so the result is portable. use-contextedits the file (current-context:line) — it's per-kubeconfig state, not per-shell. Two terminals sharing a file share the switch.--minifyis the inverse tool: current context only, for handing someone access to exactly one thing.- Namespace in a context is a default, not a boundary —
-nstill overrides it; RBAC is the boundary (M6.1).
Prevention / takeaway
- Never leave
current-contextpointing at prod. Point it at something harmless; make prod access deliberate (--context=prodtyped by hand, a separate file, or a separate terminal profile with its ownKUBECONFIG). - Put the context in your prompt (kube-ps1 or similar) — the cheapest guardrail that has prevented real incidents.
- Rotate the file, not just the cluster: old kubeconfigs are standing
credentials.
kubectl config delete-context+delete-userwhen access ends. - CI systems get minified, flattened, single-context files — never a copy of a human's multi-cluster config.
- Previous lesson
- CNI: who wires the pod, and what breaks when nobody does