I would like to request the classic confinement for my ‘kubectx’ snap. I did a mistake when I was developing it (I had the regular binaries in ~/bin, and I didn’t notice) so some grave errors passed by me.
I will show the error:
The question here is kubectx command just operate with ~/.kube/config file, since it just list and select what is the current cluster. But que kubens command is a lot more dynamic: it does a real request for the cluster do get what are the available namespaces (so naturally take a while every time).
If the credential was only inside ~/.kube/config it would be fine, but as the image shows, the credentials file can be anywhere in the system (in my case is under ~/.minikube). So it’s virtually impossible to know where the credentials are.
It also fixes a small limitation: the kube config file must be ~/.kube/config. With classic confinment, can be anywhere.
I think the code it’s very small so a developer could do an additional review if want and since use must agree with classic confinement or no business done, I think it would be quite safe to allow classic confinement. But I’m no expert.
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: Request for classic confinement: kubectx
I think I was able to be a little more specific about why the classic confinement is necessary.
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.
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.
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):
For this application, the path is clear, but the values can be anywhere and add by an application like Minikube or by user itself. We just can’t (even if we want) assume where the user (or application) will add the credentials (or even the kubeconfig file itself, which I need to read and write too).
I could live if I was able to access user’s home dir with all dotfiles. It will cover most use cases.
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?
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.
