Comment 10 for bug 2007575

I looked at using the gke gcloud auth plugin (https://github.com/kubernetes/cloud-provider-gcp/tree/master/cmd/gke-gcloud-auth-plugin) which is a static go binary and therefore in theory could be included in the snap to perform the necessary work to create the access token. Sadly, it turns out that this binary is just a fancy wrapper which still calls out to gcloud to do the actual work (which is what juju itself does in 2.9 in the classic snap). I built a strict snap with the gke plugin included to confirm it fails because it tries to call out to gcloud.

There's a third party standalone binary that someone has written
https://github.com/traviswt/gke-auth-plugin

Sadly, the initial experiment with this plugin failed:
executable gke-gcloud-auth-plugin failed with exit code 1

Work would be required to get debugging to see what's wrong. But often 3rd party libs like this continually need to be updated to keep up with upstream api changes. The root cause might be that the plugin tries to access credential files outside the sandbox.

BTW, the lack of a standalone auth plugin is a much complained about issue on various forum, so it's not just us.

For now, we are probably just going to have to ensure the Juju CLI emits a very clear message to instruct users about running the unconfined juju cli when running add-k8s.