Support install approval knobs for rukpak resources

[exdx]

One of the original design goals for the project was to incorporate an "android-style" permission system which would provide visibility into the permissions that a particular resource needed and then approve/deny them as needed, potentially denying the installation altogether. For that to come together, there first needs to be a way to indicate that a particular rukpak resource should only be installed if certain conditions are met, instead of automatically in every case. This mechanism would be similar to the install plan approval mode setting found in OLM, which can be set to automatic or manual.

For example, a Bundle should be installed or a BundleDeployment should create the objects from the Bundle only if a certain field, for example a new field spec.approvalMode is set to Automatic. Automatic could be the default, but users should have the ability to opt-in to another approval mode such as Manual.

[joelanford]

I think we need to be extremely careful about this. Approval is inherently imperative unless approval can be withdrawn. And withdrawing approval sounds fraught both technically and from a user predictability perspective.

From a declarative perspective, isn't approval implicit from the user creating/updating the bundle or bundle deployment object in the first place?

[timflannagan]

Also: what's the actual UX around inspecting Bundle contents, and provisioners that have differing storage backend implementations? In the case of the plain.v0 provisioner, I guess I could query the shared ConfigMaps using label selectors for an individual Bundle, but then I need to script around decoding the encoded Bundle contents to get my answer? Or do I have to find the underlying Bundle unpack Pod, decode the logs and get a YAML stream of objects that way?

How does this process scale for different bundle formats, or when we eventually support different source types, e.g. sourcing local, on-cluster resources in the Bundle API?

Is there the need for a first-class API for providing visibility into Bundle contents here vs. providing knobs for approving Bundle contents before they're installed, or a BundleDeployment pivots to that unpacked Bundle?

[exdx]

From a declarative perspective, isn't approval implicit from the user creating/updating the bundle or bundle deployment object in the first place?

I think that's fair. It gets to the question of who the end user is -- is it only the cluster admin who has permission to create Bundles and BundleDeployments, or can ordinary users (with RBAC permissions) install them as well. I personally think rukpak is more the latter approach, although if everything is now at the cluster scope maybe that doesn't make as much sense.

Is there the need for a first-class API for providing visibility into Bundle contents

There is for sure, it's also something that has been on the roadmap since the beginning. Providing visibility into what's actually in the bundle is doable, I think the plan was to provide this via a kubectl plugin. An easy way to dump the bundle contents from inside the cluster to locally on the machine sounds like a nice thing to have.

I mainly wrote this ticket because I noticed looking at older issues (namely #16) and saw this approval requirement as something that we at some point saw as a priority, so I didn't want to lose track of it. Maybe in this cluster scoped world, with a good bundle surfacing mechanism, it would seem less valuable.

[joelanford]

It gets to the question of who the end user is -- is it only the cluster admin who has permission to create Bundles and BundleDeployments, or can ordinary users (with RBAC permissions) install them as well.

I think from the perspective of designing these specific APIs (and really any arbitrary APIs), the end user is "anyone who has RBAC to manage the API objects" and cluster admins have the ultimate authority to decide who that is.

There's an obvious set of "users" of these APIs: other controllers that are building higher level functionality on top or rukpak (e.g. deppy). I think it's super important to keep these APIs super crisp and simple so that the higher level controllers have a predictable foundation to build upon.

IMO, this approval flow could exist in a higher level API where that controller decides whether or not to lay down the bundle instance based on some knob that exists in that API.

[github-actions]

This issue has become stale because it has been open 60 days with no activity. The maintainers of this repo will remove this label during issue triage or it will be removed automatically after an update. Adding the lifecycle/frozen label will cause this issue to ignore lifecycle events.