This is where I’m stuck now and I’m not sure if $HOME did not work in snapcraft.yaml, or if it’s a separate issue.
[pid 11850] newfstatat(AT_FDCWD, "/home/daniel/snap/fluxctl/x2/.kube/config", 0xc0000ff078, 0) = -1 ENOENT (No such file or directory)
[pid 11850] newfstatat(AT_FDCWD, "/home/daniel/snap/fluxctl/x2/.kube/.kubeconfig", 0xc0000ff148, 0) = -1 ENOENT (No such file or directory)
[pid 11850] openat(AT_FDCWD, "/home/daniel/snap/fluxctl/x2/.kube/config", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid 11850] newfstatat(AT_FDCWD, "/var/run/secrets/kubernetes.io/serviceaccount/token", 0xc0000ff218, 0) = -1 ENOENT (No such file or directory)
[pid 11850] write(2, "Error: Could not load kubernetes"..., 111Error: Could not load kubernetes configuration file: invalid configuration: no configuration has been provided
) = 111
[pid 11850] write(2, "Run 'fluxctl identity --help' fo"..., 41Run 'fluxctl identity --help' for usage.
When a snap starts, $HOME is set to ~/snap/<snap name>/<current snap revision> and fluxctl is apparently looking at $HOME (like a good snap should ;).
Since you actually want to know about the real home, you can adjust your snap accordingly. You can find the user’s home with: getent passwd $(id -un) | cut -d ':' -f 6.
Thanks @jdstrand again. This request can be closed. I’ve got it working (after quite a few round-trips). If anyone is going to look for example code in the future, it’s here:
@dholbach - yes, it does. There is also an additional requirement that the interface reference needs to be something descriptive ( The personal-files interface)
FYI, I’ve approved r4 of the snap but you’ll need to release it to a channel. The snap will need to be manually approved until the review-tools change allowing the use of the kube-config interface reference is in production.
A colleague of mine wants to extend this and let me know that:
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?
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?
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.
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.
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?
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?