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, its possible to use the security audit log to track changes to the security index when listening for COMPLIANCE_INTERNAL_CONFIG_WRITE events. Its also possible to combine this with config.compliance.enabled: true, config.compliance.write_log_diffs: true and config.compliance.write_metadata_only: false to only capture the diffs for security index requests.
The problem with this is that its not intuitive to configure and leaves cluster operators filtering the audit log for these types of events to figure out security config changes.
I'm opening this issue to spark a discussion about separating these config changes out to a separate place with the eventual goal of supporting rollback/rollforward in case a cluster operator wants to revert to the last previously known good cluster state.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem?
Currently, its possible to use the security audit log to track changes to the security index when listening for
COMPLIANCE_INTERNAL_CONFIG_WRITE
events. Its also possible to combine this withconfig.compliance.enabled: true
,config.compliance.write_log_diffs: true
andconfig.compliance.write_metadata_only: false
to only capture the diffs for security index requests.The problem with this is that its not intuitive to configure and leaves cluster operators filtering the audit log for these types of events to figure out security config changes.
I'm opening this issue to spark a discussion about separating these config changes out to a separate place with the eventual goal of supporting rollback/rollforward in case a cluster operator wants to revert to the last previously known good cluster state.
The text was updated successfully, but these errors were encountered: