Add Lock/Unlock for user "modify" actions on applications

[drewboswell]

Summary

Add operational lock/unlock functionality/button. (lock on sync, modify, edit, delete etc.)

Motivation

This is principally to protect admins from accidental or erroneous action on critical infrastructure., and introduces an extra layer of accountability. I would also add some peace of mind when operating applications individually or as a group for critical apps like ingress-controllers, sealed-secrets, rbac-manager etc.

Proposal

To not break a gitops workflow, this can take the form of an RBAC permission toggle.

• If lock setting is active, users are reduced to read-only.
• If lock setting is disabled, users have their full rbac settings applied.

There are a few options to consider:

• apply unlock to current user only? apply to all users?
• add a lock/unlock rbac permission?

[jannfis]

Hm, this is an interesting proposal and I can see the need for it - users tend to click quickly, hitting the wrong buttons, mayhem ensues. An additional (optional) safeguard in the UI could be a good thing, I have seen other UIs implementing such things as well.

I think this could be handled by an additional session cookie within the UI, and there's no need for additional RBAC roles. This should be only a safeguard against human errors for the UI.

When this session cookie (e.g. argocd-write-mode=true or similar) is not set, the UI will return an error on all data manipulating queries (i.e. POST, PUT, DELETE) it would usually send. A button on the UI (e.g Enable Write Mode) could be responsible for setting the cookie (and deleting it, when write mode is turned off again by the user).

The final decision whether the query is permitted is still done by the API, evaluating the RBAC permissions using the user's JWT token.

What do you think about this?

[drewboswell]

That's an interesting take to do it via session cookie, this would resemble other platforms' superuser mode in essence. (And way easier to implement and maintain)

I do think that there should be a flag available, so you are able to mark some applications as needing an unlock. Otherwise you may edit as usual.

There is the select multiple apps and synchronize to consider, one could then see a lock next to the flagged ones, and receive a warning for unlocking on mass action.

[victorboissiere]

We have the same use case for two main operations:

• when applying rollback, to prevent new deployments made by other devs
• when in maintenance, to block any new deployments