Thank you for engaging with each point in detail, @jslarraz — I appreciate the alternatives you suggested. Let me address each one, with concrete data on the ecosystem since you noted you weren’t very familiar with it.
- personal-files / FileChooser portal for cert/key paths
You’re right that for user-initiated file selection these are good options, and I appreciate the suggestion. The reason they don’t fit here is the non-interactive nature of the Kubernetes auth flow:
- personal-files grants access only to paths declared in advance in the snap manifest. Kubeconfig cert/key paths are chosen by the user at runtime (any path under $HOME, /etc/ssl/, corporate mount points, etc.) and cannot be
pre-enumerated.
- The FileChooser portal requires interactive user selection. The app reads certs/keys silently on every list/watch/exec call against the cluster — prompting via a portal on each API call (often many per second on active screens)
would make the app unusable.
That said, I want to emphasise that this file-read side is not actually the most fundamental blocker — even if file access were solved, the execution side (point 3) is the harder constraint.
- “Other-snap binary execution” and desktop-launch
I understand the concern about cross-snap execution being structurally messy — I share that view from a snap-architecture standpoint. The issue is that we do not create this pattern; the Kubernetes ecosystem (including Canonical’s own google-cloud-sdk snap) writes it into the user’s kubeconfig automatically. When a user runs gcloud container clusters get-credentials after installing google-cloud-sdk via snap, the resulting kubeconfig contains:
users:
- user:
exec:
apiVersion: client.authentication.k8s.io/v1beta1
command: /snap/google-cloud-sdk/current/bin/gcloud
args: [config, config-helper, ...]
We consume the user’s existing kubeconfig and cannot rewrite it; if we cannot execute the path it specifies, cluster connection fails.
Regarding desktop-launch: my understanding is that this interface is designed for launching GUI desktop applications, not for invoking a short-lived credential helper as a child process during an API call. Using it for kubectl exec-style credential acquisition would be a semantic mismatch, and it would still need to handle arbitrary paths (point 1) which the interface doesn’t model. Happy to be corrected if I’m misreading the interface.
- Number of exec credential plugins / staging them inside the snap
Thanks for asking — here is concrete data. The set is not small and not bounded:
- Major public plugins already in active use: aws (AWS CLI), gcloud, az, aws-iam-authenticator, gke-gcloud-auth-plugin, doctl (DigitalOcean), ibmcloud, oci (Oracle), linode-cli, plus kubelogin variants for Azure AD / OIDC providers.
- Enterprise-internal scripts: many organisations ship in-house auth wrappers (Vault-based, SAML, custom mTLS) that we cannot anticipate.
- The set grows whenever a new cloud or identity provider releases a kubectl exec helper.
Even setting aside the unbounded list, staging them inside the snap would not actually solve the problem:
a) Each helper needs its own credential state — aws reads ~/.aws/, gcloud reads ~/.config/gcloud/, several read the OS keychain — all outside the snap sandbox. Even with the helper bundled, it cannot reach the user’s cloud credentials.
b) Users with an official cloud-SDK snap installed already have kubeconfigs referencing the snap-installed helper (/snap/google-cloud-sdk/current/bin/gcloud). Shipping our own bundled copy at a different path would be ignored —
kubectl follows what the kubeconfig says.
c) Staging would also pull large platform-dependent cloud CLIs into our snap unnecessarily, and we would have to re-vendor on every cloud SDK release.
- Precedent and supported category
This is the same architectural situation for which kontena-lens ( Classic confinement for kontena-lens ) (another Kubernetes desktop IDE) was granted classic confinement, after the reviwer acknowledged in that thread that “kubernetes authentication helpers are a valid use case for classic.” That use case was subsequently codified as the supported category “kubernetes tools requiring arbitrary authentication agents,” which we are citing.
in that thread that “kubernetes authentication helpers are a valid use case for classic.” That use case was subsequently codified as the supported category “kubernetes tools requiring arbitrary authentication agents,” which we are citing.
If it would help, I’m happy to build a strict-confinement revision and attach snappy-debug output showing the specific denials when connecting to a cluster that uses an exec credential plugin with a /snap/… command path. Please
let me know if that would be useful.
Thanks again for the careful review.
