Kubefwd 'allow-installation' constraint rejection


Just received a rejection and wanted to know what my next steps should be.

kubefwd is a Kubernetes command-line utility similar to kubectl (classic confinement) and uses the kubectl go libraries libs to interact with the Kubernetes API.


kubefwd port-forwards services running in Kubernetes to a developer’s local workstation. Services with names like http://elasticsearch:9200. This requires kubefwd to setup network interfaces and remove entries from /etc/hosts and therefore is not able to be fully confined. I originally submitted kubefwd with classic confinement and was told to use interfaces such as personal-files.

There are over a thousand homebrew users and some people have released scoop (windows), arch and other packages. I would love to see this in the snap store for Ubuntu based Kubernetes developers. Not sure what my next steps are here, or if kubefwd is not an appropriate utility for snap. Is there a process to become a vetted publisher?



This is the same issue as CircleCI Snap Flagged for Manual Review and I’ve adjusted the snap declaration. You may either request a manual review for the failed revision or upload a new revision and it should pass automated review.


I uploaded a new revision as you suggested and it did not pass auto review. Do I need to change something on my end?


I’m sorry, my previous comment was for a different snap. Your issue has to do with the fact that you are plugging the system-files and personal-files interfaces which requires @reviewers to vote and a snap declaration issued.

The snap is currently using this:

    - $HOME/.kube
    - /etc/hosts
    - /etc/hosts

First off, you need only specify ‘write’ if you want read/write but you don’t need to use this at all, simply plugs the network-control interface which, when connected, grants you this access.

As for $HOME/.kube, a related request is being made here:
Request for auto-connections Kubicorn. We need feedback from @pedronis and @niemeyer before proceeding with this request.

Request for auto-connections Kubicorn

I only added the read and write after receiving a permission denied on testing the snap, I then consulted the documentation which showed examples of accessing system files and my local tested began to work.

kubefwd is a development utility and is fairly invasive, probably more invasive than kubectl (which is the official Kubernetes CLI). If kubectl requires classic confinement then probably more so kubefwd, however I understand that is not an option for me.

kubefwd is just a small open source util and I have limited time to spend on it. I may have under estimated my ability to understand how snaps work and the approval process for the inclusion this type of utility.

I’ll remove kubefwd from the snaps store and direct users to alternative installation methods. Thanks for your time and explanation.


Why is classic confinement not an option for you? We have a process Process for reviewing classic confinement snaps that is available to everyone. The first step is that the technical requirements need to be understood. Understand that in Manual Review for Classic Confinement of kubefwd I was making suggestions based on the information given and it seemed like strict mode might work for you (all that was said was “requires access to ~/.kube/config, the /etc/hosts file and full network access to create and bind port forwarders to local loopback IPs.” – that can be covered with strict mode).

Now you say that “if kubectl requires classic confinement then probably more so kubefwd”, which is fine, but we should look into why that is in Manual Review for Classic Confinement of kubefwd. I suggest you discuss the requirements over there and we can move forward.


I am just confused about both processes. I originally assumed I needed classic, then was told I could do it with strict. I followed the documentation for the plug interfaces and uploaded my revision 7 which was auto-rejected, then above was told: “You may either request a manual review for the failed revision or upload a new revision and it should pass automated review.” so I uploaded revision 8 and still get rejected on “system-files” and “personal-files” “due to ‘allow-installation’ constraint”.

I’m not enough of a snap expert to argue for either classic or strict yet I have tried both. I am certainly misunderstanding the process.


@cjimti - the key thing to keep in mind is that both classic and personal-files require an initial approval to use for snaps that are distributed via the public store because both are powerful. The conversations around that approval might be similar but different.

Let’s focus on your comments “kubefwd port-forwards services running in Kubernetes to a developer’s local workstation” which sounds quite different from your later statement “if kubectl requires classic confinement then probably more so kubefwd”: can you describe in sufficient detail some of the accesses that kubefwd needs that require operating outside of a sandbox? Eg, is it expected to modify arbitrary files, execute arbitrary files, install applications, require systemd unit managament, …? Or does it operate on a discrete set of files with discrete functionality?


Actually, these two are not different. Kubefwd replicates some of the functionality of kubectl and extends it quite a bit. Kubefwd does do port-forwarding like kubectl but also sets up local loopback ip addresses and ports matching those in the Kubernetes service, some may even be low port number like 80 and 443, etc.

My reasoning is that if Canonical, who maintains the kubectl snap felt classic is needed for it, then the same would be true for the derivative utility, kubefwd. That is why I originally chose classic confinement because Canonical did for kubectl.

" does it operate on a discrete set of files" - No, users can specify a config file locations, many Kubernetes cluster operators separate their configs and require this feature.

The guidance on classic vs strict and the approval process here has not been clear to me. I have many Ubuntu users of kubefwd that are fine with alternative installs.

Thanks for your time.