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.

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

[Fleet] Reusable integration policies #75867

Closed
12 tasks done
ruflin opened this issue Aug 25, 2020 · 27 comments
Closed
12 tasks done

[Fleet] Reusable integration policies #75867

ruflin opened this issue Aug 25, 2020 · 27 comments
Labels
QA:Validated Issue has been validated by QA Team:Fleet Team label for Observability Data Collection Fleet team v8.15.0

Comments

@ruflin
Copy link
Contributor

ruflin commented Aug 25, 2020

Currently each integration policy belongs to a specific Agent policy. It is not possible to reuse the same policy in multiple agent policies. Having support for this would be useful in a few cases:

  • Having a single system policy to collect data about the system and reuse it in Agent specific to Apache or MySQL servers
  • Have a single endpoint policy used for different Agent policies

As discussed in the design doc, we landed on a proposal to make all integration policies reusable with any number of agent policies.
Technically this means changing the 1:1 relationship of agent policy - integration policy to 1:N. Integration policies will store a list of agent policy ids to reference agent policies.
The full agent policy sent to the agents will contain the inputs from all integration policies that reference it.
The UI and API will be adjusted to support linking an integration policy to many agent policies.

Implementation plan

  1. QA:Needs Validation Team:Fleet
    juliaElastic
  2. QA:Needs Validation Team:Fleet
    criamico
  3. QA:Needs Validation Team:Fleet
    criamico
  4. QA:Needs Validation Team:Fleet
    juliaElastic
  5. QA:Needs Validation Team:Fleet
    criamico
  6. QA:Needs Validation Team:Fleet
    criamico
  7. Team:Fleet
    juliaElastic
  8. QA:Validated Team:Fleet bug impact:medium
    juliaElastic

As a follow-up, we should support "orphaned" integration policies that don't belong to an agent policy.

Design solution

Reach out to @simosilvestri for implementation support.

Figma file / Prototype/UX issue

New UX Criteria

Add/Edit integration wizard

Screenshot 2024-05-29 at 15 10 53
  • Ability to edit selected agent policies -> Prototype link
  • Confirmation dialog to show possible dependencies
Screenshot 2024-05-29 at 15 13 46 Screenshot 2024-06-05 at 14 22 09

Integration policies table > Agent policy tab -> Prototype link

  • Display the policy badge inline on the table based on the column width.
  • The number of policies trimmed in the column opens a popover with a full list of clickable agent policies.
  • Customers can manage agent policies that share the same integration.
  • Make the agent policy badges clickable, linking to the agent policy details page in Fleet.
Screenshot 2024-05-29 at 15 52 03 Screenshot 2024-06-05 at 14 47 24 Screenshot 2024-06-05 at 14 46 29

Fleet > Agent policy > Integration tab

  • The integration name shows a shared label with an info tooltip to communicate to the user the number of policies shared with that integration.
Screenshot 2024-05-29 at 15 57 22

Workflow

Select a reusable policy

When a user adds an integration to an Agent policy, if there are existing reusable policies for this integration, the user gets shown an option to select one. On selection a summary could be shown but the user cannot edit it.

Create reusable policy

As a reusable policy can only be created outside an Agent Policy, a new place and workflow is needed to create an manage these.

Editing reusable policy

A policy that is used in multiple agent policies should have a special indicator in the policy list. If the user wants to edit the policy, not the standard edit screen is shown but one that makes it obvious this policy is used in multiple places. It should be visible which other agent policies use the same policy. On save it must be shown how many other Agent policies this change effects.

Technical details

On the technical side, I expect that the package policy is referenced in the agent policy by id. This id can be used in multiple places. The policy itself is not tied to a config and can also exist without an assigned agent policy. If a user removes a reusable policy from an Agent Policy, the reusable policy will continue to exist. A reusable policy can only be deleted if 0 agent policies use it.

@ruflin ruflin added the Team:Fleet Team label for Observability Data Collection Fleet team label Aug 25, 2020
@elasticmachine
Copy link
Contributor

Pinging @elastic/ingest-management (Team:Ingest Management)

@jen-huang jen-huang changed the title [Ingest Manager] Reusable policies [Ingest Manager] Reusable integration policies Aug 25, 2020
@ph
Copy link
Contributor

ph commented Aug 25, 2020

@ruflin the Reusable Integration Policy (RIP nice acronym) is linked in the agent policy? I think it makes sense when you edit and save the reusable integration policy that you can either modify it which will apply the changes to all the Agent Policy or
copy and only have the configuration applied to the current Agent policy.

This is similar to the behavior you have when you work with Symbols in Sketch.

@ph
Copy link
Contributor

ph commented Aug 25, 2020

The above effectively allow you to change you mind have and have the copy behavior from #75868

@ruflin
Copy link
Contributor Author

ruflin commented Aug 26, 2020

@ph Yes, the policy is referenced in the agent policy. For the option to also copy, don't see any problem with that but would say that this is an additional feature.

@mostlyjason
Copy link
Contributor

We discussed something similar to this a few months ago called shared data sources. There is an old google doc discussing some details.

@SHolzhauer
Copy link

Would you be able to create a reusable policy with another reusable policy? Effectively creating the structure I am looking for in #76640 ?

@ruflin
Copy link
Contributor Author

ruflin commented Sep 8, 2020

@SHolzhauer No, it would be more like the following:

- apache
  - linux system
  - webserver
  - apache

- tomcat
  - linux system
  - webserver
  - tomcat
  
- proxies
  - linux system
  - proxy

- linux
  - linux system

Each sub block is a reusable entry.

@SHolzhauer
Copy link

Trying to wrap my head around this, but I believe this would still solve the use-case. Going to close the other issue in favor of this one.

