Request for auto-connections Kubicorn


CC: @reviewers

Snapcraft source is

I am requesting the automatic connections of


kube-config is a custom plug, but I believe there are several snaps that are classically confined due to not having this workaround so that would make a consideration for a supported interface.


FYI, you only need to specify write with personal-files since it implies read.

It seems that Kubicorn is not the owner of ~/.kube but rather an add-on for managing k8s and the personal-files interface was developed for snaps that have authority on the files specified (eg, firefox could specific $HOME/.mozilla for importing settings). My initial feeling is to grant a snap declaration allowing the installation of Kubicorn, but not auto-connecting it. This gives the opportunity for the snap to be installed and advise the user to take action. What do others think? I’d like to hear what others think before voting on this (esp. @niemeyer and @pedronis, but also others).

As for ssh-keys, this interface grants full access to the user’s sensitive private keys. Since $HOME for snaps defaults to SNAP_USER_DATA and users can copy files down into $SNAP_USER_DATA/.ssh to have ssh work, -1 to auto-connect ssh-keys. I suggest that on startup, the snap discuss either copying individual keys to $SNAP_USER_DATA/.ssh or plugging the interface.


Thanks for the feedback @jdstrand.

I think the read-only plug is the better idea, so I’ll look at that (maybe this should also be built in as the usual use case for SSH keys is to just read them).

I still need convincing regarding the .kube directory. I fear that, by doing that, we’re making classic easier for both the developer (e.g. --classic self documents, plugs do not) and for the end user (more commands to look up and run). I would argue people who install and then execute kubicorn would be fully aware that the kube/config file is going to be mutated. I fully understand the direction in terms of being super explicit for security, but I fear it could also undermine what it’s trying to achieve by being “too complicated” to document and install.


I think there’s a clear cut case with personal-files when a snap manages its own configs.

There’s a less clear case when we have an ecosystem of related tools (but not with one single upstream) that deal with the same pieces of config, the config of the central bit/hub of that ecosystem.

The question is a bit whether there are clear expectations on the part of the person installing the snap what it will touch/have access to, we have also no good mechanism right now to surface this information before installing.

At the moment we are also missing a mechanism that @niemeyer mentioned which is when we grant connection only to a very privileged interface we cannot enforce that the plug name makes it clear what it is about. We discussed having for this slot-names/plug-names constraints in the declaration language.

In the end cargo-culting instructions about connecting things is also not a good outcome.

Kubefwd 'allow-installation' constraint rejection

FYI, kubefwd has the same personal-files request: Kubefwd 'allow-installation' constraint rejection


I agree with all of @pedronis points.

In this particular case, I think read access to ~/.kube is probably understood. The github page says “Create, manage, snapshot, and scale Kubernetes infrastructure in the public cloud.”

I’m far less sure that write access would be understood. Does readonly access make sense for the snap? Ie, in this manner you can import existing data that you don’t own into the snap but then manage it however your want. Perhaps in this scenario we grant use of personal-files for readonly access but don’t auto-connect. In this manner the snap can provide instructions for importing kube configuration.


Well, we don’t have good mechanisms atm for surfacing any plug/slot information before installing AFAIK. Your comment did make me think that perhaps as part of the process for connecting personal-files/system-files, perhaps we could surface the read and write attributes in some way?


To be clear to show something before installing means interrupting the flow as we do for classic, where confirmation then is done by needing --classic to be specified.

Are system/personal-file special enough to warrant this? Do we want a more general mechanism where the snap declaration instead of allowing auto-connection, would instead declare (syntax to be determined) to “prompt” about it at installation?