Enabling custom actions to create new k8s resources

[reggie-k]

Summary

Currently, custom actions are only updating the resource they are acting upon.
There is a need for them to be able to create new resources as well.

Motivation

#4116

Proposal

Custom actions will have the ability to return either a list of resources with an operation type to perform for each (just create, currently), or just a single resource, for backward compatibility.
It would be nice to have the ability to use yaml manifests/template files in Lua actions, but if io library is not considered safe for the use case, the Lua script will construct the yaml inline.

Lua libraries are of a limited use from security reasons.
So the actual creation of the new resources will have to be outside of Lua.

A permission check will have to take place, to ensure the NEW resources are allowed to be created for this app.
For example: if the custom action operates on a CronJob resource, and creates a new Job resource, the permission to create a Job resource kind has to be granted on Project level, either implicitly or explicitly.
If the user is rbac-allowed to invoke the action, the action can still FAIL upon invocation if no resource permissions are granted.

The operations that can be performed on resources, returned from Lua scripts, will be only "create" at this point.

Creating the new resource(s) will happen in the same component that currently performs the kubectl patch, resulting from the Lua action - the API Server.

Issues to decide on

• Is there a use case to support also an "update" operation? If so, the "update" operation will require an additional check that the resource the action is performed on is the same resource the action is updating.
  Updating another resource will not be supported at this point because of security considerations.
  There are semantycs around update and patch - the current actions return a resource in an update format, but actually a kubectl patch is performed.
  Do we want to support an explicit "patch" operation in addition, so that the users can specify a jsonPatch or merge snippet, instead of a full resource?
  Is there such a use case?
• For built in actions - do we wanna set a blacklist/whitelist boundaries on what kind of resources contributed Lua actions can create?

Tests:

• Asserting that an action that creates a resource, the permissions for which are not granted, fails with permissions error.
• If decided on boundaries for built-in actions, adding tests that would fail upon actions that violate those boundaries.
• If decided on an "update" operation as well - asserting that an action that updates a resource different from the one it operates on fails with an error.

[otherguy]

This would be extremely useful. A first step would be just to allow creation of any resources as it would enable #4116

[tuananh]

This would be extremely helpful. Watching 👀

[reggie-k]

Apart from ad-hoc creation of Job from CronJob, what other uses of this feature are expected?