Kibana: [APM] Use ES Privileges API to check if a user has permissions to read from APM indices

[cauemarcondes]

Follow-up to https://github.com/elastic/kibana/pull/56374

Today to show the Missing Permission page we query all APM indices, and if the result is a 403 it means that the user doesn't have permissions. But it is not right, because if the user has permission to any ES index, the query doesn't return a 403, it returns a 200, but without any data.

Actions

• [x] Call ES API /_security/user/_has_privileges, to check if a user has permission to read from APM indices:
  
  
  
  • 'errorIndices',
  
  
  • 'transactionIndices',
  
  
  • 'spanIndices',
  
  
  • 'metricsIndices',
  
  
• [x] Hide the escape hatch button if the user doesn't have permission to any of APM indices. If the user has permission for some indices, it should be shown. @formgeist WDYT?
• [x] Show a list with the indices that are missing permission to help the user to understand what's the problem. @formgeist WDYT?

Current approach to check permissions
https://github.com/elastic/kibana/blob/18a76c0773bb80ed99f0a98c317af03299118b21/x-pack/legacy/plugins/apm/server/lib/security/getPermissions.ts#L11-L31

[elasticmachine]

Pinging @elastic/apm-ui (Team:apm)

[sqren]

@cauemarcondes Since this is a technical bug report, can you add a link to the code that makes the incorrect query?

[cauemarcondes]

Yes: #56374

[cauemarcondes]

@formgeist do you have any comments about:

• Hide the escape hatch button if the user doesn't have permission to any of APM indices. If the user has permission for some indices, it should be shown.
• Show a list with the indices that are missing permission to help the user to understand what's the problem.
  ?

[formgeist]

• Hide the escape hatch button if the user doesn't have permission to any of APM indices. If the user has permission for some indices, it should be shown.

• Show a list with the indices that are missing permission to help the user to understand what's the problem.

@cauemarcondes I think that makes sense - with the added benefit of listing the APM indices that they don't have access to so they can possibly reach out to their admin in order to gain access. Want me to make some copy for the missing indices listing?

[dgieselaar]

just a thought, what about showing a warning indicator in the APM header if the user closes the permissions warning?

[cauemarcondes]

• Hide the escape hatch button if the user doesn't have permission to any of APM indices. If the user has permission for some indices, it should be shown.

• Show a list with the indices that are missing permission to help the user to understand what's the problem.

@cauemarcondes I think that makes sense - with the added benefit of listing the APM indices that they don't have access to so they can possibly reach out to their admin in order to gain access. Want me to make some copy for the missing indices listing?

That would be great @formgeist , thank you.

[sqren]

just a thought, what about showing a warning indicator in the APM header if the user closes the permissions warning?

I'm worried this will be a little annoying. Say if by design some users only have access to the error section. Already showing the warning on each full page refresh seems like a lot.

[cauemarcondes]

just a thought, what about showing a warning indicator in the APM header if the user closes the permissions warning?

I'm worried this will be a little annoying. Say if by design some users only have access to the error section. Already showing the warning on each full page refresh seems like a lot.

And they will also see the toast notification for the indices that they don't have permission.

[dgieselaar]

The toasts are definitely more annoying anyway than just a small ⚠️ next to the APM header. We could also leverage it for other misconfigurations (mappings etc).

[sqren]

The toasts are definitely more annoying anyway than just a small

I don't think the toasts will be a problem anymore. Users who have access to elasticsearch in any form (not necessarily apm indices) should get an empty 200 response back (since it's a wildcard search, which they are allowed to perform).

