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
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).
Signed-off-by: Colin James <[email protected]>
0 commit comments