Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Add new audit handler method for action responses #63708
Add new audit handler method for action responses #63708
Changes from 32 commits
c710726
e9f2866
48d647e
e3c5c3f
9469127
2f5e546
d88969b
0ebadb9
f6ff433
9f56238
765493f
cf172b8
71790f9
e25903e
6e229a8
43f3644
a922aa8
aada0ae
655bba9
8c03167
b514c0c
6706993
ec22611
1b5b65e
e7383c5
14425d5
a730658
c6d1a74
93299a3
3926ada
4d579d7
e5ddb6e
cf59a60
7851883
3753771
49a2852
6e2e882
b81f644
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not technically true, some actions' (
TransportMasterNodeAction
) responses are intercepted on the coordinating node, as well as on the master node.The naming and descriptions are difficult to write to convey the subset of actions that are covered.
We could also bleed some internals in here and mention the
SecurityActionFilter
.Open to suggestions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we could keep the previous name, i.e.
actionResponse
. Please let me explain: When I suggested pulling out the code fromSecurityServerTransportInterceptor
, it was in the context of getting auditing for API key ID in for v7.11.0. The reasons are:SecurityServerTransportInterceptor
is a fairly low level indexing response and does not really provide extra valuable information than the one in the coordinating node. Therefore auditing on just the coordinating node is sufficient.TransportReplicationAction
. UnlikeTransportMasterNodeAction
, it does not go through theSecurityActionFilter
(on the remote node). This means: on the remote node, we will not get another auditing entry fromSecurityActionFilter
, i.e. there will only be a single auditing entry about API key creation and it is on the coordinating node.So my motivation was rather narrowly focused on the particular use case. The agreement, as I understand it, is to defer the auditing code in
SecurityServerTransportInterceptor
until the next release. Because it is not necessary for API key auditing in this release and if it is not in use, it's better to be left out. But we also agreed that it could still be useful when we expand the usage scenario and this is subject to further discussion.IIUC, your intention of changing the method name is for the possibility to have two different audit event types. I should have been clear that it was not my proposal. I consider whether auditing inside
SecurityServerTransportInterceptor
an implementation detail, which we chose to opt out for initial release, but could choose to add it later as an enhancement. For verbosity and duplication control, I'd prefer to solve it in a different way other than splitting it into different audit event types. I hope this makes sense.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the detailed explanation Yang, but I would like to focus the conversation on the scope of this PR only. We should consider the broader picture, as you describe, but ultimately this PR is what gets merged as a unit, and what we merge in the future is subject to debate still.
If we merge this PR, which adds the audit hook for the responses of actions intercepted by the
SecurityActionFilter
only, we add to the interface of theLoggingAuditTrail
.When we later merge the code to allow intercepting the responses of the other actions, we have the options to:
LoggingAuditTrail
hook method(or any mix of them, really, if we feel wild)
Because this is a private interface, I don't believe we have to name it in anticipation of its use. We should name it for the purpose that it serves right now, as we can always tinker with it later. For this reason, I would not favor the
actionResponse
name.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just trying to brainstorm here: How about calling this one
actionResponse
and the other onetransportResponse
?As you said, this is a private interface, so we don't have to struggle too much with its name now. So please feel free to use whatever works for you.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, this could work. I'll keep this in mind when we'll iterate on the interface.