Skip to content

[Fleet] Add warning if need root integrations trying to be used with unprivileged agents#183283

Merged
juliaElastic merged 37 commits intoelastic:mainfrom
juliaElastic:unprivileged-warning
May 21, 2024
Merged

[Fleet] Add warning if need root integrations trying to be used with unprivileged agents#183283
juliaElastic merged 37 commits intoelastic:mainfrom
juliaElastic:unprivileged-warning

Conversation

@juliaElastic
Copy link
Copy Markdown
Contributor

@juliaElastic juliaElastic commented May 13, 2024

Summary

Closes https://github.com/elastic/ingest-dev/issues/3252

Add integration

Added warning to Add integration when the integration requires root privilege and the selected existing agent policy has unprivileged agents enrolled.

To verify:

  • enroll an agent with docker (it has unprivileged: true)
  • try to add an integration that requires root e.g. auditd_manager
  • verify that when trying to save the integration, the warning callout is part of the confirm deploy modal
image

Add agent flyout

Added warning to Add agent flyout when an unprivileged agent is detected in combination with an agent policy that has integrations requiring root

To verify:

  • add an integration to an agent policy that requires root e.g. auditd_manager
  • open Add agent flyout, verify that the warning callout is visible
image

Open question:

  • Do we want to show the warning on Add agent flyout only for newly enrolled agents (in the last 10 mins like we query enrolled agents), or any unprivileged agents that are enrolled to this policy?
    • Decision: No longer applicable as we decided to not show a count here

Checklist

@juliaElastic juliaElastic added the release_note:feature Makes this part of the condensed release notes label May 13, 2024
@juliaElastic juliaElastic self-assigned this May 13, 2024
@ghost
Copy link
Copy Markdown

ghost commented May 13, 2024

🤖 GitHub comments

Expand to view the GitHub comments

Just comment with:

  • /oblt-deploy : Deploy a Kibana instance using the Observability test environments.
  • run docs-build : Re-trigger the docs validation. (use unformatted text in the comment!)

@juliaElastic
Copy link
Copy Markdown
Contributor Author

/ci

@juliaElastic
Copy link
Copy Markdown
Contributor Author

/ci

@juliaElastic
Copy link
Copy Markdown
Contributor Author

/ci

@juliaElastic juliaElastic marked this pull request as ready for review May 14, 2024 08:45
@juliaElastic juliaElastic requested a review from a team as a code owner May 14, 2024 08:45
@juliaElastic
Copy link
Copy Markdown
Contributor Author

/ci

@botelastic botelastic bot added the Team:Fleet Team label for Observability Data Collection Fleet team label May 14, 2024
@elasticmachine
Copy link
Copy Markdown
Contributor

Pinging @elastic/fleet (Team:Fleet)

@juliaElastic juliaElastic requested a review from a team as a code owner May 14, 2024 11:19
Copy link
Copy Markdown
Member

@kilfoyle kilfoyle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM for the text! 👍

