You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
CA-403744: Implement other_config operations for task (#6239)
Currently, users with read-only permissions can freely manipulate their
own tasks (create, cancel, destroy, etc.). However, they cannot easily
manipulate the `other_config` field. Some keys are specified in the
datamodel as being writeable by subjects with the VM operator role.
However, RBAC checking for keys was only ever implemented for the
individual "add" and "remove" operations, not the `set_other_config`
operation. This makes sense because the typical scenario is that the
required writer role for an "other_config" field is more privileged than
each of the individually-specified key-specific roles.
In the case of tasks, the desired role for the `set_other_config`
operation is the read-only role. However, we cannot simply demote the
required "writer role" for the `other_config` field, because:
1) We must maintain key-based RBAC checks for the operation. For
example, if a read-only user attempts to modify a task's `other_config`
using `set_other_config`, the operation must fail if they've attempted
to modify the value mapped to by some key that they are not
privileged to use.
2) Key-based RBAC checking is special cased to `add_to` and
`remove_from`. You can attempt to ascribe key-related role
restrictions to arbitrary messages but these will all fail at
runtime, when invoked - because `Rbac.check` is special cased to expect
to be able to extract out the key name from a `key` argument it
receives, which is emitted for `add_to` and `remove_from`.
3) There is an additional restriction that read-only users should not be
able to modify arbitrary tasks, only their own.
Both of these points require a custom implementation. To this end, we
mark `other_config` as read-only (DynamicRO) and implement custom
handlers for the `add_to`, `remove_from`, and `set` operations. In doing
so, we implement a subset of the RBAC protection logic for keys.
This custom implementation amounts to a relaxation of the usual RBAC
rules: where `add_to` and `remove_from` (both purely destructive
operations) cite a protected key (that they are not permitted to write),
RBAC fails. In the custom implementation of `set_other_config`, an
under-privileged session can cite any key so long as their change is not
destructive (it must preserve what is already there).
---
The motivation for this change is in fusing serial `add_to_other_config`
and `remove_from_other_config` operations into a single
`set_other_config` call. I've included (possibly excessive) commentary
within the code as the RBAC checking stuff is not touched a lot. This
change may not be desirable overall, as it has low impact.
0 commit comments