Give apm_user reserved role read privileges on .apm-*

[ogupte]

Addresses elastic/kibana#43326 by giving the apm_user reserved role read privileges on .apm-* to view APM agent settings in Kibana.

[elasticmachine]

Pinging @elastic/es-security

[kobelb]

Since we have the new privileges model introduced by all of this RBAC work, I don't think we want to be granting the apm_user role access to the .apm index. Instead, the kibana_system role would get access to the .apm index, we'd authorize the user in Kibana itself using Kibana RBAC, and then use callWithInternalUser in Kibana as opposed to callWithRequest.

[sorenlouv]

Instead, the kibana_system role would get access to the .apm index, we'd authorize the user in Kibana itself using Kibana RBAC, and then use callWithInternalUser in Kibana as opposed to callWithRequest.

So whenever we want to read/write to/from .apm-* indices we should use callWithInternalUser?

[kobelb]

So whenever we want to read/write to/from .apm-* indices we should use callWithInternalUser?

Correct. We'll want to ensure that the proper authorization is performed using the Kibana privileges before doing so though. If it's in the context of an API you can do so similar to the Dev Tools example.

[sorenlouv]

Yes, it is in the context of an API. So we can't use callWithInternalUser since that would give everyone access to read. I'm not following how the ui capabilities can provide or limit access to an index. Afaict a user with the apm_user role is currently not allowed to read from .apm-*. Don't we need to give the role access when it is created in elasticsearch?

[kobelb]

I'll be writing more about how the ES security model works in regard to Kibana later this week. Some of the slides from the Orlando EAH cover some of this, and I've tried to respond specifically to the questions that you've raised below https://docs.google.com/presentation/d/1mYIwFtkbt5moI_DPNyQCASvAcqnOPHZmVaJ_awfX0s8/edit#slide=id.g59eaf42a3a_2_62.

So we can't use callWithInternalUser since that would give everyone access to read.

We'd continue to want to use callWithRequest when accessing the apm-* data indices. However, when reading from the .apm-* system indices, we'll want to use callWithInternalUser after ensuring the appropriate Kibana privileges are checked.

I'm not following how the ui capabilities can provide or limit access to an index.

UI capabilities are inferred from the Kibana privileges. Kibana privileges are used instead of requiring users to have direct access to system indices. Using Kibana privileges allows us finer level of control to the data that is stored in the system indices, so users can only have access to subsets of the information to enable things like Spaces, and users only being able to access certain features.

Afaict a user with the apm_user role is currently not allowed to read from .apm-*. Don't we need to give the role access when it is created in elasticsearch?

That is correct. apm_user only grants read access to the apm-* data indices. Perhaps it'd be beneficial for us to take a step back. What is it that you all are persisting to the .apm-* system indices?

[sorenlouv]

That is correct. apm_user only grants read access to the apm-* data indices. Perhaps it'd be beneficial for us to take a step back. What is it that you all are persisting to the .apm-* system indices?

Similar to beat configuration (fleet) it is possible to configure APM agents via the UI. The configurations are stored in .apm- indices.
To list the configurations in the UI we query the index on behalf of the user. Without read access the user will get an error.

[kobelb]

Similar to beat configuration (fleet) it is possible to configure APM agents via the UI. The configurations are stored in .apm- indices.
To list the configurations in the UI we query the index on behalf of the user. Without read access the user will get an error.

Are you using the "Saved Objects Client" in Kibana for storing/accessing agent configuration?

[sorenlouv]

Are you using the "Saved Objects Client" in Kibana for storing/accessing agent configuration?

No. I think @ogupte looked into this and we decided against. I can't remember why. Do you @ogupte ?

[ogupte]

Are you using the "Saved Objects Client" in Kibana for storing/accessing agent configuration?

No. I think @ogupte looked into this and we decided against. I can't remember why. Do you @ogupte ?

I think at first we wanted apm-server to be able to query the configuration index directly to pass along configurations to the agent when requested. Now, the apm-server calls a Kibana API which returns the configuration. So it is possible to persist these configurations as saved objects with the most recent architecture.

[ogupte]

Closed this since we should not depend on the reserved role to read from the configuration index.