Add a user.roles field

[legrego]

Summary

When recording events performed by a user under RBAC, it is sometimes useful to record the set of roles the user had at the time the action was performed.

As an example, the Elasticsearch audit logs include this information, as described in their docs

Motivation:

Kibana is revamping its audit logging, and as part of this work, we are transitioning to be fully ECS compliant. Our logs aim to record the set of roles the end-user is assigned, and having a first-class location for this information within ECS would be beneficial to us.

We have a work-in-progress which targets this information under a custom kibana.user_roles category, but having this information exist within ECS's user category would offer a much nicer experience. We do have other alternatives if you feel this shouldn't be included in ECS, but I wanted to start a discussion to explore our options first.

Detailed Design:

Provide additional details around the design of the proposed changes.

• Field names: user.roles
• Example values for the fields

{
   "user": {
      "name": "elastic",
      "roles": ["superuser"]
   }
}

• Suggested appropriate datatypes
  I think keyword would be an appropriate datatype for this information.

• Any example events that map to the proposed use case(s)

Audit logs generated by both Elasticsearch and Kibana could benefit from this information

[webmat]

I like the idea.

This is a good complement to user.group.* which is a single nesting of a user's group relevant to an event. user.group isn't appropriate to capture all of a user's groups or roles in an audit log.

So capturing the user's roles at the time of the event via this array field makes sense to me.

[ebeahan]

++ I think this would be a good addition as well.

I can see user.roles being overloaded between different event types. For example:

1. events capturing a user's active role assignments (user logged in and authorized for ["a", "b", "c"] roles)
2. events when roles/policies are being assigned to a user by an administrator

For simplicity I like user.roles, but wonder if user.assigned_roles or user.granted_roles may help clarify the field's intent?

[legrego]

I can see user.roles being overloaded between different event types. For example:

1. events capturing a user's active role assignments (user logged in and authorized for ["a", "b", "c"] roles)
2. events when roles/policies are being assigned to a user by an administrator

For simplicity I like user.roles, but wonder if user.assigned_roles or user.granted_roles may help clarify the field's intent?

I'm not opposed to exploring other names. I don't have the broader picture of everything ECS is used for, so I'll defer to you all on what makes the most sense.

I could also make the argument that there's ambiguity for the other user fields though. What if an event changed the user.email field, for example? If this is also something we're concerned about, then maybe it makes sense to use a nested user object within another category to distinguish the updated user fields vs the fields which describe the user the event is associated with?

[webmat]

@legrego Yeah changes to existing users (and other use cases) are being addressed in this RFC #914, you may want to check it out. You're welcome chime in there, if you see things that wouldn't work with what you have in mind.

Let's move the discussion to #917, which would implement this :-)