Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[Fleet] Make reusable integration policies and space awareness work together #190727

Closed
4 tasks
nchaulet opened this issue Aug 19, 2024 · 7 comments
Closed
4 tasks

[Fleet] Make reusable integration policies and space awareness work together #190727

nchaulet opened this issue Aug 19, 2024 · 7 comments
Assignees
@nchaulet
Labels
Team:Fleet Team label for Observability Data Collection Fleet team

Comments

@nchaulet
Copy link
Member

nchaulet commented Aug 19, 2024 •
edited by jen-huang
Loading

Description

Make reusable integration policies and space awareness work together, we should make sure those features works well together, place where we can have potential issues:

  • Moving agent policies, (we also update the space of related integration policies here, we should have a special handling)
  • Bumping agent policies after updating an integration policy (be sure we search agent policies across all spaces)
  • Deleting a shared integration policy, should delete it from all integration policies.
  • Allow users to find integration policies that don't belong to any agent policies

We should write test in x-pack/test/fleet_api_integration/apis/space_awareness for those use case with reusable integration policies.

Questions

What permissions a user should have to update a integration policy shared through multiple space?
@nchaulet nchaulet added the Team:Fleet Team label for Observability Data Collection Fleet team label Aug 19, 2024
@elasticmachine
Copy link
Contributor

Pinging @elastic/fleet (Team:Fleet)

@nimarezainia
Copy link
Contributor

Do we need to have a selector on the integrations policies (just like the agent policy) which would allow the user to explicitly assign the integration to a space?

We need to accommodate the use case where an organization has multiple lines of business and they need to segregate the teams from one another. For example in the diagram below there may be a security team that would own the Defend integration. They would not want the webserver team (who owns NGINX integration as an example) to have the ability to read/write their integration.

image

this potentially could be addressed by the integration defaulting to the space in which is was created in. However having the flexibility to change the space assigned to an integration would be important - especially when an operator is creating and assigning these integrations.

@nchaulet
Copy link
Member Author

nchaulet commented Aug 20, 2024 •
edited
Loading

Do we need to have a selector on the integrations policies (just like the agent policy) which would allow the user to explicitly assign the integration to a space?

It could be a good idea, it will probably add some complexity.
For in your example the Defend integration will only be assigned to the SA space, so users in DeptA/DeptB will not see that integration is part of their Agent policy A? or they will see an incomplete integration like just the name and package?
Also retrieving the full policy for standalone agents for example will still contains the Defend integration right?

Could a first step, while we think more about this, could be to limit policies with reusable integration to not belong to multiple space/and disable the changing space for those?

@jen-huang jen-huang mentioned this issue Aug 21, 2024
Merged
4 tasks
jen-huang added a commit that referenced this issue Aug 28, 2024
@jen-huang
[UII] Support integration policies without agent policy references (a…
c9d8292 
…ka orphaned integration policies) (#190649)

## Summary

Resolves #182220.

This PR allows integration polices to be saved without being added to
any agent policies. These integration policies can be considered
"orphaned." Through the API, an empty `policy_ids: []` array can be
passed during create operations to add it to no agent policies. The same
empty array can be passed during update operations to clear it from all
previous agent policies. Clearing agent policies references this way
will also set the deprecated `policy_id` field to `null`.

Clearing agent policy references requires the same licensing as the
general reusable integration policies feature.

I spotted a bug where removing one or more agent policy references does
not bump their revision. Revision was only bumped for only newly added
references This has been fixed in this PR as well.

On the UI side, orphaned integration policies can only be discovered on
the Integrations details > Policies table:

<img width="1388" alt="image"
src="https://github.com/user-attachments/assets/bcaeb4e7-629a-4ce6-81df-a48a997ed85d">


Agent policies can be unattached in the manage agent policies modal:

<img width="1068" alt="image"
src="https://github.com/user-attachments/assets/7efd48a8-1466-48ee-a48d-18cfbcc4a9a6">


Integration policy create/edit form allows agent policies field to be
cleared, with a confirmation modal as a heads up to the user. If the
user previously had agent policies attached, and is now clearing it, the
normal `This action will update the selected agent policies` will be
shown:

<img width="1108" alt="image"
src="https://github.com/user-attachments/assets/1eade1d1-a456-4d2d-a85f-65801ec55857">


### Checklist

- ~~Consider interaction with space aware policies~~ Will be done in
#190727
- [x] Test with integrations that register custom policy editors
- [x] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)
- [ ]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
  - Will be done in elastic/ingest-docs#1261
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
@nimarezainia
Copy link
Contributor

Could a first step, while we think more about this, could be to limit policies with reusable integration to not belong to multiple space/and disable the changing space for those?

I think as a first step that is fine. My fear is that (just as before) there will be a use case that comes up with some one needing multiple space support.

@nchaulet I wanted to clarify whether dashboards belonging to an integration would also have that space context? (after this change)
say we have teams A and B in spaces A & B.

  • Team A in space A adds integration X
  • Team B in space A adds integration Y
  • Integration X (settings and dashboards) are not visible to Team B
  • vice versa Integration Y (settings and dashboards) are not visible to Team A

@nchaulet
Copy link
Member Author

nchaulet commented Sep 9, 2024

@nimarezainia integration are installed globally in every space (except for dashboard) but if the team A and B has the permissions to install integrations they both will be to install the dashboard part in the space A and B and will access the dashboard for both integration.

In your example the agent policy will belong to space A and B, but the integration policy X only to space A and the integration policy Y only to space B correct?

In a case of a space move for the agent policy, what should be the behaviour here for the integration policies?

@nchaulet
Copy link
Member Author

I was thinking about this what about the full policy, even if a user from space B did not added the integration X they will see the integration when retrieving the full agent policy

This was referenced Sep 26, 2024
Closed
Open
@nchaulet
Copy link
Member Author

I think we can close this on in favor of those those two implementation issues:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@nchaulet nchaulet

Labels
Team:Fleet Team label for Observability Data Collection Fleet team
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@nchaulet @nimarezainia @elasticmachine