-
Notifications
You must be signed in to change notification settings - Fork 431
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 field event.agent_id_status #1454
Add field event.agent_id_status #1454
Conversation
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.
Two thoughts about naming and the allowed values:
- What about dropping the
agent_id_
prefix and simply usemismatch
andmissing
? The prefix feels a bit redundant with the field name specifyingagent_id
already. - I don't have an issue with
event.agent_id_status
and understand shorter field names are often preferred, but I do think something more detailed, likeevent.agent_id_validation_status
, describes the field's purpose better.
Good idea. That change is reflected in the changes I pushed.
I had similar thoughts. Initially I had |
This adds a field that can be used to reflect the status of the agent.id verification performed by the receiving system or data pipeline. If the receiving system checks that the sender is authorized for a given agent.id value then the outcome can be added to this field. For example you might implement mTLS for authenticating agents sending data to Logstash. You could add the agent's ID to the agent's client cert subject and then validate incoming events in your Logstash pipeline to ensure the data has the agent ID. Or with Elasticsearch you could provide each of your agents with an API key that has the agent.id associated to the API key metadata. Then using an Ingest Node pipeline you can validate the agent.id against the client's API key metadata.
1e7cfcb
to
d9c9904
Compare
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, the doc preview for the field looks great 👍
* Add field event.agent_id_status This adds a field that can be used to reflect the status of the agent.id verification performed by the receiving system or data pipeline. If the receiving system checks that the sender is authorized for a given agent.id value then the outcome can be added to this field. For example you might implement mTLS for authenticating agents sending data to Logstash. You could add the agent's ID to the agent's client cert subject and then validate incoming events in your Logstash pipeline to ensure the data has the agent ID. Or with Elasticsearch you could provide each of your agents with an API key that has the agent.id associated to the API key metadata. Then using an Ingest Node pipeline you can validate the agent.id against the client's API key metadata. * Shorten value names, remove allowed_values # Conflicts: # experimental/generated/csv/fields.csv # generated/csv/fields.csv
* Add field event.agent_id_status This adds a field that can be used to reflect the status of the agent.id verification performed by the receiving system or data pipeline. If the receiving system checks that the sender is authorized for a given agent.id value then the outcome can be added to this field. For example you might implement mTLS for authenticating agents sending data to Logstash. You could add the agent's ID to the agent's client cert subject and then validate incoming events in your Logstash pipeline to ensure the data has the agent ID. Or with Elasticsearch you could provide each of your agents with an API key that has the agent.id associated to the API key metadata. Then using an Ingest Node pipeline you can validate the agent.id against the client's API key metadata. * Shorten value names, remove allowed_values Co-authored-by: Andrew Kroh <[email protected]>
…2805) This updates the Fleet final pipeline added in #100973 to match the specification of `event.agent_id_status` field as defined in ECS. The field was added to ECS in elastic/ecs#1454. Basically the values of the field were simplified from what was originally proposed and implemented.
…stic#102805) This updates the Fleet final pipeline added in elastic#100973 to match the specification of `event.agent_id_status` field as defined in ECS. The field was added to ECS in elastic/ecs#1454. Basically the values of the field were simplified from what was originally proposed and implemented.
…2805) (#102832) This updates the Fleet final pipeline added in #100973 to match the specification of `event.agent_id_status` field as defined in ECS. The field was added to ECS in elastic/ecs#1454. Basically the values of the field were simplified from what was originally proposed and implemented. Co-authored-by: Andrew Kroh <[email protected]>
This adds a field that can be used to reflect the status of the agent.id verification performed by the receiving system or data pipeline. If the receiving system checks that the sender is authorized for a given agent.id value then the outcome can be added to this field.
For example you might implement mTLS for authenticating agents sending data to Logstash. You could add the agent's ID to the agent's client cert subject and then validate incoming events in your Logstash pipeline to ensure the data has the agent ID.
Or with Elasticsearch you could provide each of your agents with an API key that has the agent.id associated to the API key metadata. Then using an Ingest Node pipeline you can validate the agent.id against the client's API key metadata.