Adding cluster.id to the orchestrator field set

[amitkanfer]

• Have you signed the contributor license agreement?
• Have you followed the contributor guidelines?
• For proposing substantial changes or additions to the schema, have you reviewed the RFC process?
• If submitting code/script changes, have you verified all tests pass locally using make test?
• If submitting schema/fields updates, have you generated new artifacts by running make and committed those changes?
• Is your pull request against main? Unless there is a good reason otherwise, we prefer pull requests against main and will backport as needed.
• Have you added an entry to the CHANGELOG.next.md?

[MikePaquette]

Hi @amitkanfer thanks for submitting this pull request!

It looks straightforward to me. LGTM, based on the following rationale:

• The cluster object already exists within orchestrator.cluster.name and other fields.
• It is very common, almost universal, for ECS to have an id field associated with a name field.
• Data type keyword is common for id fields
• Extended level makes sense becuase usage will be limited to a subset of use cases (those dealing with Kubernetes or other container orchestrators.)

[MikePaquette]

@ebeahan Can you have a look and let us know what you think?

[ebeahan]

LGTM! Thanks, @amitkanfer!

I'll add an entry to CHANGELOG.next and merge.

[ebeahan]

💚 All backports created successfully

Status	Branch	Result
✅	8.3

Questions ?

Please refer to the Backport tool documentation

[eyalkraft]

@amitkanfer Following a chat with @m-sample as we're aligned about using the kube-system namespace uuid as the identifier here, wdyt about documenting this here in ECS? I'll open a PR unless we've missed something.

This aligns with the requirement for ECS specs to be useful for both data consumers and data providers.
Documenting this field allows anyone to write their own sensor and populate the orchestrator.cluster.id field with values that match those produced by our sensors. (thanks @m-sample, @ebeahan)

[amitkanfer]

i think it's a good idea. Do we want to further define it as a f(kube-system) where f is a hash function of some sort?
if we don't do so - the only way to differentiate between a cluster_id and the namespace_id (in a case where we would collect it) - is that the cluster_id will be under orchestrator.cluster.id and the namespace will probably be under orchestrator.resource.id and the corresponding type to indicate it's a namespace.

Makes sense? Do we want to go forward w/o the hashing function? @eyalkraft @m-sample