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.keyNOTE: 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/profilesIf 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.
+3 votes for, 0 votes against, granting auto-connect of interface dot-minikube-cacrt and dot-minikube-profiles to snap juju.
@nvinuesa - Let me know once the snap with the interface adjustments @alexmurray mentioned is uploaded to the store and I will go ahead and approve.
FYI - it will initially come up as blocked but then I’ll test and update the config which will re-run review tools and should approve the revision.
Sorry for my late response, I didn’t get the notifications. The issue we have is that we publish the snap to the store during release, and if it gets blocked, it will block our jenkins jobs and create a queue. We can publish the first one by hand, and if it gets rapidly approved on your side it shouldn’t be a problem. I’ll ping you when it’s uploaded.
Since we have the enough votes, I have granted the requested auto-connections. @nvinuesa if you upload a new revision with the snap requesting these accesses, automated review should pass and the jenkins jobs should not be blocked. Let us know if there is any issue. Thanks!
@emitorino @alexmurray I’ve merged the PR on our end, but the snap publish job during our release got blocked by:
human review required due to 'allow-installation' constraint (plug-names) declaration-snap-v2_plugs_installation (dot-minikube-cacrt, personal-files)
human review required due to 'allow-installation' constraint (plug-names) declaration-snap-v2_plugs_installation (dot-minikube-profiles, personal-files)
So we had to rollback again.
Apologize, I have checked that I granted the auto-connection declaration but missed the installation one. I have updated it now and tested with the available/failing build artifact and I see it works/passes automated review.
Can you please try again and let me know if everything works now?
Thanks!