Add support for reading request ID from X-Opaque-Id header#71019
Add support for reading request ID from X-Opaque-Id header#71019joshdover merged 18 commits intoelastic:masterfrom
Conversation
There was a problem hiding this comment.
This is probably not the right name since this identifier may not come from a request (eg. background task).
There was a problem hiding this comment.
In ECS audit log this will be logged as trace.id but I'd say don't worry about updating the schema for now. I am happy to implement this as part of audit log PR as it's just going to create merge conflicts.
I added a task to add |
|
This PR is still in draft and WIP. Just wanted to push up what I had at the end of my day to run CI. There's definitely some still some rough edges. I will get back to this tomorrow and address the feedback. Also big +1 on using Joi here, I had forgotten that it included very specific validations like IP. |
delvedor
left a comment
There was a problem hiding this comment.
Just a heads up, if you need it, the client does have first-class support for the X-Opaque-Id header :)
It could be useful to include the audittrail's current scope name as a prefix in the |
Not sure how to leverage that however, as we decided to get rid of our facade. We can't create a child client with preconfigured |
@pgayvallet correct, the global configuration is used as a prefix for the local configuration, and it should be handwritten each time. Anyhow, the client does not complain at all if you directly configure it in the headers, the only catch is that if you configure both headers and the |
18fe8bb to
cffd076
Compare
There was a problem hiding this comment.
cidr not needed right now, so I just set to forbidden. Can be exposed in the future if needed.
cffd076 to
b638bcd
Compare
|
This will be on hold while I'm on PTO. It should not block any other Audit Logging work, it just needs to be completed for 7.10 FF |
|
Pinging @elastic/kibana-platform (Team:Platform) |
thomheymann
left a comment
There was a problem hiding this comment.
Looks great, can't wait to use this in audit log 🥳
There was a problem hiding this comment.
In ECS audit log this will be logged as trace.id but I'd say don't worry about updating the schema for now. I am happy to implement this as part of audit log PR as it's just going to create merge conflicts.
|
@elasticmachine merge upstream |
|
@elasticmachine merge upstream |
pgayvallet
left a comment
There was a problem hiding this comment.
Few nits and a question, but overall LGTM.
| /** | ||
| * A identifier to identify this request. | ||
| * | ||
| * @remarks | ||
| * Depending on the user's configuration, this value may be sourced from the | ||
| * incoming request's `X-Opaque-Id` header which is not guaranteed to be unique | ||
| * per request. | ||
| */ | ||
| public readonly id: string; |
There was a problem hiding this comment.
This comment makes me wonder if we really have the correct approach by having a single property for the request 'id' and the 'x-opaque-id' that we forward to ES.
The risk I see here is that it would make our audit logging virtually 'useless' to debug a specific user scenario in a environment where the kibana instance is configured to allow x-opaque-id from requests and where the user would send a constant value for multiple requests, as all requests/log entries would have the same id in the logs.
This feels like an edge case though, so it's probably not worth changing everything just for that (or maybe this is even what we want?)
There was a problem hiding this comment.
The risk I see here is that it would make our audit logging virtually 'useless' to debug a specific user scenario in a environment where the kibana instance is configured to allow x-opaque-id from requests and where the user would send a constant value for multiple requests, as all requests/log entries would have the same id in the logs.
I think we should treat this as an invalid configuration. I'm not sure how else we could properly support forwarding the header from the incoming request to ES without introducing this possibility. I think this case is kind of an edge case but it's hard to know for sure since it is so dependent on the infrastructure Kibana is running behind. Operators will have to explicitly turn on request ID forwarding from the incoming request, so I would hope that they also validate that the configuration is correct end-to-end with their proxy.
We could help the operator experience here by logging a warning message if we see the duplicate x-opaque-id headers being sent in the last N requests. @thomheymann do you have any thoughts? Should we add a warning like this for the MVP?
There was a problem hiding this comment.
Merging as-is for now, but we can address this in a follow up PR if needed.
💚 Build SucceededBuild metrics
History
To update your PR or re-run it, just comment with: |
…1019) Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
| (request.raw.req.socket?.remoteAddress && | ||
| options.ipAllowlist.includes(request.raw.req.socket.remoteAddress)) | ||
| ? request.headers['x-opaque-id'] ?? uuid.v4() | ||
| : uuid.v4(); |
There was a problem hiding this comment.
Can we extract the id generation logic in a common place to use it here and in KibanaRequest contructor?
export function generateId() {
return uuid.v4();
}These broke due to the recently merged code for reading request ID from the X-Opaque-Id header in #71019.
Summary
Fixes #62018
This PR essentially does 3 things:
requestIdfield toKibanaRequestthat is sourced from theX-Opaque-IdheaderLegacyScopedClusterClientrequestIdto AuditEvents in the audit_trail pluginTODO:
Checklist
Delete any items that are not applicable to this PR.
For maintainers