Auto connect requests for juju

store-requests
1

Hi,

We’re looking to strictly confine the juju snap and need these interfaces auto connected. There’s a few personal files ones outlined below with reasons.

  • lxd (so juju can create lxd containers)
  • ssh-keys (so juju can add the user’s ssh public key to authorized keys on instances it creates)

config-juju is so that the confined snap can access the usual juju config files in the user’s real home directory.

  config-juju:
    interface: personal-files
    write:
      - $HOME/.local/share/juju

cloud-credentials-juju allows juju to read various cloud config files of the user to use the credentials and cloud endpoints therein

  cloud-credentials-juju:
    interface: personal-files
    read:
      - $HOME/.aws
      - $HOME/.azure
      - $HOME/.config
      - $HOME/.kube
      - $HOME/.maasrc
      - $HOME/.oci
      - $HOME/.novarc

config-lxd allows juju to read the user’s lxd config

NB we might be doing something wrong here since we still get a permission denied trying to read $HOME/snap/lxd/current/.config/lxc/config.yaml. Any ideas?

  config-lxd:
    interface: personal-files
    read:
      - $HOME/snap/lxd/current/.config/lxc
      - $HOME/.config/lxc

We use the home interface so that juju can read arbitrary user specified YAML files for adding cloud and credential definitions, storing backups etc. Since this is auto connected on traditional distros, I don’t think there’s a eed to ask for auto connect, right?

Thanks in advance.

2

If all you require is the user’s public keys, you can instead plug ssh-public-keys.

Regarding the various personal-files instances, can these please follow the usual naming convention and instead be named dot-local-share-juju and dot-config/lxc respectively.

For the various cloud credentials, the use of ~/.config grants access to everything there - can this please be slimmed down the whatever particular directories are required under this folder? Also I think for consistency sake these should be split into their own particular personal-files instances. e.g:

  dot-aws:
    interface: personal-files
    read:
      - $HOME/.aws

  dot-azure:
    interface: personal-files
    read:
      - $HOME/.azure

