Add security mechanism for rukpak installations

[exdx]

Currently rukpak components have * permissions and are able to install any arbitrary content on the cluster. This is a very wide set of privileges that can result in a BD installing or modifying potentially anything on the cluster. Some users, particularly those working in more high-security cluster environments, would naturally want a way to limit the set of permissions granted to objects installed with rukpak. The upstream community would also be interested in some kind of built-in security, as Tiller in Helm v2 was considered a potential security risk. The ideal solution would enable to users to install arbitrary resources but allow there to be safeguards, or limitations, in place that can potentially block a resource from installing based on some other configured property or API.

The following are some options to build security into rukpak:

• Inspect the set of permissions/objects that an installation needs and enable an approve/deny workflow (which was proposed originally in the strawman). This is imperative but intuitive.
• Ensure that every BundleDeployment has to have a configured serviceaccount that rukpak will use to install it. Ensure that a user can create/edit a bundle deployment if their permissions are a superset of the serviceaccount's permissions. This adds some complexity to the UX of interacting with rukpak but provides a mechanism to limit the permissions granted to resources installed by rukpak.
• Other, layered security mechanisms that could be implemented on top of the existing APIs (leveraging a solution like combo for example).

Alternatively, there could be a solution where rukpak is left as-is (with * permissions and no safeguards around what is installed) and the expectation would be a higher-level API, which is designed to work with rukpak, has the relevant security privileges backed into it. RBAC for rukpak resources with then be limited to cluster-admins only.

[github-actions[bot]]

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.