[WFCORE-7247][WFLY-21238] Filtering mechanism for management audit logging and configuration change history#769
[WFCORE-7247][WFLY-21238] Filtering mechanism for management audit logging and configuration change history#769yersan wants to merge 1 commit intowildfly:mainfrom
Conversation
|
Please always include clickable links in the description, we don't have the WF bot on here :) |
|
@yersan I think I could be the outside perspective on this. I'm not sure I'd be considered an SME here given this is more about audit logging than logging in general. |
|
Thank you @jamezp , I've just added you there ... I will try to move this one in this WF40 cycle |
| * Provide a new attribute named `enable-redaction` at `/core-service=management/access=audit` so users can enable or disable the redaction of sensitive data in the management audit log. | ||
| ** It defaults to `true`. | ||
| ** When enabled, any attribute flagged as `redactable` will be redacted when the management operation that includes the attribute is logged in the management audit log. | ||
| * Provide a new attribute named `enable-redaction` at `/subsystem=core-management/service=configuration-changes` so users can enable or disable the redaction of sensitive data in the configuration change history. |
There was a problem hiding this comment.
One minor concern I have is having the enable-redaction in two places. I understand one is for the print of audit logs and one is for seeing them via the resource. The main concern I have is if the attribute is set to false in two places for a test environment, but set back to true only in one place for another environment.
The only potential solution I could think of would be to add the enabled-redaction attribute at the root, e.g. /:read-attribute(name=enable-redaction). I'm not sure that is a good or even viable solution, but just kind of thinking out loud.
There was a problem hiding this comment.
Good point. My feeling is that it should be left to the administrator being their responsibility to properly configure the server.
By default, the redaction is enabled, so if you, as an administrator, are disabling one in the above resources, you should know that the sensitive information for such a resource will not be redacted.
By the way, I made a mistake with the name of the audit resource. I'm going to fix it now:
Instead of /core-service=management/access=audit, the configuration attribute will be placed at the audit log level, /core-service=management/access=audit/logger=audit-log
This is indeed the resource that the administrator enables/disables to activate/deactivate the audit logs, so the enable-redaction should be there instead of a parent level. Notice there is only one audit-log resource, the users cannot create additional ones
There was a problem hiding this comment.
I've pushed a preliminary work for this at wildfly/wildfly-core#6679, it is a draft since there are still some gray areas but wanted to gather some initial feedback on the approach.
|
I dno't mind volunteering to be on the feature team for this one, will make it easier if reviewing code anyway/ |
…gging and configuration change history Signed-off-by: Yeray Borges <yborgess@redhat.com>
|
Thanks @darranl , added you as SME since this is a security related issue |
Jira issues:
Fixes #768