[Ingest Manager] Hosted Agents cannot be upgraded, unenrolled or reassigned to a different config #76843
Comments
ruflin
added
the
Team:Fleet
|
Pinging @elastic/ingest-management (Team:Ingest Management) |
|
@ruflin Can you clarify, the enforce would be at the Agent policy not on the Agent itself? |
|
I expect this to be set during enrollment time on the Elastic Agent side. An Elastic Agent defines if it can accept a different policy or not, not the policy. |
ph
changed the title
|
@jfsiii Can you take a look at this and we can build the AC together? |
|
When a user attempts to take an action, a generic error message could say something like:
I'm hoping Elastic Cloud is generic enough to include ESS/ECE/ECK? If not, what is a better term? It'd be nicer if we had some metadata available in Fleet that allowed us to offer a more specific/helpful message based on which service is hosting the agent. Even better if we could link to the appropriate cloud console URL and deployment ID.
What do we think is possible given our technical capabilities and timeline? |
|
Also, I just realized that Elastic Cloud is not the only use case for preventing changes. For example, users on self-managed Kubernetes clusters may want to put these restrictions in place too. To support this, we'd need to expose some kind of setting or metadata on the agent. Perhaps something like Also, we'd either need a more generic message or more information about the orchestration solution they are using. I'm leaning towards starting with the generic message to keep things simple, and we can enhance it later.
|
|
I consider this a generic feature which is a fully managed policy. So it should work the same on Cloud but also the user on prem could setup this up if he wants. On top of that, we can build additional logic to improve error messaging for certain environments. |
|
I agree with both of you, I have added specific cloud message to be out of scope for first iteration is that correct? @mostlyjason we will initially develop this feature hidden in the UI, but we should see how we expose that feature to the end user in the UI. I am also assuming that we can reuse the current existing error reporting to reported blocked operation in the UI. |
|
For an individual agent action an error message would work fine, but what about bulk actions? Rather than showing individual errors for each agent that fill up the screen, it'd be nice to have a single error. Perhaps something like this?
@ph I think these error messages would be exposed to users in the Fleet UI, right? We can do something more sophisticated like showing which agents are affected, or have a specific message for Elastic Cloud, but we can do those as enhancements later. They will require extra data and business logic. |
|
As for exposing this in the UI beyond the error messages such as in the agent policy settings, can we track that on a separate issue? That allows us to prioritize/implement it separately. |
|
@mostlyjason Not sure I follow. I assume the Elastic Agents which can't be unenrolled would not even show this option. They could not be checked even for bulk actions. ++ on moving these discussions to separate issue(s). |
|
@ph My understanding when you said "we will initially develop this feature hidden in the UI" that meant we aren't making any changes to the UI. We are just showing error messages returned from the API using our current error reporting UI. This seems like the the minimal requirement to protect the agents on Elastic Cloud and communicate to the user. Is that what you had in mind? @ruflin Writing special functionality in the UI to disable check boxes and menu items would enhance the UX but I assume it'd require extra effort. I figure its better to save our limited capacity for higher priority features. We could file another issue to enhance the UX with these features. What do you think? |
|
I added a new requirement "No agents can be added to this policy from Fleet" |
|
@ph can you confirm that you agree with the initial scope "we aren't making any changes to the UI. We are just showing error messages returned from the API using our current error reporting UI. " |
|
@mostlyjason Not sure I agree. I would expect if for example an Agent cannot be upgraded, the upgrade action is hidden / greyed out. |
|
@mostlyjason Can you expand on "No agents can be added to this policy from Fleet"? Is that different from "No Agents can be moved into this policy" a few points up in the list? In #88688, any calls to
Is that in line with what you meant? Should I add or remove anything in that list? |
|
@mostlyjason before I commit to that, I want @jfsiii to comment on it, #76843 (comment) for the complexity, not I am not considering this "new UI" work, the widget is there. |
|
After thinking about this some more I could go either way, and considering effort is a good approach. I believe this is not enforced on the agent itself, but on the agent policy in Fleet so Fleet already knows what should be allowed or not. Greying out some menu items seems like less work. What would require more effort potentially are bulk actions. There we'd want to differentiate what subset of agents the action can be performed on, and which it cannot. This allows the user to select all agents on the agents page and upgrade them all in bulk, minus the small number of hosted agents. I imagine we'd want to update the bulk action confirmation dialog with this information. If we decided not to implement the confirmation message, we could perform the action on all agents and I imagine we'd get an error message on the subset that are not allowed. I imagine this is also how the bulk action API would work. |
|
So here is an easier idea for bulk actions: if any selected agent cannot be upgraded then block the entire bulk action, showing an error in the confirmation dialog and/or on execution. This could work because we have a filter for agents with an upgrade available #76842. If the user applies this filter, they can bulk upgrade the eligible agents. We'd probably want to double check that managed agents aren't listed as upgrade available, even if the version is lower. |
@mostlyjason thanks for spelling this out. I'll update the PR to error if it the list includes a managed policy. It currently silently filters them before calling ES. I was hoping to return an array of success / failure results like the ES client does for other bulk operations, but since the logic is in Kibana and not ES, it's a little more complicated. I think rejecting early is easiest and perhaps we can come back to allowing the actions on unmanaged policies to succeed while still returning details about why those on a managed policy failed. |
|
I added 3 checkmarks to the list above:
|
|
I added an item to the list above:
|
## Summary Introduces the concept of a managed agent policy. Resolves most of the acceptance criteria from #76843. Remaining to be done in follow up PRs - [x] Define hosted Agent Policy concept in Fleet. - [x] Flag in policy? **_yes, added `is_managed: boolean`_ in agent policy SO** - [x] Should not built only for cloud, an admin should be able to set theses restrictions. - [x] We should have an API to configure it _**Can `POST` and `PUT` to `/api/fleet/agent_policies/{policy_id}`**_ - [x] Integration should be editable, we expect integration author to do the right thing and limit what can be edited. - [x] Research if we can ensure the right behavior of Hosted Agent policy and restrict the super user. - [ ] Capabilities restrictions - [ ] An Agent enrolled in an Hosted Agent policy should not be able to be upgraded. - [x] An Agent enrolled in an Hosted Agent policy should not be able to be unenrolled. - [ ] No Agents cannot be enrolled into this policy by the user. - Hide the enrollment key? - Need to figure out the workflow. - [x] An Agent enrolled in an Hosted Agent policy should not be able to be reassigned to a different configuration. - [x] As a user I should be prevented to do theses action. _**No user-level checks. Only Agent Policy. No UI changes, but API errors are shown for failed actions like reassigning**_ - [x] As an API user I should receive error messages. - [x] If making a single "flag" is easier/faster let's do it. _**Currently single `is_managed` property on agent policy SO.**_ Checks are implemented in service layer (is agent enrolled in a managed policy?) No UI-specific changes added but UI is affected because HTTP requests (like `api/fleet/agents/{agentId}/reassign`) can fail. See screenshots below. Tests at service (`yarn test:jest`) and http (`yarn test ftr`) layers for each of create policy, update policy, unenroll agent, and reassign agent Bulk actions currently filter out restricted items. A follow-up PR will change them to throw an error and cause the request to fail. ## Managed Policy Can create (`POST`) and update (`PUT`) an agent policy with an `is_managed` property. Each new saved object will have an `is_managed` property (default `false`) <details><summary>HTTP commands</summary> #### Create (`is_managed: false` by default) ``` curl --user elastic:changeme -X POST localhost:5601/api/fleet/agent_policies -H 'Content-Type: application/json' -d'{ "name": "User created policy", "namespace": "default"}' -H 'kbn-xsrf: true' {"item":{"id":"edc236a0-5cbb-11eb-ab2c-0134aecb4ce8","name":"User created policy","namespace":"default","is_managed":false,"revision":1,"updated_at":"2021-01-22T14:12:58.250Z","updated_by":"elastic"}} ``` #### Create with `is_managed: true` ``` curl --user elastic:changeme -X POST localhost:5601/api/fleet/agent_policies -H 'Content-Type: application/json' -d'{ "name": "User created policy", "namespace": "default"}' -H 'kbn-xsrf: true' {"item":{"id":"67c785b0-662e-11eb-bf6b-4790dc0178c0","name":"User created policy","namespace":"default","is_managed":false,"revision":1,"updated_at":"2021-02-03T14:45:06.059Z","updated_by":"elastic"}} ``` #### Update with `is_managed: true` ``` curl --user elastic:changeme -X PUT -H 'Content-Type: application/json' -H 'kbn-xsrf: 1234' localhost:5601/api/fleet/agent_policies/67c785b0-662e-11eb-bf6b-4790dc0178c0 -d '{ "name":"User created policy","namespace":"default","is_managed":true }' {"item":{"id":"67c785b0-662e-11eb-bf6b-4790dc0178c0","name":"User created policy","namespace":"default","is_managed":true,"revision":2,"updated_at":"2021-02-03T14:47:28.471Z","updated_by":"elastic","package_policies":[]}} ``` </details> ## Enroll behavior is not changed/addressed in this PR. Agents can still be enrolled in managed policies ## Unenroll Agent from managed policy behavior #### Enrolled in managed agent policy, cannot be unenrolled ``` curl --user elastic:changeme -X POST http://localhost:5601/api/fleet/agents/441d4a40-6710-11eb-8f57-db14e8e41cff/unenroll -H 'kbn-xsrf: 1234' | jq { "statusCode": 400, "error": "Bad Request", "message": "Cannot unenroll 441d4a40-6710-11eb-8f57-db14e8e41cff from a managed agent policy af9b4970-6701-11eb-b55a-899b78cb64da" } ``` <details><summary>Screenshots for managed & unmanaged policies</summary> #### Enrolled in managed agent policy, cannot be unenrolled <img width="1931" alt="Screen Shot 2021-01-19 at 1 22 53 PM" src="https://user-images.githubusercontent.com/57655/105081614-67d05980-5a60-11eb-8faa-07e4e722a5b5.png"> <img width="1199" alt="Screen Shot 2021-01-19 at 1 30 26 PM" src="https://user-images.githubusercontent.com/57655/105081617-67d05980-5a60-11eb-9099-832dc6e04eca.png"> <img width="1971" alt="Screen Shot 2021-01-19 at 1 30 42 PM" src="https://user-images.githubusercontent.com/57655/105081618-67d05980-5a60-11eb-9a84-b80b6295ba19.png"> #### Enrolled agent policy is not managed, agent can be unenrolled<img width="1917" alt="Screen Shot 2021-01-19 at 1 44 12 PM" src="https://user-images.githubusercontent.com/57655/105081951-e3caa180-5a60-11eb-9308-7741b8986e8e.png"> <img width="2183" alt="Screen Shot 2021-01-19 at 1 44 19 PM" src="https://user-images.githubusercontent.com/57655/105081952-e3caa180-5a60-11eb-9833-1c721be0a107.png"> </details> ## Reassign agent #### No agent can be reassigned to a managed policy ``` curl --user elastic:changeme -X 'PUT' 'http://localhost:5601/api/fleet/agents/482760d0-6710-11eb-8f57-db14e8e41cff/reassign' -H 'kbn-xsrf: xxx' -H 'Content-Type: application/json' -d '{"policy_id":"af9b4970-6701-11eb-b55a-899b78cb64da"}' { "statusCode": 400, "error": "Bad Request", "message": "Cannot reassign an agent to managed agent policy 94129590-6707-11eb-b55a-899b78cb64da" } ``` <details><summary>Screenshots</summary> <img width="1350" alt="Screen Shot 2021-02-04 at 2 14 51 PM" src="https://user-images.githubusercontent.com/57655/106943490-8044a300-66f3-11eb-9d2c-4b1ceef2e783.png"> </details> #### Enrolled in managed agent policy, cannot be reassigned ``` curl --user elastic:changeme -X 'PUT' 'http://localhost:5601/api/fleet/agents/482760d0-6710-11eb-8f57-db14e8e41cff/reassign' -H 'kbn-xsrf: xxx' -H 'Content-Type: application/json' -d '{"policy_id":"af9b4970-6701-11eb-b55a-899b78cb64da"}' { "statusCode": 400, "error": "Bad Request", "message": "Cannot reassign an agent from managed agent policy 94129590-6707-11eb-b55a-899b78cb64da" } ``` <details><summary>Screenshots</summary> <img width="1364" alt="Screen Shot 2021-01-19 at 2 58 38 PM" src="https://user-images.githubusercontent.com/57655/105086737-72dab800-5a67-11eb-8f5e-93cd7768b914.png"> <img width="1367" alt="Screen Shot 2021-01-19 at 2 58 44 PM" src="https://user-images.githubusercontent.com/57655/105086740-73734e80-5a67-11eb-8ef9-9c7005a0a4ea.png"> <img width="623" alt="Screen Shot 2021-01-19 at 2 59 27 PM" src="https://user-images.githubusercontent.com/57655/105086741-740be500-5a67-11eb-8fc2-721f8b5d178a.png"> </details> #### Enrolled agent policy is unmanaged, agent can be reassigned to another unmanaged policy <details><summary>Screenshots</summary> <img width="1368" alt="Screen Shot 2021-01-19 at 3 00 01 PM" src="https://user-images.githubusercontent.com/57655/105086754-78d09900-5a67-11eb-86a5-9e3ac02d6e1f.png"> <img width="1363" alt="Screen Shot 2021-01-19 at 3 00 08 PM" src="https://user-images.githubusercontent.com/57655/105086761-7a01c600-5a67-11eb-991d-acf994e2a393.png"> <img width="625" alt="Screen Shot 2021-01-19 at 3 00 46 PM" src="https://user-images.githubusercontent.com/57655/105086764-7a9a5c80-5a67-11eb-8290-e79648d01579.png"> </details> ### Checklist Delete any items that are not applicable to this PR. - [ ] 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/master/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 - [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 Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
|
@ruflin should users be able to edit a hosted agent policy's settings such as:
Screenshot for Agent policy settings tab
|
|
IMO - the |
|
++ on @simitt comment. |
|
@hbharding can you file a separate issue for that? We could have a separate issue to discuss restrictions in integration policies. |
|
@ruflin I know we cannot add integrations to, or remove them from, a hosted policy
However, can the integrations that are associated with the hosted policy be updated? For example, looking at this list of Should we be able to click on one in a managed policy (
and update the integration name, whether to collect logs, etc? Another path to the same form is The current behavior is to show an error about updating integrations of a managed policy Should I update the API to allow this? cc @hbharding @mostlyjason this is what we discussed Tuesday |
|
In the case of the apm integration, users must be able to adjust the configs inside the integrations policy also in the managed case. I wonder what we should do with the name and description. My initial instinct would be to not let users edit name / description as this should have been set on creation time. |
@ruflin there's no such exception now. Should this be added for 7.13? If so, let's sync ASAP since FF is ~5 work days away. |
|
The apm integration won't be part of the 7.13 release; |
|
@jfsiii Yes, would be great to have it. I don't it matters too much if name / description are editable or not but the configs itself should be. |
## Summary Remove the restriction against updating integrations on hosted policies. I described the current behavior and asked if it should change in [1]. Based on the responses in [2] & [3] and looking back at prior discussion around hosted policies, I don't think updates should be restricted. Adding or removing integrations is still blocked for hosted policies. Updated API tests to confirm behavior. [1] #76843 (comment) [2] #76843 (comment) [3] #76843 (comment) ## Screenshots <details><summary>Current behavior</summary> <h3>Error about updating integrations of a managed policy</h3> <img width="1208" alt="Screen Shot 2021-04-08 at 3 23 37 PM" src="https://user-images.githubusercontent.com/57655/114084750-87686880-987e-11eb-91a9-081c45dbe871.png"> <details><summary>via flow A</summary> <img width="1223" alt="Screen Shot 2021-04-08 at 3 01 32 PM" src="https://user-images.githubusercontent.com/57655/114082826-3a839280-987c-11eb-94d0-151ae93ab523.png"> <img width="1205" alt="Screen Shot 2021-04-08 at 3 13 24 PM" src="https://user-images.githubusercontent.com/57655/114083728-5c314980-987d-11eb-92be-195d7d44c037.png"> </details> <details><summary>via flow B</summary> <img width="1221" alt="Screen Shot 2021-04-08 at 3 19 52 PM" src="https://user-images.githubusercontent.com/57655/114084502-3fe1dc80-987e-11eb-8879-57718586ac95.png"> <img width="1198" alt="Screen Shot 2021-04-08 at 3 20 06 PM" src="https://user-images.githubusercontent.com/57655/114084503-3fe1dc80-987e-11eb-9fa9-512210b938cd.png"> </details> </details> <details><summary>This PR</summary> <h3>Successful updates using either form</h3> <img width="1301" alt="Screen Shot 2021-04-09 at 1 21 02 PM" src="https://user-images.githubusercontent.com/57655/114219370-8f84de80-9938-11eb-9b94-dfbeb18535b2.png"> <img width="1320" alt="Screen Shot 2021-04-09 at 1 05 10 PM" src="https://user-images.githubusercontent.com/57655/114219408-9f9cbe00-9938-11eb-96d2-2918332d1539.png"> </details> ### 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 Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary Remove the restriction against updating integrations on hosted policies. I described the current behavior and asked if it should change in [1]. Based on the responses in [2] & [3] and looking back at prior discussion around hosted policies, I don't think updates should be restricted. Adding or removing integrations is still blocked for hosted policies. Updated API tests to confirm behavior. [1] elastic#76843 (comment) [2] elastic#76843 (comment) [3] elastic#76843 (comment) ## Screenshots <details><summary>Current behavior</summary> <h3>Error about updating integrations of a managed policy</h3> <img width="1208" alt="Screen Shot 2021-04-08 at 3 23 37 PM" src="https://user-images.githubusercontent.com/57655/114084750-87686880-987e-11eb-91a9-081c45dbe871.png"> <details><summary>via flow A</summary> <img width="1223" alt="Screen Shot 2021-04-08 at 3 01 32 PM" src="https://user-images.githubusercontent.com/57655/114082826-3a839280-987c-11eb-94d0-151ae93ab523.png"> <img width="1205" alt="Screen Shot 2021-04-08 at 3 13 24 PM" src="https://user-images.githubusercontent.com/57655/114083728-5c314980-987d-11eb-92be-195d7d44c037.png"> </details> <details><summary>via flow B</summary> <img width="1221" alt="Screen Shot 2021-04-08 at 3 19 52 PM" src="https://user-images.githubusercontent.com/57655/114084502-3fe1dc80-987e-11eb-8879-57718586ac95.png"> <img width="1198" alt="Screen Shot 2021-04-08 at 3 20 06 PM" src="https://user-images.githubusercontent.com/57655/114084503-3fe1dc80-987e-11eb-9fa9-512210b938cd.png"> </details> </details> <details><summary>This PR</summary> <h3>Successful updates using either form</h3> <img width="1301" alt="Screen Shot 2021-04-09 at 1 21 02 PM" src="https://user-images.githubusercontent.com/57655/114219370-8f84de80-9938-11eb-9b94-dfbeb18535b2.png"> <img width="1320" alt="Screen Shot 2021-04-09 at 1 05 10 PM" src="https://user-images.githubusercontent.com/57655/114219408-9f9cbe00-9938-11eb-96d2-2918332d1539.png"> </details> ### 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 Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary Remove the restriction against updating integrations on hosted policies. I described the current behavior and asked if it should change in [1]. Based on the responses in [2] & [3] and looking back at prior discussion around hosted policies, I don't think updates should be restricted. Adding or removing integrations is still blocked for hosted policies. Updated API tests to confirm behavior. [1] #76843 (comment) [2] #76843 (comment) [3] #76843 (comment) ## Screenshots <details><summary>Current behavior</summary> <h3>Error about updating integrations of a managed policy</h3> <img width="1208" alt="Screen Shot 2021-04-08 at 3 23 37 PM" src="https://user-images.githubusercontent.com/57655/114084750-87686880-987e-11eb-91a9-081c45dbe871.png"> <details><summary>via flow A</summary> <img width="1223" alt="Screen Shot 2021-04-08 at 3 01 32 PM" src="https://user-images.githubusercontent.com/57655/114082826-3a839280-987c-11eb-94d0-151ae93ab523.png"> <img width="1205" alt="Screen Shot 2021-04-08 at 3 13 24 PM" src="https://user-images.githubusercontent.com/57655/114083728-5c314980-987d-11eb-92be-195d7d44c037.png"> </details> <details><summary>via flow B</summary> <img width="1221" alt="Screen Shot 2021-04-08 at 3 19 52 PM" src="https://user-images.githubusercontent.com/57655/114084502-3fe1dc80-987e-11eb-8879-57718586ac95.png"> <img width="1198" alt="Screen Shot 2021-04-08 at 3 20 06 PM" src="https://user-images.githubusercontent.com/57655/114084503-3fe1dc80-987e-11eb-9fa9-512210b938cd.png"> </details> </details> <details><summary>This PR</summary> <h3>Successful updates using either form</h3> <img width="1301" alt="Screen Shot 2021-04-09 at 1 21 02 PM" src="https://user-images.githubusercontent.com/57655/114219370-8f84de80-9938-11eb-9b94-dfbeb18535b2.png"> <img width="1320" alt="Screen Shot 2021-04-09 at 1 05 10 PM" src="https://user-images.githubusercontent.com/57655/114219408-9f9cbe00-9938-11eb-96d2-2918332d1539.png"> </details> ### 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 Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: John Schulz <john.schulz@elastic.co>
|
Hi @EricDavisX , While converting all proposed scenarios in testcases, we have come up with below query. Could you please confirm about what is expected from point ' Should not built only for cloud' mentioned in ticket summary AC. As we are unable to determine how its expected to behave in application. Thanks |
|
@jfsiii and @hbharding would you want to take a look at the test cases created and see how they look? |
|
@dikshachauhan-qasource re: #76843 (comment)
I believe this is tested & confirmed via the HTTP API for creating them: There's nothing cloud-specific about it and it's subject to the same "must be superuser" requirement as all Fleet APIs |
Hosted Agent are agent managed outside of Fleet and Kibana, one of the use case is to spin up an Agent on Cloud and have it managed by the Fleet application.
AC
[Fleet] Upgrade-related restrictions for agents in managed policies #90434Agents in a managed policy aren't listed as upgrade available, even if the version is lowerHide the enrollment key?will check agent policy same as other actions/agents/bulk_{reassign,unenroll,upgrade}) will error if any item is invalid/forbiddenimplementation steps to understand the initial problem:
Out of scope
Questions:
The text was updated successfully, but these errors were encountered: