Allow users with read access to view Integrations app

[joshdover]

Summary

Fixes #94322

This makes the following changes:

• Removes the superuser requirement from the Integrations app
• Hides the "Policies" and "Settings" tabs from the Integration detail view for read-only users
• Filters the "Assets" tab based on what the user has privileges to access
• Adds tooltip for users without enough privileges to install an integration
• Adds tooltip and callout for clusters without security enabled + link to guide on what needs to be configured

Release Note

Users without the superuser role may view integrations and their assets in the Integrations app if they have "read" permissions for Fleet & Integrations.

Checklist

Delete any items that are not applicable to this PR.

• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Documentation was added for features that require explanation or tutorials
• Unit or functional tests were updated or added to match the most common scenarios
• Any UI touched in this PR is usable by keyboard only (learn more about keyboard accessibility)
• Any UI touched in this PR does not create any new axe failures (run axe in browser: FF, Chrome)
• This renders correctly on smaller devices using a responsive layout. (You can test this in your browser)
• This was checked for cross-browser compatibility

For maintainers

• This was checked for breaking API changes and was labeled appropriately

[mostlyjason]

@joshdover Thanks for thinking through this scenario. We didn't define it in our doc but its important to consider because self-managed clusters do not have security enabled by default. I want to make sure I understand your proposal. Today when a user starts a self-managed cluster, security is disabled by default. When they visit the integrations page, they see the list of elastic agent integrations but get an error if they lack superuser or security is not enabled. In this PR, you are proposing that when this user visits the integrations page they do not see any elastic agent integrations nor any notice that they are missing integrations? If so, that seems like a regression since they lose visibility to both the integrations and the requirements to enable them. I'm worried that a large percentage of users in new self-managed clusters will be unaware that they are losing visibility.

One option is consistent with our design for when the user lacks privileges to add agent integrations. We show a read-only mode, disable the add integration button and potentially add hovertext to explain that they need to enable security. The advantage is that users get visibility to the full set of integrations and a message explaining how to enable them. If they are not interested in using Elastic Agent integrations they can use the filter on the browse tab or clear the EPR URL.

A second option is to show a info box similar to when EPR is not accessible. This tells the user they need to enable security to see the full set of integrations. In this case, users get defaulted to Beats automatically. However, I'm not sure that users with security disabled necessarily prefer Beats over Elastic Agent. It could just be they didn't around to enabling security yet, but they intend to do so eventually.

I prefer the first option since it offers more visibility to agent integrations, but curious what you and @alexfrancoeur think too.

[joshdover]

In this PR, you are proposing that when this user visits the integrations page they do not see any elastic agent integrations nor any notice that they are missing integrations? If so, that seems like a regression since they lose visibility to both the integrations and the requirements to enable them. I'm worried that a large percentage of users in new self-managed clusters will be unaware that they are losing visibility.

Good point on losing discoverability of integrations here. My thinking was that it wasn't a regression since they already couldn't access them, but you are right that we would be removing one key way to discover that Elastic Agent integrations exist.

Poking around a bit more in the code, I'm not too worried about the scope required to support either of the experiences you suggest above. If anything, option (1) is easier. I do wonder if we'd be making things confusing with option (1) since most of the tiles shown to the user in this case wouldn't be actionable for them unless they enable security. Could that reduce ingestion rates for on-prem clusters in 7.16?

One option could be to make the Agents vs. Beats toggle switch persisted for the user in localStorage so that they can see the view that makes the most sense for them.
EDIT: I see that this is already part of the scope for that toggle

[mostlyjason]

Thinking through this again, I'd love to provide users a link to documentation so they can discover how to enable security. Its not an easy or intuitive process. We have a full page banner in Fleet with links to docs, but not in the Integrations app.

@dborodyansky
what are your thoughts on how to show a message with a docs link when security needs to be enabled?

[mostlyjason]

Just had talk with Dmitry and he's going to take this on. Also, it looks like the security check in Fleet is only partially enabled since its implemented in the wrong order #83001. We also need to add an API key check.

[joshdover]

Just had talk with Dmitry and he's going to take this on. Also, it looks like the security check in Fleet is only partially enabled since its implemented in the wrong order #83001. We also need to add an API key check.

Great, makes sense. I'll update this PR to support the following in both scenarios (where security is disabled in ES only and where security is disabled in Kibana and ES):

• Integrations app is visible and functional
• EPR packages are included in integrations grid
• UI is displayed as if user is superuser:
  • The "Add integration" button is visible and enabled (clicking leads to security disabled UI)
  • Only the overview tab is displayed on integrations detail view
