Keystore RBAC Configuration Issues

[jamesdreid]

SUMMARY

Changes to the RBAC to incorporate the keystore items has created various issues with the config that cannot be corrected aside from assigning users "admin" roles. First, actions/workflows that are grant permission to a user by RBAC role config to DO NOT apply to keystore operations that are executed within it. This includes any internal client functions coded in an action or any tasks that call keystore actions within the workflow. Second, there is no way to configure RBAC to work around this limitation as none of the keystore operations are available to be configured in the global RBAC context and can only be applied to individual keys that are known by name which does not allow for the creation of any new system-level keys (as the name/resource ID is not known until the action is run). As a result, you cannot even work around the issue by creating a config that would allow a user to have "Admin" access to keystore items, but limit their ability to execute actions within the system.

Ideally, RBAC would be updated to allow ALL of the keystore operations

st2/st2common/st2common/rbac/types.py

Line 369 in 606f42f

ResourceType.KEY_VALUE_PAIR: [

to be defined globally.

st2/st2common/st2common/rbac/types.py

Line 437 in 606f42f

GLOBAL_PERMISSION_TYPES = [

Along with the global config options, the RBAC config should incorporate the ability to define keystore resource IDs using a regex filter so it could allow for very granular access to specific (or groups of specific items) in the keystore for each different operation on a per user/role basis.

STACKSTORM VERSION

3.7 and greater with RBAC enabled

OS, environment, install method

Centos 8/Rocky Linux

Steps to reproduce the problem

Create an RBAC config that allows a user to perform an action that includes the reading or writing of any keystore item and run the workflow as that user.

Expected Results

Action permission should allow the workflow to be executed.

Actual Results

Workflow fails at task/action that attempts to perform the keystore action.

[fdrab]

I did some testing:
1, I've created a local user st2apiuser and created an api key for that user. Tried to execute a sample flow I created that uses a system scoped key, it didn't work.
2, I've granted the user execute permissions on a workflow that uses said system scoped key and the user was able to execute the workflow with no issues, despite not having been granted any permissions on the system scoped key used. (api call to get the system scoped key fails) - this was done via st2kv()
3, tried the same with an encrypted key and it didn't work, because to decrypt keys the user requires to have admin level privileges
EDIT:
4, tested a flow that uses st2.kv.get and that one doesn't work

So, a user is able to trigger the execution of a workflow that uses a system scoped key, but not decrypt it if it's encrypted.

I disagree that a user should be granted all permissions to a key when granted access to a workflow that uses that key, because in large environments you may want to grant a user the permissions to execute and use a workflow that uses sensitive passwords, but not grant them access to view said passwords in their unencrypted form.

I'd be happy if I could grant a user permissions to a flow that uses even encrypted keys and they'd be able to run the flow, but not be able to decrypt / see the key.

[jamesdreid]

I will have to go back a do a more involved set of tests but I think we are seeing much the same as you are reporting. There does seem to be some slight difference in keystore actions that are initiated as part of the ST2 Action methods as opposed to KV actions, but there are some serious issues with the current implementation that need to be addressed.

I did not even get to the decryption of keys but that is a good point that should be considered as well as I agree it would be useful to allow for the USE of a decrypted key value but not have the ability to read it. I would consider this a feature above and beyond this basic config enhancements that are currently lacking in the implementation.

In any case, I do agree that permissions to execute an action should not necessarily give access to the keys it could touch, but it does point out the discrepancy in a fairly simple manner. I can give someone "execute" access to the st2.kv.set or st2.kv.get actions but they will fail unless I explicitly give them access to any/all keys with the "set" being almost impossible to resolve as I would have "predetermine" every key that user was to be allowed to create and grant those resource IDs in my RBAC config.