Skip to content

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.

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 (the name is the cluster's id in kubelatch):

kubectl config get-contexts
kubectl config use-context <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 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, with the message kubelatch no admite cabeceras Impersonate-* (kubectl --as no está soportado) (kubelatch doesn't support Impersonate-* headers (kubectl --as is not supported)). 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.
  • Cluster or namespace 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.