Elastic Agent deployment models with mutual TLS

Mutual Transport Layer Security (mTLS) provides a higher level of security and trust compared to one-way TLS, where only the server presents a certificate. It ensures that not only the server is who it claims to be, but the client is also authenticated. This is particularly valuable in scenarios where both parties need to establish trust and validate each other’s identities, such as in secure API communication, web services, or remote authentication.

For a summary of flow by which TLS is established between components using either one-way or mutual TLS, refer to One-way and mutual TLS certifications flow.

With mutual TLS the following authentication and certification verification occurs:

Fleet-managed Elastic Agent has two main connections to ensure correct operations:

In order to bootstrap, Elastic Agent initially must establish a secure connection to the Fleet Server, which can reside on-premises or in Elastic Cloud. This connectivity verification process ensures the agent’s authenticity. Once verified, the agent receives the policy configuration. This policy download equips the agent with the knowledge of the other components it needs to engage with. For instance, it gains insights into the output destinations it should write data to.

When mTLS is required, the secure setup between Elastic Agent, Fleet, and Fleet Server is configured through the following steps:

Refer to the steps in Configure SSL/TLS for self-managed Fleet Servers. To configure mutual TLS, include the following additional parameters when you install Elastic Agent and Fleet Server.

During Elastic Agent installation on premise use the following options:

During Fleet Server installation on-premise Fleet Server authenticates with Elasticsearch and Elastic Agents. You can use the following CLI options to facilitate these secure connections:

In Kibana, navigate to Fleet, open the Settings tab, and choose the Output that you’d like to configure. In the Advanced YAML configuration, add the following settings:

In the Advanced YAML configuration these settings should be added in the following format:

ssl.certificate_authorities:
  - /path/to/ca
ssl.certificate: /path/to/cert
ssl.key: /path/to/cert_key

OR

ssl.certificate_authorities:
  - /path/to/ca
ssl.certificate: /path/to/cert
ssl.key: /path/to/cert_key

In this deployment model, all traffic ingress into Elastic Cloud has its TLS connection terminated at the Elastic Cloud boundary. Since this termination is not handled on a per-tenant basis, a client-specific certificate can NOT be used at this point.

We currently don’t support mTLS in this deployment model. An alternate deployment model is shown below where you can deploy your own secure proxy where TLS connections are terminated.

In this scenario, where you have access to the proxy, you can configure mTLS between the agent and your proxy.

During Elastic Agent installation on premise use the following options:

In some scenarios you may want to deploy Fleet Server on your own premises. In this case, you’re able to provide your own certificates and certificate authority to enable mTLS between Fleet Server and Elastic Agent.

However, as with the Fleet Server on Elastic Cloud use case, the data plane TLS connections terminate at the Elastic Cloud boundary. Elastic Cloud is not a multi-tenanted service and therefore can’t provide per-user certificates.

Similar to the Fleet Server on Elastic Cloud use case, a secure proxy can be placed in such an environment to terminate the TLS connections and satisfy the mTLS requirements.

During Elastic Agent installation on premise use the following options, similar to Elastic Agent deployment on premises:

During Fleet Server installation on-premise use the following options so that Fleet Server can authenticate itself to the agent and then also to the secure proxy server:

This is the same as what’s described for on premise deployments. The main difference is that you need to use certificates that are accepted by the secure proxy, as the mTLS is set up between the agent and the secure proxy.