Clarify Fleet Server connectivity requirement in the “Remote Elasticsearch output” doc#5108
Clarify Fleet Server connectivity requirement in the “Remote Elasticsearch output” doc#5108vishaangelova wants to merge 3 commits intomainfrom
Conversation
✅ Vale Linting ResultsNo issues found on modified lines! The Vale linter checks documentation changes against the Elastic Docs style guide. To use Vale locally or report issues, refer to Elastic style guide for Vale. |
🔍 Preview links for changed docs |
- Clarified the Fleet Server to remote cluster connectivity requirement - Added step for configuring SSL CA - Updated stepper to use step titles
vishaangelova
force-pushed
the
4026-clarify-remote-es-output
branch
from
ecf55f6 to
8823f2e
Compare
vishaangelova
force-pushed
the
4026-clarify-remote-es-output
branch
from
8ad09e1 to
221ead4
Compare
| - **Server SSL certificate authorities**: Add the certificate authority (CA) used to sign the remote {{es}} cluster's SSL certificate. This allows {{fleet-server}} to validate the remote cluster's certificate. | ||
| - **Client SSL certificate** (optional): Add a client certificate if the remote {{es}} cluster requires mutual TLS (mTLS) authentication. | ||
| - **Client SSL certificate key** (optional): Add the private key for the client certificate. | ||
| Expand the **Authentication** section, then paste the certificate content into the **Server SSL certificate authorities** field. |
There was a problem hiding this comment.
The new UI also allows to configure a path instead of the content of the CA. I mention it because you are mentioning it in all other places with alternatively, .....
| - **Client SSL certificate**: Paste the client certificate content that {{agents}} will use to authenticate with the remote cluster. | ||
| - **Client SSL certificate key**: Paste the private key content associated with the client certificate. |
There was a problem hiding this comment.
Sane as before, the new UI also allows setting paths instead of the content of the cert and key. So they could use /path/to/client-cert.pem and /path/to/client-cert.key.
Co-authored-by: Edu González de la Herrán <25320357+eedugon@users.noreply.github.com>
| These limitations apply to remote {{es}} output: | ||
|
|
||
| * {{fleet-server}} must be able to reach the remote {{es}} cluster with a service token to create API keys for any {{agents}} that use the remote {{es}} output. | ||
| * At least one {{fleet-server}} must be able to reach the remote {{es}} cluster with a service token to generate API keys for the {{agents}} that use the remote output for data ingestion. |
There was a problem hiding this comment.
All need to be able to reach, otherwise a request could be routed to one that cannot and that will fail. There is no internal routing that knows which one can access and which one cannot. So they all must be able to reach the remote ES cluster.
There was a problem hiding this comment.
I wrote that comment, before I got to the bottom. The at least one is still not correct here, but it doesn't have to be all of them. It must accessible by all Fleet Servers that the Elastic Agent's in that policy that will access the remote ES. This ties into defining the URL to the Fleet Server. If the Fleet Servers that the Elastic Agent's will communicate with all need to have access to the remote ES cluster.
If 2 of the Fleet Servers are used for a separate network and those agents are never going to connect to those Fleet Servers and are never going to communicate with that remote ES, then it doesn't need to have access.
3 participants
Summary
This PR:
applies_tofor a feature configuration, and removes incorrect use ofserverlessin an in-lineapplies_to(remote ES output is not available in Serverless)Resolves #4026
Preview
reference/fleet/remote-elasticsearch-output.md
Generative AI disclosure
Tool(s) and model(s) used: Cursor 2.4.31 with claude-4.5-sonnet