The microstack snap bootstraps the juju controller, create models, deploy bundle files.
During bootstrapping the juju client will write information related to controllers, clouds, credentials etc in $HOME/.local/share/juju folder.
To elaborate a bit more, there’s been a new content interface added to the juju snap that is utilized by the microstack snap. This content interface allows the microstack snap to bootstrap juju controllers and such using the binary, but needs access to the $HOME/.local/share/juju folders in order for the binary to have access and for the users to be able to use the juju command outside of the microstack interface itself.
This has been discussed with the Juju team themselves (cc @wallyworld) and this is a trusted usage and access to this location between the teams.
While we’re at it, we need access to the SSH keys as well. Should we amend this request or file a new one?
Sorry its not that clear regarding SSH keys.
The interface which is required by microstack for autoconnect is ssh-public-keys.
The intention is to import ssh public key to the openstack deployed by microstack as part of initial configuration. This will help users to create VMs using the key imported and ssh into the VMs without specifying the private key explicitly.
I was going to suggest that this dot-kubepersonal-files instance may be better being manually connected (in which case microstack would check if it was present and then knowing that juju would try and access it could then prompt the user to manually connect it if desired) but I don’t think the usual AppArmor policy would allow to test for the presence of it - even that would be denied I think.
So then the question is, does microstack work fine without this access? Can juju simply ignore this error and continue operation? Since I expect users may be surprised to find that microstack has automatic access to this path OOTB. Can you clarify?
Hmm actually after doing some testing it looks like the default AppArmor profile does allow a snap to stat a dot-file in $HOME - so it should be possible to test for the presence of ~/.kube and then prompt for this to be connected in that case. Thoughts?
Microstack will work fine in many cases without this access and in other cases it will cause the bootstrap sequence to fail (e.g. if the ~/.kube path exists ahead of time). As you suggest, it is most certainly possibly to go the route that you have suggested (stat the path and then prompt for connection).
As we’re being quite open about Microstack running the control plane on Kubernetes, I believe that the users of Microstack from the sunbeam (and derivative) channels will expect that Microstack has a legitimate need to have read access to the ~/.kube directory. However, I don’t want to be that guy who pushes for convenience over security because I believe you can have both.
I think for this situation, it would be ideal if there was an in-between state of manual connect vs auto-connect for the interfaces. e.g. an on-demand but confirm with the user prompt provided by snapd. However, I know that’s much more complicated than it sounds on the surface and the proposed solution is approximating that.
How about we split the discussion around read only access to k8s config files from this topic? I’m keen to get the core plugs approved so we can actually resume automated publishing of this snap in the snapstore.
It feels a bit fishy to allow microstack access to juju config files - which might contain sensitive information. The sole link between microstack and juju is that they’re both published by Canonical but that’s about it.
The sunbeam channel of microstack takes a different approach to deployment - rather than everything being provided as part of the snap it integrates with Kubernetes and uses Juju (via a new content interface provided by Juju 3.0) to deploy the control plane for OpenStack on top of MicroK8S.
The snap makes use of the juju binary via the content interface, which in turn needs a subset of the interfaces consumed by the juju snap itself in order to function - being able to write to .local/share/juju is part of this as the microstack snap bootstraps the Juju controller ontop of MicroK8s.
The hypervisor component of the solution is provided by the openstack-hypervisor snap (which in fact has its roots in a subset of the original microstack snap in terms of the interface it require to operate). The microstack snap configures the openstack-hypervisor snap via a content interface as well.
In addition, the microstack snap also consumes the microk8s content interface that provides it with configuration to use with Juju on how to access the Kubernetes cluster it deploys.
As such, microstack is working as an installer to utilise a number of different tools and approaches to deploy an OpenStack cloud rather than being a huge monolithic snap with all of the required binaries.
Our tutorial on using sunbeam might help explain this a little further:
I hope that this explanation helps clarify what we’re endeavouring todo.
I see - Thanks for the explanation. +1 on dot-local-share-juju personal-files based on the above. I wonder if, given that it operates so differently, a different snap (openstack-sunbeam? openstack-installer?) might have been more appropriate, but if this is the future then I think it’s OK to have these interfaces now, even if they do look a little out of place with the old way of the snap’s operation.