Users that do not have any elasticsearch privileges will see the warning without being able to dismiss it (because they can't access any of the APM indices).

[sqren]

That being said, I'm not against a warning symbol like what you suggest @dgieselaar . I can see many use cases for it. But it sounds like a v.2 of this.

[formgeist]

I added in copy around what indices the user role is missing access to.

Updated the general copy as well a bit;

We’ve detected your current role in Kibana does not grant you access to the APM data. Please check with your Kibana administrator to get the proper privileges granted to start using APM.

Wonder if it's sufficient to just have the index name e.g. transaction instead of transactionIndices as that translated better into the user role management UI.

[cauemarcondes]

I added in copy around what indices the user role is missing access to.

Updated the general copy as well a bit;

We’ve detected your current role in Kibana does not grant you access to the APM data. Please check with your Kibana administrator to get the proper privileges granted to start using APM.

Wonder if it's sufficient to just have the index name e.g. transaction instead of transactionIndices as that translated better into the user role management UI.

Thanks @formgeist. Some points:

• If the user doesn't change the APM default index pattern, apm-*, we won't be able to identify which indices are missing.
• We have changed the escape hatch link to Dismiss warning because we don't have the page title available, I started using the breadcrumb but it turned out to not be a good idea because it can sometimes be the transaction name depending on the page the user tried to open.

[formgeist]

If the user doesn't change the APM default index pattern, apm-*, we won't be able to identify which indices are missing.

You mean if they do change the default index pattern? I reckon we just omit the "missing indices permissions" list in that case.

We have changed the escape hatch link to Dismiss warning because we don't have the page title available, I started using the breadcrumb but it turned out to not be a good idea because it can sometimes be the transaction name depending on the page the user tried to open.

That's fair - I think "Dismiss" is enough copy for that link.

[cauemarcondes]

If the user doesn't change the APM default index pattern, apm-*, we won't be able to identify which indices are missing.

You mean if they do change the default index pattern? I reckon we just omit the "missing indices permissions" list in that case.

We have changed the escape hatch link to Dismiss warning because we don't have the page title available, I started using the breadcrumb but it turned out to not be a good idea because it can sometimes be the transaction name depending on the page the user tried to open.

That's fair - I think "Dismiss" is enough copy for that link.

Yes, I meant "they do change". But I'll omit it in that case. And since we won't show the indices, does it make sense to show the escape hatch?

[formgeist]

And since we won't show the indices, does it make sense to show the escape hatch?

I think the "escape hatch" was thought of as we're not going to block users from accessing the APM UI even if they don't have any data to read, so I'd prefer to keep it even if we can't list the missing permissions for the user.

[sqren]

Wonder if it's sufficient to just have the index name e.g. transaction instead of transactionIndices as that translated better into the user role management UI

Instead of saying "transactionIndices" or "transaction" I think we should specifically say which indicies the user doesn't have access to eg apm-*-transaction-*. By default they'll all beapm-* in which case we should remove duplicates and just say: "The user doesn't have access to apm-* whcih is required to use APM UI".

WDYT?

[cauemarcondes]

Wonder if it's sufficient to just have the index name e.g. transaction instead of transactionIndices as that translated better into the user role management UI

Instead of saying "transactionIndices" or "transaction" I think we should specifically say which indicies the user doesn't have access to eg apm-*-transaction-*. By default they'll all beapm-* in which case we should remove duplicates and just say: "The user doesn't have access to apm-* whcih is required to use APM UI".

WDYT?

I like the idea @sqren, maybe, in this case, we should show a list instead of each index split by comma. @formgeist thoughts?

[formgeist]

So something along these lines?

[sqren]

So something along these lines?

I want thinking something like:

---

You do not have access to the following APM indices:

• apm-*-transaction-*
• apm-*-span-*
• apm-*-metric-*

---

[formgeist]

Alright, so like

[cauemarcondes]

@sqren Correct me if I'm wrong, please. But there will be a couple of scenarios depending on if the user changed the default index(apm-*).

1) The user doesn't change the default index:
result: The user doesn't have access to apm-* which is required to use APM UI
2) The user changes only a specific index and leaves the other as default:
Transaction index: apm-transaction-index (read privileges equals false)
Other indices: apm-*
Result: ?
3) The user leaves only one index as default:
Transacion index: apm-transaction-index (read privileges equals false)
Span index: apm-span-index (read privileges equals false)
Error index: apm-error-index (read privileges equals false)
Metrics index: apm-*
Result ? (I believe it will be the same as item 2)
4) All indices were changed:
Result: Missing indices permissions: ...

Any other?

[sqren]

I think we should just always list the indices that the user doesn't have access to, and omit duplicates. Meaning all those cases are the same.

Scenario 1
Missing index permissions:

• apm-*

Scenario 2
Missing index permissions:

• apm-*-transaction-*
• apm-*

Scenario 3
Missing index permissions:

• apm-*-transaction-*
• apm-*-span-*
• apm-*-error-*
• apm-*

Scenario 4
Missing index permissions:

• apm-*-transaction-*
• apm-*-span-*
• apm-*-error-*
• apm-*-metric-*