Support for pushing policies instead of pulling

[poppelaars]

Describe the enhancement:

I would like a mechanism where policies/configuration can be pushed to a fleet-server instead of fleet-server retrieving this.

Describe a specific use case for the enhancement or feature:

Nowadays you see that a lot of companies are implementing micro-segmented network architectures as a standard. Where some networks are labeled with a higher security level than others. Connections from a network with a lower security level to a higher one is prohibited.

This causes that the observability/SIEM stack has to be setup in a network with a higher security level in order to cater many networks. However, fleet server needs to communicate to the central Elasticsearch stack to retrieve its policies. While fleet server supports proxy servers the direction of connection from a lower level to a higher one is usually not allowed.

As long as the network connection is initiated from the higher security level network most use-cases are fine (We would still need to explain what data is going outbound, in this case the policies). It would be nice if policies could be pushed from the higher security level to a lower security level instead of being pulled.

[cmacknz]

In this situation, Fleet Server is outside of the higher security network that contains Elasticsearch?

We don't have any plans to support pushing policies to Fleet Server instead of having Fleet Server query them out of Elasticsearch directly.

Most related work in this area is building out support for multiple clusters, with a single control cluster delivering policies to agents which write data to multiple data clusters, with analysis happening via cross-cluster search.

https://github.com/elastic/kibana/issues/187323a to replicate integrations across clusters is probably the closest to something that could help if you were willing to have 2 clusters, but I don't think this actually solves your problem.

CC @nimarezainia