[Fleet] Add warning if need root integrations trying to be used with unprivileged agents#183283
Conversation
🤖 GitHub commentsExpand to view the GitHub comments
Just comment with:
|
|
/ci |
|
/ci |
|
/ci |
|
/ci |
|
Pinging @elastic/fleet (Team:Fleet) |
| </> | ||
| )} | ||
| {isConfirmModalOpen ? ( | ||
| <UnprivilegedConfirmModal |
There was a problem hiding this comment.
I'm going to add UI tests
There was a problem hiding this comment.
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
...cy/create_package_policy_page/multi_page_layout/components/page_steps/install_agent/types.ts
Outdated
Show resolved
Hide resolved
jen-huang
left a comment
There was a problem hiding this comment.
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:
| onCancel={() => setFormState('VALID')} | ||
| /> | ||
| )} | ||
| {isUnprivilegedModalOpen && !(formState === 'CONFIRM' && agentPolicy) ? ( |
There was a problem hiding this comment.
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:
WDYT? and sorry for the review churn - I should have commented on this behavior in my initial review 😅
There was a problem hiding this comment.
Good point, showing two modals is not ideal indeed. I'll update.
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 |
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. |
jen-huang
left a comment
There was a problem hiding this comment.
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 👍
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. |
… src/core/server/integration_tests/ci_checks'
I would leave it as is for now, we can adjust the UI later if needed. |
💚 Build Succeeded
Metrics [docs]Module Count
Public APIs missing comments
Async chunks
Page load bundle
History
To update your PR or re-run it, just comment with: |




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:
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:
Open question:
Add agent flyoutonly for newly enrolled agents (in the last 10 mins like we query enrolled agents), or any unprivileged agents that are enrolled to this policy?Checklist