Hi fellows!
Any news about that?
Mine’s been open for two weeks now 
Apologies for the delays in responding to store requests - with the recent release of Ubuntu 22.04 LTS and then preparations for, and now the attendance at an in-person sprint event all this week the @reviewers team has not been able to get to all requests in a timely fashion. We hope to get back to the usual 7-day response window in the coming weeks. Thanks for your patience.
Any news about that?
Hey @mhalano, apologize for the long delay.
So iiuc, the issue here is the location of the credentials file which could be anywhere on the system. In this case, credential files should be stored in expected locations in normal installations. You could plug home, personal-files, system-files and even system-backup (which provides access to the hostf) without really needing the unrestricted accesses that classic provides.
Please remember that classic confinement effectively grants device ownership to the snap, and classic snaps run in the global mount namespace, which means great care must be taken for the snap to work reliably across distributions.
Hi @emitorino,
The problem is: the credential files are user defined, not automatically installed. Let me show you some lines from my ~/.kube/config for Minikube (which adds the line automagically):
I know I can provide access to home files, but AFAIK the dotfiles are excluded. There is a way to add all dotfiles (.minikube, .kube and so on so forth)?
@emitorino, I think I was able to create a workaround. I add these two plugs:
Doing this, I can read all files in /home and /root (where credentials probably are) and write just in ~/.kube.
I want to clarify I need the write permission for all ~/.kube directory because, apart config file, there are some other files created by the tools used to remember certain values (previous cluster and previous namespace to be exactly).
I think it’s hideous solution, but it is a solution anyway. What do you think?
Hey @mhalano,
I see you could make this work but… that’s not exactly correct. Are you plugging home? It should give you access to non-hidden files owned by the user in the user’s home ($HOME) directory as well as access to /root.
Any other hidden file needed should be added as part of the personal-files iface as you did for .kube
The problem is: I need access to read all dotfiles since I don’t have how to know where the user has saved the credentials. For Minikube is .minikube, but for other applications? So maybe classic confinement still be a better and cleaner option.
Whilst this request looks very similar to historical requests such as Classic confinement for fluxctl and Classic confinement for kontena-lens - I notice one particular difference - those required access to execute arbitrary binaries to authenticate - whereas in this case we seem to only need to perhaps read various files.
As such, if these are always common paths which are used (as was the case with Fluxctl personal-files [Was: Fluxctl snap wants to be classic]) then I think personal-files would be appropriate - since it allows to declare just access to these specific paths and be granted those and still then retain the benefits of isolation from the rest of the system.
@mhalano since it looks like these paths are always in the same sorts of locations (ie. ~/.minikube etc) then I think this would be more appropriate.
@alexmurray I read the discussions you mentioned, and it’s the exactly same problem.
I didn’t consider you could use commands to authenticate, just external files with credentials, but yes, you could use a command which will return the credentials too. The problem is the same: what files I need to read/execute to authenticate correctly? The answer is: it is impossible to know exactly.
I just know my commands kubectx and, more important, kubens, need to authenticate with the Kubernetes cluster, as same kontena-lens and fluxctl do.
And one additional information about the non-executable files with credentials: they could be anywhere. ~/.minikube it was just an example of one application besides kubectl itself. fluxctl indicates another case as I can see (k3d), and the list just go on. It’s impossible to map all the applications.
Here is also a perfect explanation, mentioning the commands and the files with credentials (I just mentioned the files). The case is the same, as it is an “app that needs to use kubeconfig”.
Any news about that? We have in the past another thread by the former maintainer about the use of personal-files auto-connection vs. classic confinement. The thread is here:
@linuxhintbd I think I was able to explain where is the problem more clearly, and also we have now the examples from fluxctl and kontena-lens. I think it will be enough for the use of classic confinement to be approved, and I will be able to publish the snap in no time after that.
@mhalano thanks for the extra info - the requirements for classic confinement for kubectx are understood. @advocacy could you please perform publisher vetting? Thanks.
@Igor The official webpage is https://github.com/ahmetb/kubectx
I’m working on this PR: https://github.com/ahmetb/kubectx/pull/353
+1 from me, I verified the publisher.
1 Like
Thanks @Igor - classic confinement override for kubectx has now been granted - this is now live.
1 Like
Thank you everyone. I already made the final PR so the project can generate the Snap assets and I want to work in the future with the developer of kubectx to create a pipeline so we always get a fresh version of the app together with the release.