Add security_audit feature#5594
Conversation
added an optional security_audit flag which users can specify in the st2,conf file, This is used to track when keys are being decrypted either manually in the container or when a workflow is triggered and contains an encrypted key in its config.
updated conf file
removed the need of having another flag in st2,conf, changed the log.info to a log.audit
reverted back conf file
added extra argument for better search ability
excluded jinja parts from the logs
arm4b
left a comment
There was a problem hiding this comment.
Looks good.
Thanks for the contribution!
cognifloyd
left a comment
There was a problem hiding this comment.
I reformatted with black for you :)
I don't think this is complete. Secrets can also be decrypted in ContentPackConfigLoader._get_datastore_value_for_expression() if the schema has secret: true. (see comment).
There may be other places we should add this audit log as well.
For instance, should this also be included in contrib/runners/orquesta_runner/orquesta_functions/st2kv.py which calls kvp_util.get_key() (ie st2common.util.keyvalue.get_key() which calls deserialize_key_value()).
added if user decrypts the key
added condition for when the user audits decryption event.
cognifloyd
left a comment
There was a problem hiding this comment.
I'm sorry I keep requesting repeated changes - I just want to make sure the AUDIT log entry is as accurate/useful as possible and this isn't the easiest block of code to grok (for me).
Here are some suggestions on how to deal with the log entries in the controller.
The pack config entry looks great to me now.
updated get_all to account for all decryption events
added log audit message after _get_one_by_scope_and_name
updated the get_all function added user scope
|
I was reviewing this on my phone before. I just pushed a commit to move the audit logs slightly so I don't have to keep annoying you (sorry!). @dmork123 what do you think about this? If you're happy with what I did, I'll merge it. |
|
Create AUDIT log entry when datastore keys are being decrypted either manually (via API which is used by the
st2CLI) or when a workflow/action is triggered and the action's metadata or parameters accesses a secret from pack config or decrypts a datastore key.