Open joshdover opened 2 years ago
Pinging @elastic/fleet (Team:Fleet)
Hi @joshdover , are you thinking you would lock down the service? or lock down certain updates to the payload ifnot using a fleet scoped client?
are you thinking you would lock down the service? or lock down certain updates to the payload ifnot using a fleet scoped client?
My plan was to remove support for setting this field from the service completely. I don't think we need this functionality as this is supposed to be specified in the package manifest. Please correct me if I am wrong.
Today, the Fleet server-side plugin exposes a
packagePolicyService
API to other plugins which allows them to read and write to integration policies. These policies contain a field that specifies the required Elasticsearch privileges that Fleet Server should grant to Agents that are enrolled in the policy.Instead of allowing any consumer of this service to specify the privilege definitions, we should ensure that these privileges are always pulled from the integration's package manifest to avoid any potential security vulnerabilities from usage of our internal service.
We should probably take a closer look at what we're allowing plugins to do with these internal services and start de-couple the service used internally by the Fleet plugin from what is exposed to other plugins.
The packagePolicyService is exposed here: https://github.com/elastic/kibana/blob/68abf5eb50cef160bbe01df6b71028d270c75c1d/x-pack/plugins/fleet/server/plugin.ts#L432
Which exposes this class: https://github.com/elastic/kibana/blob/68abf5eb50cef160bbe01df6b71028d270c75c1d/x-pack/plugins/fleet/server/services/package_policy.ts#L91
Which allows specifying ES privileges on this type: https://github.com/elastic/kibana/blob/68abf5eb50cef160bbe01df6b71028d270c75c1d/x-pack/plugins/fleet/common/types/models/package_policy.ts#L69-L73