Fluxctl personal-files [Was: Fluxctl snap wants to be classic]

[jdstrand]

@dholbach

unfortunately, kind clusters can have --name set.
This means that while the files are under the same directory, they have arbitrary names. ( ~/.kube/kind-config-* )

Would this be possible in any way? Can we use * ? Can we add directories to personal-files ?

Yes. Eg:

plugs:
  dot-kube:
    interface: personal-files
    read:
    - $HOME/.kube

which would allow access to the $HOME/.kube file, $HOME/.kube directory and all of its contents.

[dholbach]

Super.

It took me a bit, but I uploaded a version with a bit more generalised permissions to the store now. It should be in the review queue.

[jdstrand]

I adjusted the snap declaration to allow the more generalized $HOME/.kube and $HOME/.minikube since a) this is read access and b) we’ve allowed this with other snaps that need access to ~/.kube. @reviewers - please comment if this is in error.

However, while your snap was granted subsets of ~/.kube and ~/.minikube before (so expanded is warranted, see above), it also added ~/.config/k3d, which is new and not discussed before. Can you describe what this access is for and why you need it?

[dholbach]

Hey Jamie,

this came in from @stealthybox who added support for k3d (k3s in docker, where k3s is “k3s is the lightweight Kubernetes distribution by Rancher”) in this PR.

I realise this looks like it’s becoming a bit of a wild-growth of config files to look at, but it’s what we have to do to support a few varieties of Kubernetes flavours.

Thanks a lot in advance.

Have a great day,
Daniel

[jdstrand]

Hey Daniel,

Ok, thanks for the additional information. ‘dot-kube’ doesn’t really fit with ~/.config/k3d, but it sounds like that is the equivalent of the .kube directory for rancher. I’m going to adjust the snap declaration since, again, this is read access and related. @reviewers - please speak up if you disagree. This is now live.

Have a great day,

You too!

[jdstrand]

@jdstrand

This is now live.

You can either request a manual review for revision 34 or perform another upload and it will pass automated review.

[dholbach]

Unfortunately we will have to move to classic interface. Depending on configuration and use-case fluxctl might need to exec other tools like doctl or aws-iam-authenticator.

As kubectl uses classic too, I guess that’s the way to go?

[alexmurray]

So in summary (@dholbach please correct me if I am wrong) fluxctl requires classic confinement since 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. Therefore, fluxctl requires to be able to run arbitrary binaries from the host, and these may require access to various (unknown in advance) user configuration files, and as such classic confinement is the best fit?

If this is a common pattern amongst kubernetes tools, it sounds like it would be worth having an interface specifically for this kubeconfig access (which provides access to the required configuration files and the ability to launch various helpers from the host file-system) since it seems like we have had a lot of similar classic confinement / personal-files requests for accesses of this sort - @jdstrand @pedronis thoughts?

[alexmurray]

@dholbach - if fluxctl is definitely requesting classic confinement, this would be easier to track etc if you create a separate forum request for this too, thanks.

[dholbach]

Thanks @alexmurray. I moved the request here.