Finally, regarding $HOME/snap/lxd/current/.config/lxc/config.yaml appearing not to work - I suspect the issue will be that current in that path is a symlink, whereas when apparmor sees this access it sees the real path (ie. whatever the actual revision number is that current points to). Unfortunately you can’t use wild-cards in personal-files declarations either - so we can’t grant / specify $HOME/snap/lxd/*/.config/lxc/config.yaml.

In this case, perhaps you could work with the lxd snap developers to move this file into $HOME/snap/lxd/common/.config/lxc/config.yaml - in which case this is a non-symlinked path and that should work. Then we could grant that via personal-files.

As such, +1 from me for auto-connect of ssh-public-keys and lxd for juju as these are required for standard functionality.

Also +1 for use-of and auto-connect of personal-files named dot-local-share-juju for write access to $HOME/.local/share/juju as the juju snap is the clear owner of this path.

Also +1 for use-of and auto-connect of personal-files named dot-config-lxc for read access to $HOME/.config/lxc.

And finally, +1 for use-of but not auto-connect of personal-files name dot-aws etc as outlined above - in general I think these should not be auto-connected since if these are desired by juju you could try and detect if they are connected via snapctl is-connected dot-aws etc within juju at the time that these may be required, and then prompt the user to manually connect these interfaces.

Could other @reviewers please vote?

3

I would say -1 to autoconnect to the cloud config files because the entity/person deploying it might not necessarily want to share these with juju and possibly limit access due to security requirements at their side. I would also suggest splitting them into individual requests.

4

Thanks very much for the thoughtful suggestions; we’ll take up the advice offered. We’ll update this post with the results once implemented and tested.

With the cloud-config files, users of Juju have a clear expectation that Juju is able to read their locally stored cloud credentials. Juju offers an autoload-credentials feature which Just Works to allow the user to out of the box bootstrap to the major public clouds, plus discover local config for Openstack etc so it becomes painless to configure Juju for those as well.

Given that Juju offers these features already since day one (originally via the deb and lately via the classic snap), it would be a big step back in usability to now require the users to take extra steps (once per cloud type) in order to have Juju do what it was designed to do. Given Juju fundamentally needs to operate cloud APIs and needs access to such config and credentials to operate as stated on the shrink wrap, is it unreasonable to think that a user choosing to snap install Juju would not expect this?

5

I’ve re-done the snapcraft config as per Alex’s suggestions

apps:
  juju:
...
    plugs:
      - network
      - ssh-public-keys
      - lxd
      # Needed so that juju can still use the real ~/.local/share/juju.
      - dot-local-share-juju
      # Needed to read lxd config.
      - dot-config-lxd
      # Needed to read ~/.kube, ~/.novarc, ~/.aws etc.
      - dot-aws
      - dot-azure
      - dot-google
      - dot-kubernetes
      - dot-maas
      - dot-openstack
      - dot-oracle
      # Needed so that arbitrary cloud/credential yaml files can be read,
      # backups can be created etc.
      - home

...

plugs:
  dot-local-share-juju:
    interface: personal-files
    write:
      - $HOME/.local/share/juju

  dot-config-lxd:
    interface: personal-files
    read:
      - $HOME/snap/lxd/common/config

  dot-aws:
    interface: personal-files
    read:
      - $HOME/.aws

  dot-azure:
    interface: personal-files
    read:
      - $HOME/.azure

  dot-google:
    interface: personal-files
    read:
      - $HOME/.config/gcloud

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

  dot-maas:
    interface: personal-files
    read:
      - $HOME/.maasrc

  dot-oracle:
    interface: personal-files
    read:
      - $HOME/.oci

  dot-openstack:
    interface: personal-files
    read:
      - $HOME/.novarc
6

Hey @wallyworld,

Apologize for the delay.

+1 from me for auto-connect ssh-public-keys to juju since its clearly required to add the user’s keys to authorized keys on created instances. +2 votes for, 0 votes against, granting auto-connect of ssh-public-keys to juju.

+1 from me as well for use-of and auto-connect of personal-files using the interface reference dot-local-share-juju for write access to $HOME/.local/share/juju as the juju snap is the clear owner of the directory. +2 votes for, 0 votes against, granting auto-connect of personal-files using the interface reference dot-local-share-juju for write access to $HOME/.local/share/juju.

+1 from me as well for use-of and auto-connect of personal-files using the interface reference dot-config-lxc for read access to $HOME/.config/lxc. +2 votes for, 0 votes against. Granting auto-connect of personal-files using the interface reference dot-config-lxc for read access to $HOME/.config/lxc to juju. This is now live. @wallyworld please note that in the snapcraft you shared you did not added the $HOME/.config/lxc directory to dot-config-lxc.

@wallyworld could you solve the issue with reading the $HOME/snap/lxd/current/.config/lxc/config.yaml?

I understand the usability issues with the several cloud config accesses but at this point this already got 2 votes against so I have granted the use but not auto-connect of the several personal-files read access requests: dot-aws, dot-azure, dot-google, dot-kubernetes, dot-maas, dot-oracle and dot-openstack.

7

This is now live. @wallyworld please let us know if you have any issues.

8

Apologies, just realised I never voted on the lxd interface connection - +1 from me for this as this is a standard function for juju.

9

+1 from me as well for auto-connect lxd to juju since its required for juju to create lxd containers. +2 votes for, 0 votes against, granting auto-connect of lxd to juju. This is now live.

10

Thank you for all the work to approve these - there were quite a few and the effort is much appreciated.

1 Like
11

Hi folks,

The strict juju snap is coming along nicely, but I would like to ask to revisit the -1 on connecting the various dot config files by default

      # Needed to read ~/.kube, ~/.novarc, ~/.aws etc.
      - dot-aws
      - dot-azure
      - dot-google
      - dot-kubernetes
      - dot-maas
      - dot-openstack
      - dot-oracle

Without these, users will find the juju client pretty much unusable, and asking them to connect things manually will cause confusion and broken systems.

Juju fundamentally is a tool which creates and manages cloud resources on behalf of the user. For the 11 or more years Juju has existed, it is well known and unambiguous that users need to provide access to their cloud credentials for Juju to function. So there’s nothing surprising happening here - in moving to a strictly confined snap, we need to replicate the behaviour of the classic snap in allowing Juju to read the credentials. We are not asking for access to every config file in a user’s home dir, just the very specific cloud config files Juju has always needed in order to operate as adverised on the shrinkwrap.

It also seems strange to me that the home plug is auto connected allowing access to all sorts of files, but these particular dot files which also exist in the same home dir cannot be read.

In light of this, can we revisit the decision and allow these plugs to be auto connected?

12

Hey @wallyworld,

Thanks for the detailed explanation. Since:

I am +1 for auto-connecting cloud related dot files. Could you please add a note to the snap description explaining this? Can other @reviewers please also vote?

13

Thank you very much. We can definitely add a note to the snap description as requested.

14

+1 from me too - since this is expected behaviour of the juju snap to be able to easily access these configurations.

+2 votes for, 0 votes against, granting auto-connect and use of personal-files as above.

15

@wallyworld one thing I noticed when using the strict juju snap was that when prompted to authenticate via SSO my web browser was not automatically launched:

$ juju machines
Opening an authorization web page in your browser.
If it does not open, please open this URL:
https://api.jujucharms.com/identity/login?did=39e34ebe2767e02809a848ba8599576de5a2381ee303365090edc69e21cb95ed

And the following was seen in dmesg:

[23075.364451] audit: type=1400 audit(1647319168.567:2056): apparmor="DENIED" operation="exec" profile="snap.juju.juju" name="/usr/bin/xdg-open" pid=129252 comm="juju" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0

The juju snap should plug the desktop interface which will allow the use of xdg-open in this case.

16

Hi Alex

Thank you! The desktop plug is now added and I’ve confirm the strict snap now auto connects all the required plugs and works nicely.