Add field event.agent_id_status#1454
Merged
andrewkroh merged 4 commits intoelastic:masterfrom Jun 14, 2021
Merged
Conversation
ebeahan
reviewed
Jun 8, 2021
Member
There was a problem hiding this comment.
Two thoughts about naming and the allowed values:
- What about dropping the
agent_id_prefix and simply usemismatchandmissing? The prefix feels a bit redundant with the field name specifyingagent_idalready. - I don't have an issue with
event.agent_id_statusand 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.
Member
Author
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
Member
Author
|
Doc preview:
|
ebeahan
approved these changes
Jun 10, 2021
Member
ebeahan
left a comment
There was a problem hiding this comment.
Thanks, the doc preview for the field looks great 👍
ebeahan
pushed a commit
to ebeahan/ecs
that referenced
this pull request
Jun 14, 2021
* 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
ebeahan
added a commit
that referenced
this pull request
Jun 14, 2021
* 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 <andrew.kroh@elastic.co>
1 task
andrewkroh
added a commit
to elastic/kibana
that referenced
this pull request
Jun 21, 2021
…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.
kibanamachine
pushed a commit
to kibanamachine/kibana
that referenced
this pull request
Jun 21, 2021
…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.
kibanamachine
added a commit
to elastic/kibana
that referenced
this pull request
Jun 22, 2021
…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 <andrew.kroh@elastic.co>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
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.