Connect to a cluster with a kubeconfig context

A Kubernetes or K3s connection in DevOpsPad points at a kubeconfig file and one of its contexts. Choose the file, pick a context from the list DevOpsPad reads out of it, set a default namespace, then test and save. Both connection types use the same client-go adapter, so everything on this page applies to both.

DevOpsPad reads only context metadata from the file: context names, their clusters and default namespaces. It does not run authentication plugins while listing contexts, and it never returns credentials to the interface.

The Edit connection dialog for a Kubernetes connection, with the kubeconfig file path, a context drop-down showing “west · west-cluster” and the namespace set to staging.

Add the connection

  1. Click New connection in the Explorer (or press ⌘ / Ctrl + N) and choose Kubernetes or K3s.
  2. Enter a Connection name and an Environment label.
  3. In Kubeconfig file, enter the path (for example /Users/you/.kube/config) or click the folder button to pick it. The file picker shows hidden files, so ~/.kube is reachable.
  4. Open Context. Each entry shows context · cluster. DevOpsPad selects the file’s current context by default.
  5. Selecting a context fills Namespace with that context’s default namespace (or default). Change it if needed, or enter * to list across all namespaces. See Choose a namespace.
  6. Click Test connection, then Save connection.

The test lists at most one Pod in the selected namespace. It proves that the API server is reachable, that your credentials work and that you can list Pods there.

Which authentication works

Method in kubeconfig Supported
Bearer token Yes
Client certificate and key Yes
Exec plugin (users[].user.exec, for example cloud CLI helpers) No

Contexts that use an exec plugin are labeled (exec auth unsupported) in the drop-down. Read Why exec-based kubeconfig auth fails for workarounds.

Saving resolves the context

If you save with Current context selected, DevOpsPad writes the real context name into the connection. It also checks that the context exists in the file; if it does not, saving fails with “Kubeconfig context was not found”. Each query tab and history entry keeps the context it was opened with, so switching contexts later does not change what an old tab points at.

Reaching a private API server

If the API server is only reachable from a bastion host, enable Connect through SSH tunnel in the same dialog. The kubeconfig’s CA, client certificate and TLS server name are still used, and proxies from the environment or kubeconfig are bypassed for tunneled requests. See SSH tunnel overview.

Limits

  • One context per connection. Add a second connection for another cluster or context.
  • The kubeconfig file must stay at the saved path. If you move it, edit the connection.
  • Exec-based authentication is not supported yet.

Frequently asked questions

Does DevOpsPad copy my kubeconfig credentials?

No. The connection stores the path to your kubeconfig file and the context name. Tokens and client certificates stay in that file and are never sent to the app's interface.

What happens if I leave the context set to Current context?

When you save, DevOpsPad replaces it with the explicit name of the kubeconfig's current context. Later changes to current-context in the file do not silently move the connection to another cluster.