Request for human-review for auto-connect of interface 'personal-files' for microstack snap

Hi

This is a request for the auto-connect for MicroStack snap interface “personal-files” for strict confinement.

The personal-files interface is used to have write access to $HOME/.local/share/juju folder that will allow to run juju commands from the snap itself.

snpacraft.yaml for reference: https://github.com/openstack-snaps/snap-microstack/blob/main/snap/snapcraft.yaml#L55-L58

Thanks!

2 Likes

Hello @hemanth, can you classify why write access is required for the juju personal-file? Can it be read-only? Thanks!

Hi

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.

Hope this clarifies. Thanks!

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?

1 Like

@review-team cheeky ping for review - we’d quite like to get this snap installable without --devmode and do a tech preview announcement this week :slight_smile:

No need for a second request - we can do both ssh-keys and personal-files here - but one question - do you need public or private SSH keys?

+1 from me for the use of personal-files named dot-local-share-juju for write access to $HOME/.local/share/juju for microstack.

Regarding ssh-keys you will need to elaborate a bit more on whether this is just public or private keys and what the purpose is.

@alexmurray

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.

1 Like

Excellent - +1 from me for auto-connect of ssh-public-keys for microstack as above.

1 Like

Proving the value of doing random testing on a selection of machines we’ll also need access for the juju binary to kubernetes configuration files - this is read only:

dot-kubernetes:
  interface: personal-files
  read:
    - $HOME/.kube

if a .kube directory is present juju will endeavour to read the config file from it which results in a permission denied.

Please could this be included for auto-connection for the microstack snap.

Thanks

I was going to suggest that this dot-kube personal-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.

Split to .kube discussion to:

I’m also +1 on the ssh-public-keys connections.

  • Daniel

+2 votes for ssh-public-keys - this is now live. @roadmr Can you also vote on the original personal-files request for write to dot-local-share-juju?

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.

I skimmed microstack’s home page and top-level documentation doesn’t mention or detail why microstack needs to run juju - all I found was how to point juju to microstack as a cloud for deployments which doesn’t sound like the same scenario.

@jamespage sorry for the extra trouble, could you please explain a bit more why/how microstack needs to run juju commands against an existing, configured juju environment?

Thanks.

  • Daniel

Hi @roadmr

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 :tm: 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.

  • Daniel

I’ve taken the liberty of setting up the dot-local-share-juju personal-files rule, it’s now live on the store.

  • Daniel
1 Like