Classic confinment for kubectx snap

store-requests
#1

Hi!

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:

image
image1263×201 32.8 KB
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.

What are you thoughts?

#2

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.

Request for classic confinement: kubectx
#3

@alexmurray Do you have any timeframe for that kind of request? (I tagged you because you seem very active in this approval questions)

#4

Hi fellows!

Any news about that?

#5

Mine’s been open for two weeks now :frowning:

#6

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.

#7

Any news about that?

#8

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.

#9

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):

image
image728×122 4.69 KB
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)?

#10

@emitorino, I think I was able to create a workaround. I add these two plugs: image

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?

#11

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

#12

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.

#13

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.

#14

@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.

image
image709×169 14.2 KB

#15

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”.

image
image812×401 52.2 KB

#16

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:

#17

@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.

#18

@mhalano thanks for the extra info - the requirements for classic confinement for kubectx are understood. @advocacy could you please perform publisher vetting? Thanks.

#19

@mhalano What is the official page for kubectx?

#20

@Igor The official webpage is https://github.com/ahmetb/kubectx

I’m working on this PR: https://github.com/ahmetb/kubectx/pull/353