@jen-huang jen-huang changed the title [Ingest Manager] Reusable integration policies [Fleet] Reusable integration policies Apr 27, 2021
@runejuhl
Copy link

Sorry for the noise, but it's been 2.5 years since the last comment -- are there any plans to implement this feature?

@Fabien4941
Copy link

Fabien4941 commented Mar 1, 2023

We have exactly the same need.

Example of our policies:

Server type A:

  • System
  • Docker
  • Custom Logs

Server type B:

  • System
  • Docker

Server type C :

  • System

"System" integrations are strictly identical in each policy. When a modification is made to one of the policies, it must be manually transferred to all the others, it is not convenient. Especially when the number of policies increases.

@renzedj
Copy link

renzedj commented Mar 1, 2023

We have exactly the same need.
...
"System" integrations are strictly identical in each policy. When a modification is made to one of the policies, it must be manually transferred to all the others, it is not convenient. Especially when the number of policies increases.

Same here. We just identified a need to add something to our system policy across our entire environment. I'm going to have to apply this manually to approximately 60 policies, with all the potential for error and time commitment that implies.

@SHolzhauer
Copy link

This is something that is still blocking our migration to Agent!

@dcarltonafs
Copy link

dcarltonafs commented Nov 30, 2023

Also following this thread for our implementation of fleet. I might be getting twisted around here but it seems each thread in 75867, 75868, and 76640 closes in a cyclical favor of one of the other two threads. Any idea if either integration policy copying or a single integration policy being applied to multiple agent-policies (preferred) is on the horizon? If not, could an explanation be put out on how to use API calls to create a new policy with the same configuration? Rather than using integration policy names the API seems to automatically assign uuid's so I don't see how we can use API calls to copy configurations right now.

@nicpenning
Copy link

Any progress being made here? Over time more and more policies with slight changes are occurring and starting to sprawl out of control.

@zez3
Copy link

zez3 commented Apr 17, 2024

@nchaulet can you or @kpollich please update us on this ER?

@kpollich
Copy link
Member

kpollich commented Apr 17, 2024

(Edit: I'm updating my comment to be a little less committal, as priorities can shift. See the edit history for my previous comment.)

This work is prioritized and the product definition is nearly complete. We'll be working on finalizing the technical implementation details in the coming weeks. We'll reuse this issue for the technical implementation details so look for an updated description that lays out the implementation in the near future.

@juliaElastic
Copy link
Contributor

@kpollich Added the implementation plan to this issue, the last few tasks are WIP, asked a few clarifying questions on the doc from Nima.

@kpollich
Copy link
Member

kpollich commented May 7, 2024

@juliaElastic - After talking with @nimarezainia, I moved the "orphaned" integration policy work out of the main implementation plan. We can tackle that work in a follow-up as it's a less common use case.

@juliaElastic
Copy link
Contributor

@kpollich I think #182222 is still needed for the first phase, because by default all integration policies would be deleted when an agent policy is deleted.

@cmacknz
Copy link
Member

cmacknz commented Jun 4, 2024

We need to stress test this feature to determine how it impacts the maximum number of agent policies we support.

@criamico
Copy link
Contributor

criamico commented Jul 2, 2024

Found this bug while testing the new feature: #187331

juliaElastic added a commit that referenced this issue Jul 9, 2024
## Summary

Relates #75867

Change to `Agent policy` to `Agent policies` in a few places.

<img width="1154" alt="image"
src="https://github.com/elastic/kibana/assets/90178898/52ea19ea-6302-44b8-88b2-54abd6a4ec37">
<img width="1405" alt="image"
src="https://github.com/elastic/kibana/assets/90178898/503844c5-d9ec-4bdf-a2d3-aeb4e9100764">
<img width="1409" alt="image"
src="https://github.com/elastic/kibana/assets/90178898/9149bf6f-c9fa-4535-ab7b-c4ff4df35dca">


### Checklist

- [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

Available in 8.15 behind a feature flag. @kpollich can i close this? PRs for telemetry are available.

@kpollich
Copy link
Member

kpollich commented Jul 19, 2024

Yes let's close this. The feature flag is enabled by default in 8.16 as of #186175.

criamico added a commit that referenced this issue Jul 19, 2024
Part of #75867

Depends on merging first elastic/telemetry#3759

## Summary

Define new telemetry hourly job for reusable policies; Example of data:
```
   {
        total_integration_policies: 3,
        shared_integration_policies: 2,
        shared_integrations: {
          agents: 10,
          name: 'aws-1',
          pkg_name: 'aws',
          pkg_version: '1.0.0',
          shared_by_agent_policies: 3,
        }
```


### Checklist
- [ ] [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

---------

Co-authored-by: Elastic Machine <[email protected]>
@nicpenning
Copy link

Wow, 4 years in the making. This is huge! 🥳

@amolnater-qasource
Copy link

Hi Team,

We have created 15 testcases under Testmo for this feature under Fleet test suite under below Section:

Please let us know if any other scenario needs to be added from our end.

Thanks!

@amolnater-qasource
Copy link

Hi Team,

We have executed 18 testcases under the Feature test run for the 8.16.0 release at the link:

Status:

PASS: 18

Build details:
VERSION: 8.16.0 BC2
BUILD: 79434
COMMIT: 59220e9

As the testing is completed on this feature, we are marking this as QA:Validated.

Please let us know if anything else is required from our end.
Thanks

@amolnater-qasource amolnater-qasource added the QA:Validated Issue has been validated by QA label Oct 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
QA:Validated Issue has been validated by QA Team:Fleet Team label for Observability Data Collection Fleet team v8.15.0
Projects
None yet
Development

No branches or pull requests