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

Great advice! Thanks, I did not know about this.

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.

@degville - as discussed - we should document this $HOME stuff…


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:


1 Like

Ah, apparently, it still needs review as it uses personal-files.

@dholbach - yes, it does. There is also an additional requirement that the interface reference needs to be something descriptive ( The personal-files interface)

Currently you have:

    - $HOME/.kube/config
    - $HOME/.minikube/client.key
    - $HOME/.minikube/client.crt
    - $HOME/.minikube/ca.crt

This should be chnaged to:

    interface: personal-files
    - $HOME/.kube/config
    - $HOME/.minikube/client.key
    - $HOME/.minikube/client.crt
    - $HOME/.minikube/ca.crt
    - kube-config

+1 for use and auto-connect of personal-files for the above accesses using the ‘kube-config’ interface reference.

@reviewers - can some of you also vote for this?

Reading through, personal-files for accessing ~/.kube and ~/.minikube makes sense to me. I’m +1 on the interface and auto-connection.

Thanks for the reviews and the feedback! I updated the PR and uploaded a new snap with the suggested changes.

2 votes for, 0 against. Granting use of personal-files as described in this topic.

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.

Since we last talked we moved on to https://github.com/fluxcd/flux/blob/master/snap/snapcraft.yaml#L50:L57

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?

Paging @jdstrand and @mvo.

Yes. Eg:

    interface: personal-files
    - $HOME/.kube

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

1 Like


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.

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?

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,

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.

You too! :slight_smile:

1 Like

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

1 Like

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?