[Feature requests] action protection

[style95]

It would be great if we can have feature to protect actions from accidental deletion.
It can happen at anytime and the impact is critical when action is being used in production.
Most of VM services have similar feature.

[csantanapr]

@style95 could you provide a proposal or more details on the use case?
Can you elaborate on “VM services” how do they provide feature and how it would contrast with Serverless and Container services ?

[style95]

@csantanapr Many VM services provide option to enable VM protection.
If user enables that option, no one can delete that VM until user explicitly disables protection.

So I naively thought that if user can enable protection against actions, user can protect important(used in production) actions from accidental deletion.

[csantanapr]

@style95 can you elaborate your problem?

Today we only generate one master api key. This key is use to create, update and delete.

Today the solution is that you have a namespaces for each environment and that the master key for production is not shared, saved in a vault and scripts deploying to production never delete and always create/update

Long term there might be better ACLs thru IAM/oauth identity, but what you are requesting is much simpler? Like marking an entity (trigger, rule, package, or rule) remove the “write” equivalent to “chmod -w” ? Meaning can still read/GET and execute/POST but can’t be deleted right?

Maybe a new annotation can serve as a mid term solution that indicates to the controller that the entity is marked that can’t be deleted.
But you would have to deal with the burden in production CI scripts to remove lock, then deploy and after deploy add the lock.

Does this reflect your problem, need and desire solution?

[style95]

@csantanapr Yes mostly you are correct.

Let me clarify issues more.
Actually, I am operating in-house version of OpenWhisk with our own UI.
In UI, once user login, all requests(action deletion) for api key is automatically populated.

I originally thought use-case in UI, but same thing can happen via CLI as well.
No matter which CLI is used(wsk or serverless), we can do CRUD against actions once we configure api key. No need to configure api key for subsequent requests.

Under the situation that api key is already configured, user can easily delete their own actions.
If actions is already being used in production, accidental deletion can introduce calamity.

Regarding your lock related concern, I think we can provide a level of protection; only protect from deletion and protect from update and deletion and so on.

HDYT?

Regarding implementation, I was also thinking of annotations based approach.

[csantanapr]

Hum there is no point of protecting from delete only and not update the action can accidentally be updated with wrong version of code or just a broken action.
I think it needs to be a single setting making it read and execute only meaning no delete or update to have the protection correctly explicitly applied.

[ddragosd]

I also feel like a developer should have full control over the action.

Maybe a warning like

• “you’re deleting an action that is used in a sequence; are you sure ?”
• or “you’re deleting a web action that may be used, are you sure ....”
  Would help ?

Another idea is to work with a wskdeploy manifest and only make updates from it ?

[rabbah]

There is a general issue in that referenced entities are not tracked at all today - applies to rules, packages, sequences, and compositions. We don't track dependencies today.

The way I propose approaching this is two fold: 1. addressing referenced entities (#1047) and 2. fine grained permission on entities (like unix permissions) so that an action could be locked to +x (execute only) not -rw (read or write).

Annotations are a reasonable way of addressing 2 initially -- eventually this may warrant rising to the level of a first class property.

[ningyougang]

@rabbah #4058