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
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.
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?
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:
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.
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!
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.
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.
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?
+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.
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?
@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.
@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:
Create a fresh ubuntu 20.04 server VM
create a file ~/.config/kafkactl/config.yml
install kafkactl sudo snap install kafkactl
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?
@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.