We are Velocity Tech, a young startup. In short, the company’s mission is to increase R&D velocity by allowing developers to create on-demand, fully isolated production-like environments in the same easy way they are creating new Git branches.
We’re currently working on our MVP and would like to provide our early adapters with a command-line utility called mprod that allows them to interact with our backend services.
The tool has the following functionality:
Interacts with our backend API
Merges Kubernetes kubeconfig contexts into existing or new ~/.kube/config file (has to be in the user’s real $HOME)
Executes telepresence and kubectl as binaries (we do not supply them as dependencies, by the customer’s request) to open a tunnel to the customer’s Kubernetes cluster.
We’ve attempted to use strict confinement with some interfaces to get some of the functionality working, but I think executing other executables not installed by us is impossible that way. Since even kubectl requires classic confinement to run, we believe that our application should have a classic confinement as well.
Thank you for your time, and let me know what else is needed to progress with this request,
Ilai
Apologies for the delay in reviewing this request. Since mprod is required to execute kubectl or telepresence on the host, this means as the snap currently stands it requires classic confinement.
However, usually the requirement to launch arbitrary host binaries is not a sufficient reason to be granted classic confinement as per Process for reviewing classic confinement snaps - can you explain more why you can’t ship these binaries inside the mprod snap?
Although we do have a category for classic confinement regarding kubernetes tools that require arbitrary authentication agents - however it is not clear to me that mprod fits into this - can you provide more details on how mprod authenticates etc?
can you explain more why you can’t ship these binaries inside the mprod snap?
As we try to keep mprod as transparent as possible for the customer (not installing anything in the background without his knowledge), we do not want to supply common dependencies that might collide with how the customer is already using them (change in kubectl or telepresence versions). Also, installing telepresence is a bit of a hassle, and we prefer that the customer will install them first on its own if he doesn’t have it already.
can you provide more details on how mprod authenticates etc?
The customer is granted access via SSO initialized from mprod auth login with supported IDPs (currently only Google). Without this access, the customer cannot work with our service.
