-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
x-pack/filebeat/input/entityanalytics/{okta,azuread/fetcher/graph}: add ability to remove request trace logs #40004
Conversation
b3a9ccf
to
00582ec
Compare
Pinging @elastic/security-service-integrations (Team:Security-Service Integrations) |
This pull request is now in conflicts. Could you fix it? 🙏
|
00582ec
to
0526260
Compare
This pull request is now in conflicts. Could you fix it? 🙏
|
0526260
to
73ff70b
Compare
This pull request is now in conflicts. Could you fix it? 🙏
|
73ff70b
to
da71774
Compare
…dd ability to remove request trace logs This is essentially a replay of elastic#39969, but for the entity analytics providers. The previous configuration system did not allow users to remove trace logs from agents after they are no longer needed. This is potential security risk as it leaves potentially sensitive information on the file system beyond its required lifetime. The mechanism for communicating to the input whether to write logs is not currently powerful enough to indicate that existing logs should be removed without deleting logs from other instances. So add an enabled configuration option to allow the target name to be sent independently of whether the files should be written or removed. The new option is optional, defaulting to the previous behaviour so that it can be opted into via progressive repair in the client integrations.
da71774
to
01b288a
Compare
Proposed commit message
This is essentially a replay of #39969, but for the entity analytics providers.
The previous configuration system did not allow users to remove trace logs from agents after they are no longer needed. This is potential security risk as it leaves potentially sensitive information on the file system beyond its required lifetime. The mechanism for communicating to the input whether to write logs is not currently powerful enough to indicate that existing logs should be removed without deleting logs from other instances. So add an enabled configuration option to allow the target name to be sent independently of whether the files should be written or removed.
The new option is optional, defaulting to the previous behaviour so that it can be opted into via progressive repair in the client integrations.
Checklist
CHANGELOG.next.asciidoc
orCHANGELOG-developer.next.asciidoc
.Disruptive User Impact
Author's Checklist
How to test this PR locally
Related issues
Use cases
Screenshots
Logs