ClusterDeck
What a context contains
A kubeconfig can define clusters, users, and contexts. A context combines a cluster, a user, and an optional default namespace. kubectl normally uses the current context unless a command-line flag overrides it.
kubectl config get-contexts
kubectl config current-context
kubectl config use-context production-readonly
kubectl auth whoamiUse names that carry operational meaning. production-readonly is harder to confuse than an autogenerated identifier. Names are only labels, however; verify the API server and authenticated identity instead of trusting the label alone.
The default file and KUBECONFIG merging
Without an override, kubectl reads $HOME/.kube/config. The KUBECONFIG environment variable can list several files separated by colons on macOS and Linux. kubectl merges them according to documented rules. The first file to set a particular value or map key wins, which can surprise you when two files reuse a user or context name.
KUBECONFIG="$HOME/.kube/base:$HOME/.kube/customer-a" kubectl config view
KUBECONFIG="$HOME/.kube/base:$HOME/.kube/customer-a" kubectl config get-contextsInspect the effective configuration before relying on a new combination. Avoid committing generated flattened configs to source control.
Relative file paths matter
Kubeconfig entries may refer to client certificates, private keys, certificate authorities, and token files. Relative paths inside a kubeconfig are interpreted relative to that kubeconfig file. Moving only the config file can break authentication or, worse, make it refer to an unintended file with the same relative name.
Keep a config and its referenced files together with restrictive filesystem permissions. If a desktop app imports or copies the configuration, understand whether it also resolves and copies referenced data and where the result is stored.
Treat an unfamiliar kubeconfig like code
The Kubernetes documentation explicitly warns that a malicious kubeconfig can lead to code execution or file exposure. One reason is that user authentication may use an exec plugin, which runs a local command to obtain credentials. Do not open or import a kubeconfig from an untrusted ticket, chat message, or repository without inspection.
Review server addresses, proxy settings, file paths, embedded data, and exec commands. Obtain access files through your organisation's authenticated channel and verify their source.
Separate production identities and permissions
Use Kubernetes RBAC and identity-provider controls to grant only the access needed. A production observation workflow often does not need permission to delete workloads, edit Secrets, or create privileged pods. Separate read-only and administrative identities make intent clearer and reduce the impact of a mistaken context.
Short-lived credentials are preferable when the provider supports them. Know how renewal works before an incident. A token that silently expired can look like a cluster outage; an indefinitely valid token copied across laptops becomes a long-term risk.
Build a preflight habit
Before a write action, confirm the context, namespace, target name, and diff. For high-risk changes, verify the authenticated subject with kubectl auth whoami and check authorization with kubectl auth can-i. Shell prompts can display context, but visual colour alone is not a security boundary.
kubectl auth can-i patch deployment/api -n production
kubectl diff -f deployment.yaml
kubectl apply -f deployment.yamlUsing a Mac desktop client
A client should display the current context and namespace persistently and should not upload credentials unless that is an explicit, documented service feature you want. Clusterdeck has no developer backend. Its folder import checks referenced files stay within the folder you authorize, then stores a private flattened copy inside the app container. It also offers a local read-only mode as an extra accidental-write guard.
That local guard complements rather than replaces Kubernetes RBAC. The API server remains the authority for every request.