CC: @reviewers
Snapcraft source is https://github.com/joedborg/kubicorn/blob/master/snap/snapcraft.yaml
I am requesting the automatic connections of
ssh-keys
kube-config
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.
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?
Installation prompts have thus far been avoided, but could be reconsidered. Typically an installation prompt is nothing more than an annoying click-through for the user, which is why on Ubuntu Touch we used contextual prompting instead (which is something that Google also moved towards). That said, we don’t have contextual prompting and the current system is lacking.
I wonder if we could add a new interface attribute: prompt that we could opportunistically use. Ie, we continue to use manual or auto in the normal case, but when we specify prompt, we have snapd prompt in someway. The UX would need to be designed, but in this manner Kubicorn might get prompt for use of ~/.kube (related, but not clear owner) but the foo application might get auto-detection for ~/.foo (obvious owner).
@jdstrand it sounds like we should start by granting installation but not auto-connection, and for sure at a later point we will enforce that the plug is called “kube-config”.
For anything else we need either more experience or further snapd design/work.
+1 to grant installation but not auto-connection.
2 votes for, 0 against granting installation for write access to ~/.kube/config
0 votes for, 2 against granting auto-connection for write access to ~/.kube/config
This is now live.
Note, please remove the ‘read’ portion from your snapcraft.yaml. Also note, there is currently a bug in the review-tools that will cause your snap to fail automatic review still even though the snap declaration was granted. This is fixed and on its way to production and I will manually approve your snap in the meantime.