Classic confinement request for `mprod`

store-requests
#1

Hi guys,

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

#2

Hey there @emitorino :slight_smile:

Just wanted to ping about this, we had to send the binary to the customer today, we want to be able to let him install it via snap ^^

Thanks, Ilai

#3

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?

#4

Hey @alexmurray,
Thanks a lot for replying!

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.

Waiting for your reply,
Thanks again,
Ilai

#5

Ok so based on the above mprod appears to require arbitrary authentication agents and so would fit in that category for classic confinement.

The requirements for classic confinement are understood, @advocacy could you please perform publisher vetting?

#6

Thank you very much, @alexmurray! We can’t wait to have support via snap :star_struck:

1 Like
#7

@ilai-velocity Is there a contact email/project page for velocity.tech?

#8

Hi there, @Igor!

We’re working on our project page (branding is WIP ^^). Regarding the contact email, that should be accounts@velocity.tech

Also, I would like to transfer ownership of the snap from my email to accounts@velocity.tech. How can we get this done?

Thanks, Ilai

#9

+1 from me, I verified the publisher.

#10

As requirements were understood and publisher was verified, I am granting use of classic. This is now live.

#11

@roadmr could you please help with this ownership transfer request. Thanks!