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’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.
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.
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.
We seem to be talking in circles. I’m sorry if I’ve been unclear and I’ll try to be more clear. You said that the guidance for classic vs strict and the approval process has not been clear. Let me address that first: there is no clear guidance at this time because every snap is different, but understand the ultimate goal is that if a snap can effectively run in strict mode, it should. The process is essentially you start with one or the other and then make a request for classic or auto-connection (it doesn’t matter which you do, the reviewers will then guide the conversation). At that point, clarifying questions are asked to understand what your application does and what it requires (understand that reviewers don’t know your application like you do! ) and this may or may not lead to recommendations for your snap.
For kubefwd specifically, you stated 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”. We look at each snap on its own and while that statement may help some reviewers understand its capabilities, it isn’t justification in and of itself for classic. From my perspective, I’m still not convinced by the information you put forth that this requires classic (you’ve mentioned network and its configuration, which is covered by existing interfaces, and config files, which is covered by the snap’s writable areas and interfaces like home and removable-media). However, there is a disconnect for me because you have said kubefwd extends kubectl, which needs to do much more than networking and config file operations but you haven’t said clearly (to me at least, sorry if I’m being dense) how.
Does kubefwd provide all the functionality of kubectl? If not, can you list all the functionality that kubefwd provides without assuming reviewers know anything about kubectl or kubefwd (eg, creating and managing pods, etc, etc, etc)?
Thanks, hopefully we can bring this to a close soon
Ok then can we go back to this statement regarding the rejection on strict with personal-files:
How do I get approval for “personal-files”?
kubefwd needs to access the configuration files for kubectl, this is how kubefwd is able to connect to a remote kubernetes cluster, it’s most likely stored in ~/.kube/config, which is a non-confined personal file. However even then the user could have many configuration files and specify which one they would like to use, this is common with kubectl and also with kubefwd, anywhere on their system.
We have since received an answer in the Kubicorn topic which directly applies to this. In an effort to move this forward in a timely manner, I’ll cast two different votes:
+1 to grant installation of personal-files with write access to $HOME/.kube with manual connection since while it is clear that kubefwd should be able to access the files, it isn’t obvious it should have write access to files that it isn’t the clear owner of
+1 to grant installation of personal-files with read access to $HOME/.kube with auto-connection since it is clear that kubefwd should have access to the files
@cjimti - your snap current uses ‘read’ with personal-files which I vote for auto-connecting. Do you prefer write?
@reviewers - can you also vote? Feel free to vote for both as I did and if we vote the same I can issue alternate constraints for the snap.
You misunderstood. If all you need is read, there is nothing else to do. It wasn’t clear to me if you wanted write or not. You have now stated you only want read.
+1 to grant installation of personal-files with read access to $HOME/.kube with auto-connection since it is clear that kubefwd should have access to the files
@cjimti, while the voting process proceeds, please adjust your snap to drop use of system-files and instead plugs ‘network-control’, which grants write access to /etc/hosts (network-control is manually connected so please comment if it should be auto-connected).
Also, we’ve added a new requirement for use of personal-files where the interface reference you use in your snapcraft.yaml must be descriptive for the user to understand what it is granting. As such, please adjust your snap to use:
+1 for auto-connection of personal-files with read to $HOME/.kube - this entirely makes sense and seems logical and probably unsurprising from an end-user perspective.
) and this may or may not lead to recommendations for your snap.