[Fleet] Add a is_managed field to package policy

[shahzad31]

Summary

This requirement came out of elastic/uptime#475 and it's to support #135782

i separated out in a separate PR to make code review easier.

In synthetics we want to control to synthetics integration policies from Synthetics plugin. When user adds a monitor, we create a respective integration policy in synthetics package. Since that is entirely managed by synthetics plugin, we don't want users to edit those in view. Since source of truth in this case will be uptime monitor saved object.

This PR adds is_externally_managed a flag in policies, which will indicate if this is externally managed integration.

When this flag is set to true, we will disable actions

And also when user is editing, we disable editing and adds a link to uptime

If user has existing synthetics monitors, they will keep working same or if they add them via fleet ui, they will continue working same.

[joshdover]

@shahzad31 How is this functionally different than the is_frozen attribute we already have support for?

[joshdover]

cc @nchaulet I think you would be best to guide this

[elasticmachine]

Pinging @elastic/fleet (Team:Fleet)

[shahzad31]

@shahzad31 How is this functionally different than the is_frozen attribute we already have support for?

i wasn't aware of is_frozen, let me check that out.

[shahzad31]

@shahzad31 How is this functionally different than the is_frozen attribute we already have support for?

i wasn't aware of is_frozen, let me check that out.

i can't find is_frozen option.

[nchaulet]

Hi @shahzad31, I am not sure the is_frozen will totally solve your use case I have a couple of questions (just discovering that issue so maybe these questions can sound dumb :) )

• What block this managed package policy to be edited from the Fleet UI? is there no way to sync Fleet package policy with your saved object using Fleet provided hooks?
• Can the package policy be deleted from Fleet?
• Does some synthetics package policy will be edited from the Fleet UI and some from your plugin?

[shahzad31]

Hi @shahzad31, I am not sure the is_frozen will totally solve your use case I have a couple of questions (just discovering that issue so maybe these questions can sound dumb :) )

Those are totally valid question, and thank you so much for taking a quick look

• What block this managed package policy to be edited from the Fleet UI? is there no way to sync Fleet package policy with your saved object using Fleet provided hooks?

I think it would be complex, potentially it can be done since we control the synthetics fleet ui by custom controllers we have in uptime app. But i don't think we see any value in that. Since we want 100% of our users to interact from monitor management.

• Can the package policy be deleted from Fleet?

No it shouldn't be. User shouldn't be able to delete these externally managed policies from FLeet UI. I think this PR does prevent that. Is there any other way to delete these from fleet UI?

• Does some synthetics package policy will be edited from the Fleet UI and some from your plugin?

So for now yes, since we want our changes to be backward compatible. And user may have existing synthetics policies or may want to ad new from fleet ui. So that means they will be able to edit/delete those from fleet UI.

[elasticmachine]

Pinging @elastic/uptime (Team:uptime)

[kfirpeled]

approved changes to cloud_security_posture plugin

[nchaulet]

I saw potentially a bunch of issues with this that are currently not addressed and we probably need to discuss:

• Managed package policy should probably not be editable in Fleet HTTP API
• How package policy upgrade will work?

I am still trying to understand your saved object and the link to package policy, can you give more info on what do you save in saved object and how|when you transform this in package policy?

[nchaulet]

@shahzad31 as we discussed offline I tried to play with frozen input but it seems too limited for what you want to achieve this allow to have some variable non editable but it does not allow to block package policy deletion.

I think it will make sense to allow the is_externally_managed flag, we already have a similar flag at the agent policy level call is_managed do you mind renaming is_externally_managed => is_managed to be consistant, also I think we need to make a little more changes for managed package policies:

• a managed package policy should not be editable or updatable unless you pass a force flag similar to the agent policy behavior (see here for example https://github.com/nchaulet/kibana/blob/67683c9065758f667fac13834ce005b256adea0c/x-pack/plugins/fleet/server/services/agent_policy.ts#L655-L657)

• In the UI:

  • we should probably disable upgrade and delete in package policy action
  
  • when we edit|view a package policy we should probably disable all the fields and we should show a callout to explain that it's managed

[shahzad31]

@shahzad31 as we discussed offline I tried to play with frozen input but it seems too limited for what you want to achieve this allow to have some variable non editable but it does not allow to block package policy deletion.

I think it will make sense to allow the is_externally_managed flag, we already have a similar flag at the agent policy level call is_managed do you mind renaming is_externally_managed => is_managed to be consistant, also I think we need to make a little more changes for managed package policies:

• a managed package policy should not be editable or updatable unless you pass a force flag similar to the agent policy behavior (see here for example nchaulet/kibana@67683c9/x-pack/plugins/fleet/server/services/agent_policy.ts#L655-L657)

• In the UI:

  • we should probably disable upgrade and delete in package policy action
  
  • when we edit|view a package policy we should probably disable all the fields and we should show a callout to explain that it's managed

I have added a callout

[shahzad31]

also renamed it to is_managed

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: 81b8982
• Storybooks Preview

Metrics [docs]

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	1390	1393	+3

Async chunks

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

id	before	after	diff
fleet	848.9KB	849.5KB	+589.0B
synthetics	882.1KB	882.6KB	+492.0B
total			+1.1KB

Saved Objects .kibana field count

Every field in each saved object type adds overhead to Elasticsearch. Kibana needs to keep the total field count below Elasticsearch's default limit of 1000 fields. Only specify field mappings for the fields you wish to search on or query. See https://www.elastic.co/guide/en/kibana/master/development-plugin-saved-objects.html#_mappings

id	before	after	diff
ingest-package-policies	38	39	+1

Unknown metric groups

API count

id	before	after	diff
fleet	1522	1525	+3

History

• 💔 Build #57386 failed d10a495
• 💛 Build #57347 was flaky 164b23c
• 💚 Build #57168 succeeded 966a645
• 💔 Build #57116 failed 7aa8ab7
• 💔 Build #56998 failed ddc82d7

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

[nchaulet]

Looks good to me 🚀
It will be nice if you can add an API integration test for a managed package policy here (or create a follow up issue so we keep track of that)
I created a follow up issue to improve the Fleet UI for these managed spec #136322

[dominiqueclarke]

Uptime changes LGTM

[shahzad31]

Looks good to me 🚀 It will be nice if you can add an API integration test for a managed package policy here (or create a follow up issue so we keep track of that) I created a follow up issue to improve the Fleet UI for these managed spec #136322

Thanks, i will do a follow up PR or an issue to cover that. Though i will add tests from synthetics perspective in follow up PR as well.

[hbharding]

This message should go in the content prop. Only use the title prop if content is being used. The title prop adds a horizontal divider, and looks bad when no context exists below.