Auto connect request for juju

Hi,

We have recently added a new interface to access minikube’s env configuration on the personal files (see https://github.com/juju/juju/pull/16844) to Juju’s snacpcraft.yaml:

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

Could we get this auto connected? I think there’s the need for some manual security validation.

Thanks in advance

+1 from me for auto-connect of dot-minikube for the juju snap.

Looking at the associated Launchpad bug report there seems to be a genuine need for this use-case. Given the snap is not the owner of this path though, read access seems most appropriate.

However, on the question of auto-connect - can you describe which data is being access from this folder by juju? Since I expect it may potentially contain secrets or other things and so perhaps it is best that this is manually connected by the user when they know they wish to use juju with minikube? Thanks.

Hi, and sorry for coming back to you this late.

So, juju will need at least the CA cert, but we might be using something else (maybe @wallyworld or @hpidcock can provide more info):

$ juju add-k8s m
ERROR detecting clouds for provider "kubernetes": detecting local kube config clouds: getting cluster CA data: open /home/nicolas/.minikube/ca.crt: permission denied

Indeed in ~/.minikube there will be secrets but this is the same case as for ~/.aws for example, which juju already reads and gets auto connected. Since juju users do not have to manually connect the personal config files for other clouds, IMO doing it only in the case of minikube seems confusing. Do you think it’s a bad idea?

Thanks

I think there is a good argument that auto-connecting ~/.minikube is most likely (like with microk8s) to be used for local-development.

Juju itself does not directly know about ~/.minikube, but it is through ~/.kube/config that is configured by minikube. Minikube inserts a user and cluster stanza into the ~/.kube/config file that use paths (under ~/.minikube) for the cluster certificate-authority and the user client-certificate +client-key.

Example paths are:

  • ~/.minikube/ca.crt
  • ~/.minikube/profiles/minikube/client.crt
  • ~/.minikube/profiles/minikube/client.key

NOTE: the profiles sub-directory can contain many different minikube profiles, i.e. the user can create many local minikube clusters, and use any one of them, default is just the default profile name.

Hi

As @alexmurray said we must be very cautious when granting access to folders that are not clearly owned by the snap, specially if they contain secrets. However, I think that users should expect that juju , as a orchestration engine, has access to the secrets required to authenticate against the different supported infrastructures/clouds.

Thus, I’ll be happy (+1 from me) to support the request for auto-connection for the following directories

  • ~/.minikube/ca.crt
  • ~/.minikube/profiles

If we can limit the access to:

I think its ideal so we reduce the access scope while allowing juju to properly operate. @nvinuesa do you think this is enough or there might be further files/folders inside $HOME/.minikube that juju might require?

I just tested locally, with a minikube installed and indeed only the paths

  • ~/.minikube/ca.crt
  • ~/.minikube/profiles (directory)

are required.

Can we split these then for naming consistency?

+1 from me for auto-connect with read access to ~/.minikube/ca.crt named dot-minikube-cacrt and a second interface with read access to ~/.minikube/profiles named dot-minikube-profiles.

sure! I’ll create both interfaces separately. Thanks!

What are the next steps? Can I safely update our snap? (it will be built automatically by jenkins so I want to be sure so we avoid getting blocked by the store)

Until this request is granted, new uploads to the store which declare such a personal-files interface will be blocked (as the current revisions are anyway) - so feel free to change this on your side and once the request is granted it will then pass automated review.