Request for personal-files confinement for kafkactl snap

[dwi-di]

Hey everyone,

I would like to request classic confinement for the kafkactl snap.

Up to now we were quite happy using strict confinement, but our latest release includes the ability to run kafkactl with a kubernetes cluster configured.
This utilizes kubectl run to deploy kafkactl container in kubernetes. This is described in more detail here: https://github.com/deviceinsight/kafkactl/blob/master/README.md#running-in-kubernetes

This does not work currently for the snap package since access to kubectl executable is prohibited.
It is also not possible to include kubectl in our snap because the kubectl version needed, depends on the version of the kubernetes cluster.

We therefore see classic confinement as the only option for our snap package.

– UPDATE: –

This thread is no longer about classic confinement but we need personal-files access to the following:

• ~/.kube folder since this is where kubectl places its config files. we need access to talk to kafka clusters running in kubernetes.
• ~/.config/kafkactl/config.yml which is the default location for the kafkactl config. this location should be consistent regardless how kafkactl was installed

[emitorino]

Hey @dwi-di,

If you take a look at our Process for reviewing classic confinement snaps, the need of running kubectl is not enough for this request to be accepted (it falls under the unsupported category). If you need to support several kubectl versions, you could either a) ship them all in your snap, and then decide which one to use at runtime b) make use of snap tracks. Would either of these two options work for kafkactl?

Please remember classic snaps are not installable on Ubuntu Core devices and also run in the global mount namespace, which means great care must be taken for the snap to work reliably across distributions.

[galgalesh]

@emitorino

From what I understand, kubectl is a "kubernetes tools requiring arbitrary authentication agents ", so wouldn’t any app which includes it fall under this supported reason for classic confinement?

[dwi-di]

Hey @emitorino,
I thought that the snap package for helm has a similar requirement and uses classic confinement, but I searched the forum and found at least those two requests that are similar to mine:

Request for classic Confinement for Linkerd

Hi, Linkerd is a tool for Kubernetes, that relies on kubectl and its config which lives under ~/.kube, thus the need for classic confinement. For reference, I found this discussion about the same request for Helm, which also relies on kubectl. Thanks in advance!

Helmfile: Classic Confinement?

Hi, I’m trying to build a snap for https://github.com/roboll/helmfile This in theory is pretty easy because it’s just a static binary but I think it might need Classic confinement, much like the snap for Helm itself. However I’m new to building snaps so I’m happy to be told I’m wrong. From my understanding of the tool it needs access to yaml files in the directory you run the command in. It also needs permissions to run Helm. It may also need additional access to hidden directories storing He…

There it is stated that classic confinement for helm was granted some years ago and things are different now.

I gave this some thought and I can probably live without classic but I will need access ~/.kube/ folder in order to read kubectl configs from the default location. For that I would need personal files interfaces.

What do I need to do for that?

While I’m already at it, can I also get access to ~/.config/kafkactl which is the xdg config dir for kafkactl and where people usually expect the config to be.

Thanks for your help.

[emitorino]

Hey @dwi-di,

Here you have an example of how your yaml should look like for read access to $HOME/.kube and other example to request access to ~/.config/kafkactl.

Please update the request title/info so it follows under the correct category of our queue.

Thanks!

[emitorino]

Hey @galgalesh,

Even though we have such category for granting classic, it is not exactly the situation for kafkactl. Their need is related to getting access to $HOME/.kube which is possible with strict confinement and the use of the personal-files interface.

Thanks as always for your active participation in this forum!

[emitorino]

Hey @dwi-di,

Could you analyze the alternatives suggested? Thanks!

[dwi-di]

Hey @emitorino,

sorry for being unresponsive. I’m working on the corresponding code changes and hopefully the new version can be submitted mid of next week.
I will then update the title/info accordingly.

[alexmurray]

@dwi-di I notice the snapcraft.yaml has a few issues - can you please change it as follows:

apps:
  kafkactl:
    command: kafkactl
    plugs:
    - home
    - network
    - dot-kube
    - config-kafkactl 
    completer: kafkactl-completion.bash
plugs:
  dot-kube:
    interface: personal-files
    read:
    - $HOME/.kube
  config-kafkactl:
    interface: personal-files
    write:
    - $HOME/.config/kafkactl/config.yml

ie. there should be 2 separate personal-files instances. Also write also grants read so there is no need for both, and finally each personal-files instance should be named descriptively so it is clear what the access is providing.

[dwi-di]

@alexmurray I published an updated version with the changes you mentioned.

[alexmurray]

Thanks @dwi-di - +1 from me for the use of and auto-connect of personal-files for dot-kube and config-kafkactl as listed above. Can other @reviewers please vote too?

[dwi-di]

@alexmurray how long does this usually take until enough @reviewers have voted?

[emitorino]

+1 for the use of and personal-files using dot-kube and config-kafkactl interfaces.

@dwi-di: Our voting period is usually one week, apologize for the delay. You can see the process details here. Also, are you requesting auto-connection for this interface as well? I don’t see you have asked for it.

Thanks!

[emitorino]

+2 votes for, 0 votes against, granting use of personal-files to kafkactl. This is now live.

[dwi-di]

@emitorino If I understand correctly, with this being live now the user still has to manually connect the interface with:

snap connect kafkactl:dot-kube
snap connect kafkactl:config-kafkactl

Since the configurations in these folder are vital for application work I would also like to request the auto-connection of the interfaces.
I’m sorry but I did not know about this feature beforehand. Can this additional request just be handled in this thread?

[emitorino]

@dwi-di you are correct, the previous live revision required the user to manually connect the interface. Since you have explained this requirement is vital for the snap to work, I am +1 on auto-connecting personal-files using dot-kube and config-kafkactl interface references.

+2 votes for, 0 votes against, granting auto-connect of personal-files to kafkactl. This is now live.

[dwi-di]

@emitorino I’m sorry to bother you with this, but I don’t get how this is supposed to work now:
According to the docs the config.yml should now be mounted to $SNAP_USER_DATA/.config/kafkactl/config.yml but when I do the following:

1. Create a fresh ubuntu 20.04 server VM
2. create a file ~/.config/kafkactl/config.yml
3. install kafkactl sudo snap install kafkactl
4. then I expected this to return something:

$ sudo snap run --shell kafkactl
$ ls -lah $SNAP_USER_DATA

But there is nothing in there. What am I doing wrong?

[ijohnson]

@dwi-di

$ ls -lah $SNAP_USER_DATA

$SNAP_USER_DATA will be something like /home/you/snap/kafkactl/current/, so you need to use something like $SNAP_REAL_HOME instead

[emitorino]

@dwi-di apologize for the very late response. Could you solve your issue?

As @ijohnson mentioned, $SNAP_USER_DATA is the per-user writable area for a particular revision of the snap (in this case something like /home/you/snap/kafkactl/current). And $HOME is set to $SNAP_USER_DATA for all commands.

You can find further documentation about the personal-files interface here. The Security policy and sandboxing documentation is very helpful as well to get a further understanding of confinement, policies, env setup, etc.

Let us know if you have any further question!