kubectl, k9s, Lens and Helm¶

How to use your kubelatch kubeconfig with the usual tools, and what doesn't work through the proxy.

Before you start¶

You need an issued credential (see Get a credential) and its kubeconfig saved in a file of its own, never in ~/.kube/config.

With the kubelatch CLI you don't handle a token at all: kubelatch login writes a kubeconfig whose contexts get their token from the CLI.

kubectl¶

Point KUBECONFIG at your file, or use --kubeconfig on each command:

export KUBECONFIG=~/.kube/kubelatch.yaml
kubectl get pods -n <namespace>

If the credential includes several clusters, each one is a separate context, named kubelatch-<id> after the cluster's id in kubelatch, in a downloaded kubeconfig and with the CLI alike (a downloaded one starts on the first):

kubectl config get-contexts
kubectl config use-context kubelatch-<cluster-id>

Commands that depend on a long-lived connection work the same as against a direct cluster:

kubectl exec -it <pod> -- sh              # interactive exec
kubectl logs -f <pod>                     # log streaming
kubectl port-forward pod/<pod> 8080:80    # port-forward
kubectl cp <pod>:/path/file ./file        # cp
kubectl get pods -w                       # watch

Check your identity¶

kubectl auth whoami

Shows your user as the cluster sees it through the proxy: user:<your-login> if you're a person (whether you sign in with your company account, GitHub or a password; the prefix doesn't change) or bot:<name> if it's a bot's credential. The group list includes one for every active permission, in the form kubelatch:ns:<namespace>:<tier> or kubelatch:cluster:<tier> for a permission over the whole cluster.

k9s and Lens¶

Both read KUBECONFIG or a kubeconfig file you point them to, same as kubectl; they need no special configuration. Open k9s with k9s --kubeconfig ~/.kube/kubelatch.yaml or add the file to Lens's clusters. Everything they do (listing, editing, exec, logs, port-forward) goes through the same proxy and is audited just the same.

Helm¶

Helm uses the same kubeconfig with nothing special:

helm --kubeconfig ~/.kube/kubelatch.yaml list -n <namespace>
helm --kubeconfig ~/.kube/kubelatch.yaml install <release> <chart> -n <namespace>

A helm install/upgrade in practice needs the developer tier (or higher) on the namespace, because it creates and modifies objects.

What doesn't work¶

Impersonation with --as or --as-group: kubelatch answers 400 to any request with Impersonate-* headers. You already act as your own user; you can't act as someone else.
Anything outside your permissions: a verb, resource or namespace your tier doesn't cover answers 403 Forbidden, same as ordinary Kubernetes RBAC.
A cluster with no active permission: if you have no permission currently valid on that cluster, the response is 403 explaining that you have no active permissions there.

Long streams and revocation¶

An open exec, logs -f, port-forward or watch is cut off if your credential or permission is revoked: see Expiry and revocation.

If something doesn't work as you expect, continue to If something fails.