Mechanics has always been proud of the kubeconfig files it does not hand out.
But "no cluster credentials" should not mean "no kubectl describe
when a pod misbehaves". Mechanics 0.3.5 threads that needle:
user kubeconfig prints an opt-in, read-only kubeconfig scoped to
one workspace namespace.
ssh -T mechanics.run -- user kubeconfig > kubeconfig.yaml
KUBECONFIG=kubeconfig.yaml kubectl get pods
KUBECONFIG=kubeconfig.yaml kubectl describe deploy myapp-main
KUBECONFIG=kubeconfig.yaml kubectl logs deploy/myapp-mainNo stored token, no local mutation
The printed kubeconfig contains no embedded bearer token. Instead,
kubectl refreshes short-lived credentials through an exec plugin
that calls back over Mechanics SSH. The same key that signed up is the
credential. Mechanics never edits ~/.kube/config. You save the
file explicitly and point KUBECONFIG at it when you want it.
Read and debug, nothing else
The backing RBAC grants reads, watches, and pod logs for the selected namespace
and denies everything that would turn inspection into control: writes, Secrets,
exec, attach, port-forward, RBAC mutation, cluster-scoped resources, and other
namespaces. kubectl auth can-i agrees with the docs, and the e2e
suite proves it stays that way. Deployment still goes through the front door
of app release, and since 0.3.37 native TCP access goes through
audited workspace tunnels rather than pods/portforward.
Repair is part of the contract
Access objects are GitOps-reconciled per workspace, so they can lag or go
missing on older accounts. user kubeconfig wait blocks until they
exist, and user doctor --wait repairs kubeconfig access across
every workspace the account owns, using the same idempotent onboarding path
that runs at signup.
Agents deploy through commands. Humans and agents debug with kubectl: read-only, workspace-scoped, and refreshed over SSH.