Skip to content

[WFCORE-7247][WFLY-21238] Filtering mechanism for management audit logging and configuration change history#769

Open
yersan wants to merge 1 commit intowildfly:mainfrom
yersan:WFCORE-7247
Open

[WFCORE-7247][WFLY-21238] Filtering mechanism for management audit logging and configuration change history#769
yersan wants to merge 1 commit intowildfly:mainfrom
yersan:WFCORE-7247

Conversation

@yersan
Copy link
Contributor

@yersan yersan commented Dec 3, 2025

@github-actions github-actions bot added the stability-level/community "Community" stability level label Dec 3, 2025
@rhusar
Copy link
Member

rhusar commented Dec 5, 2025

Please always include clickable links in the description, we don't have the WF bot on here :)

@github-actions github-actions bot added stability-level/community "Community" stability level and removed stability-level/community "Community" stability level labels Dec 5, 2025
@rhusar rhusar changed the title [WFCORE-7247][WFLY-21238] Filtering mechanism for management audit lo… [WFCORE-7247][WFLY-21238] Filtering mechanism for management audit logging and configuration change history Dec 9, 2025
@jamezp
Copy link
Member

jamezp commented Jan 21, 2026

@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.

@github-actions github-actions bot added stability-level/community "Community" stability level and removed stability-level/community "Community" stability level labels Jan 22, 2026
@yersan
Copy link
Contributor Author

yersan commented Jan 22, 2026

Thank you @jamezp , I've just added you there ... I will try to move this one in this WF40 cycle

@jamezp jamezp self-requested a review January 27, 2026 00:24
* 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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@darranl
Copy link
Contributor

darranl commented Feb 26, 2026

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>
@github-actions github-actions bot removed the stability-level/community "Community" stability level label Feb 27, 2026
@yersan
Copy link
Contributor Author

yersan commented Feb 27, 2026

Thanks @darranl , added you as SME since this is a security related issue

@github-actions github-actions bot added the stability-level/community "Community" stability level label Feb 27, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

stability-level/community "Community" stability level

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Filtering mechanism for management audit logging and configuration change history

4 participants