• Clicking on any actions that lead to an API that requires superuser shows an error about not having superuser (which will be improved by [Fleet] Display security checks when security is disabled #83001 to instead show the instructions for enabling security requirements)

We can then leverage the fix for #83001 and add any additional UX improvements for this scenario in a separate PR. Does that make sense to you, @mostlyjason?

[joshdover]

I've pushed up changes to allow the same behavior regardless of how security is disabled (in ES, or ES and Kibana). @mostlyjason let me know if the plan I proposed above works and we can set this to ready for review.

[dborodyansky]

@mostlyjason @joshdover Please let me know if I understood this correctly. My assumptions are limitations result in inability to add an integration. Limitations include:

1. Security being disabled, which may be remedied by the user with doc guidance.
2. Privilege limitations, which require administrator assist.

With this in mind, what do you think of the following proposal:

[mostlyjason]

Thanks @dborodyansky! We should only show the tabs and actions appropriate for read-only mode of the UI. You can read up on those requirements in my google doc titled "Allow non-superusers to access the integrations app". Also, where does the "Steps in this guide" link to? Does it handle both security being disabled and the API key being disabled?

@joshdover I'd modify your proposal for when security is disabled in this way

• UI is displayed as if user is a read only user:
  • The "Add integration" button is disabled
  • Only the overview tab and asset tabs are displayed on integrations detail view
• The user is not allowed to click on any actions that require superuser
• API calls that requires superuser shows an error about not having superuser (or about not having security enabled)
• Include Dmitry's designs

[joshdover]

• UI is displayed as if user is a read only user:
  • The "Add integration" button is disabled
  • Only the overview tab and asset tabs are displayed on integrations detail view
• The user is not allowed to click on any actions that require superuser
• API calls that requires superuser shows an error about not having superuser (or about not having security enabled)

All of this is already covered in this PR for read-only users. The only difference here when security is disabled is that the Asset tab won't be present (since integrations can't be installed), so they'll only see the Overview tab.

• Include Dmitry's designs

👍

[joshdover]

@dborodyansky @mostlyjason a few questions related to the designs:

• Should the "follow this guide" link just send the user to /app/fleet where the user will see the instructions once [Fleet] Display security checks when security is disabled #83001 is fixed?
• FYI when security is disabled, there's no way of telling if the user (since there is no user) is someone who has access to the cluster's configuration. So I can't differentiate between the top-right and bottom-right situations. Maybe we should use copy on the tooltip that covers both cases?

[mostlyjason]

@joshdover I think if security is disabled then they cannot log in as a superuser role, so the top right use case is not possible. The bottom left indicates the next step they need to take.

I think it'd be fine to link to Fleet to show the dialog. We need to make sure the two checks align so the user doesn't get redirected and see nothing.

[dborodyansky]

Does the following look accurate?

[joshdover]

I think if security is disabled then they cannot log in as a superuser role, so the top right use case is not possible. The bottom left indicates the next step they need to take.

++ this is what I was trying to explain, but this was more clearly put 😅

Does the following look accurate?

Yes, thanks all. I'll have this in review tomorrow.

[elasticmachine]

Pinging @elastic/fleet (Team:Fleet)

[kpollich]

LGTM 🚀 - Created a read-only user w/ the viewer role in Kibana and was able to view integrations on this branch.

[thomasneirynck]

lgtm

can confirm:

• created user with viewer-role
• can access integration page
• cannot install an AWS package
• tooltip shows with extra info
• asset-tab is hidden (except when package is installed)

Wasn't sure how to verify the callout for missing security-enablement.

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: ff0052d
• Storybooks Preview
• Documentation Changes

Metrics [docs]

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
fleet	630.2KB	630.7KB	+499.0B

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
fleet	104.9KB	105.0KB	+142.0B

History

• 💔 Build #160388 failed 32c1b82
• 💔 Build #160381 failed 93dabe2
• 💔 Build #159961 failed 018dc91
• 💚 Build #159936 succeeded 4c63d256a28a5892dd700e2bba4dce47dad0d4d2
• 💔 Build #158471 failed ca47ad1d54e0761a30a35196d9612f1060c7221b

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

[kibanamachine]

💔 Backport failed

Status	Branch	Result
❌	7.x	Commit could not be cherrypicked due to conflicts

To backport manually run:
node scripts/backport --pr 113925

[thomasneirynck]

this backport is failing because we're backed up a little on backports of prereqs. Working through this as we speak. Will create new backport once we're through all the outstanding prereqs (this one likely #114432 (comment))

[thomasneirynck]

once #114910 merges, I'll backport this one