Classic confinement for fluxctl

[dholbach]

As discussed in this and its following posts, it is normal practice for users to configure kubeconfig to execute arbitrary helpers for authentication, and it is not feasible to ship all of these within the fluxctl snap itself. For example doctl or aws-iam-authenticator.

https://github.com/fluxcd/flux/pull/2529/files shows the snapcraft.yaml change I’d like to make.

Thanks @alexmurray for taking a look kat the original request.

[jdstrand]

Also note Classic confinement for kontena-lens. This may be a new class of classic request.

[jdstrand]

@dholbach - note that by design snapd supports refreshes from classic to strict but not strict to classic. If granted use of classic, what is your plan for migrating existing fluxctl snap users?

Also, to better under the scope of the request, how many authentication helpers are there? Listed here is doctl and aws-iam-authenticator, while kontena-lens also listed gcloud. What others are there?

cc @pedronis - wondering if maybe these snaps should use snapcraft parts that has the authentication helpers rather than everything needing classic confinement.

[stealthybox]

x-ref:

Classic confinement for kontena-lens

For GKE users, the kubeconfig is modified by the gcloud command. ( I’m using the gcloud snap which also happens to use classic confinement. ) When running gcloud container clusters get-credentials, the resulting kubeconfig sets cmd-path to the path of the binary in use. On my ubuntu system, you can see that this path is set to the full path of my snap gcloud binary: - name: gke_redacted_us-central1-a_test-kubeconfig-1 user: auth-provider: config: cmd-args: config config-h…

---

what is your plan for migrating existing fluxctl snap users?

Good question – this might just be a breaking change?

how many authentication helpers are there?

IMO, it’s infeasible to support every arbitrary auth method. Kubernetes is an open platform meaning every cloud provider, bare-metal vendor, and internal platform team may use their own auth helper for temporary tokens, SAMLv2, kerberos/AD, etc. When new implementations are created, it becomes user-hostile to expect that maintainers and devs would contribute builds of those tools to some central kubeconfig plug.

The security model of kubeconfig does not appear to isolate well unless we can provide users some way to easily mount binaries and directories into a confined snap runtime.

[jdstrand]

Daniel, I apologize for this taking so long. The reasoning is detailed here: Classic confinement for kontena-lens

This application falls into the category of “kubernetes tools requiring arbitrary authentication agents” and therefore the requirements for classic are understood. I’ve vetted the publisher.

Granting use of classic. This is now live.

[dholbach]

Thanks a lot Jamie!

What’s a bit unfortunate is that refreshing from strict to classic is not supported. It will mean that users will be stuck on the old version and we have no way of letting them know, right?

[jdstrand]

@dholbach

What’s a bit unfortunate is that refreshing from strict to classic is not supported. It will mean that users will be stuck on the old version and we have no way of letting them know, right?

That’s correct. I believe the @advocacy team has some techniques to help developers on this.