</>
)}
{isConfirmModalOpen ? (
<UnprivilegedConfirmModal
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm going to add UI tests

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

above in this file, there is another modal nested under formState === 'CONFIRM'

I'm concerned about potential conflicts with that modal since this one is outside of that conditional. can formState be part of the condition for opening this modal?

btw, if we continue to use isConfirmModalOpen, it should probably be renamed because there are multiple confirm modals in this flow and this is only for the unprivileged modal

Copy link
Copy Markdown
Member

@nchaulet nchaulet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 🚀

@juliaElastic juliaElastic requested a review from jloleysens May 16, 2024 12:34
Copy link
Copy Markdown
Contributor

@jen-huang jen-huang left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few UX suggestions.

For the Add agent flyout, I think it would be good to also notify the user before the attempt installation that the selected policy needs privileged agents. How about we put this just before the installation commands code block? That way it can appear on the standalone agent installation instructions too:

image

onCancel={() => setFormState('VALID')}
/>
)}
{isUnprivilegedModalOpen && !(formState === 'CONFIRM' && agentPolicy) ? (
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

when I add auditd to an existing policy with an unprivileged agent is such that I get this modal first, I click Add integration, and I get the second Save and deploy changes confirmation modal. this seems like a UX anti-pattern.

is it possible to merge these two modals? since both modals are conditional on if there are already agents enrolled into the selected policy, we could have the unprivileged warning callout below the blue callout if there are some unprivileged agents:

image

WDYT? and sorry for the review churn - I should have commented on this behavior in my initial review 😅

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, showing two modals is not ideal indeed. I'll update.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Merged the two modals:
image

@juliaElastic
Copy link
Copy Markdown
Contributor Author

juliaElastic commented May 17, 2024

For the Add agent flyout, I think it would be good to also notify the user before the attempt installation that the selected policy needs privileged agents. How about we put this just before the installation commands code block? That way it can appear on the standalone agent installation instructions too:

Good point, I'll move it.
I think we should eventually add to the instruction how to enroll an agent in unprivileged mode.

I moved the callout before the install commands, do we still want to show how many unprivileged agents are enrolled? If there are no unprivileged agents yet, we can show a generic warning:

image

If there are unprivileged agents:
image

@kpollich
Copy link
Copy Markdown
Member

do we still want to show how many unprivileged agents are enrolled?

I don't know how useful the count is in this scenario without also listing out each agent ID or something along those lines. Maybe we can opt to exclude it for now and revisit this callout with some technical writing/UX eyes. One thing that comes to mind: would we want to give the user a link to a pre-filtered agents table view that shows the agents in question so they can take action and then come back to the enrollment flow? As it stands, I think unless we are providing clear call to actions this callout is mainly informative, and we're not driving the user to take action. This is okay for the initial scope here, imo.

@juliaElastic - would it be possible to render the list of integrations in a <ul> instead of as a comma separate string? I foresee an edge case where there 10+ integrations that fall into this case on a large policy and callout starts to look a bit messy. We could put the list of offending integrations after the main callout text, maybe with some wording tweaks e.g.

This agent policy contains the following integrations that require Elastic Agents to have root privileges.
To ensure that all data required by the integrations can be collected, reenroll the agents using an account with root privileges. 

- Auditd Manager
- ...
- ...

@juliaElastic
Copy link
Copy Markdown
Contributor Author

juliaElastic commented May 17, 2024

I don't know how useful the count is in this scenario without also listing out each agent ID or something along those lines. Maybe we can opt to exclude it for now and revisit this callout with some technical writing/UX eyes. One thing that comes to mind: would we want to give the user a link to a pre-filtered agents table view that shows the agents in question so they can take action and then come back to the enrollment flow? As it stands, I think unless we are providing clear call to actions this callout is mainly informative, and we're not driving the user to take action. This is okay for the initial scope here, imo.

Thanks for the suggestions, I agree that it's not that useful to show the count of unprivileged agents if not actionable. I'll remove it for now. cc @nimarezainia

I'll change the callout to show a list of integrations.

Updated:
image

@juliaElastic juliaElastic requested a review from jen-huang May 17, 2024 13:53
Copy link
Copy Markdown
Contributor

@jen-huang jen-huang left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The UI changes look great, thanks for making them @juliaElastic :)
Agree with the decision to remove the count from agent enrollment flyout.

I pulled the screenshots you provided to the PR description.

I tested locally 👍

@nimarezainia
Copy link
Copy Markdown
Contributor

I moved the callout before the install commands, do we still want to show how many unprivileged agents are enrolled? If there are no unprivileged agents yet, we can show a generic warning:

IMO it doesn't hurt to show the number of agents. More information is always better. Also could help with troubleshooting if there are issues.

@juliaElastic
Copy link
Copy Markdown
Contributor Author

IMO it doesn't hurt to show the number of agents. More information is always better. Also could help with troubleshooting if there are issues.

I would leave it as is for now, we can adjust the UI later if needed.

@juliaElastic juliaElastic enabled auto-merge (squash) May 21, 2024 07:10
@kibana-ci
Copy link
Copy Markdown

💚 Build Succeeded

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id before after diff
fleet 1011 1013 +2

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id before after diff
fleet 1187 1188 +1

Async chunks

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

id before after diff
fleet 1.3MB 1.3MB +4.0KB

Page load bundle

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

id before after diff
fleet 164.4KB 164.6KB +189.0B
Unknown metric groups

API count

id before after diff
fleet 1308 1309 +1

History

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

cc @juliaElastic

@juliaElastic juliaElastic merged commit ad03dfb into elastic:main May 21, 2024
@kibanamachine kibanamachine added v8.15.0 backport:skip This PR does not require backporting labels May 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

backport:skip This PR does not require backporting release_note:feature Makes this part of the condensed release notes Team:Fleet Team label for Observability Data Collection Fleet team v8.15.0

Projects

None yet

Development

Successfully merging this pull request may close these issues.