Elastic Agent deployment models with mutual TLS
editElastic Agent deployment models with mutual TLS
editMutual 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.
Overview
editWith mutual TLS the following authentication and certification verification occurs:
- Client Authentication: The client presents its digital certificate to the server during the TLS handshake. This certificate is issued by a trusted Certificate Authority (CA) and contains the client’s public key.
- Server Authentication: The server also presents its digital certificate to the client, proving its identity and sharing its public key. The server’s certificate is also issued by a trusted CA.
- Certificate Verification: Both the client and server verify each other’s certificates by checking the digital signatures against the CAs' public key (note that the client and server need not use the same CA).
Fleet-managed Elastic Agent has two main connections to ensure correct operations:
- Connectivity to Fleet Server (the control plane, to check in, download policies, and similar).
- Connectivity to an Output (the data plane, such as Elasticsearch or Logstash).
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:
- mTLS is enabled.
-
The initial mTLS connection between Elastic Agent and Fleet Server is configured when Elastic Agent is enrolled, using the parameters passed through the
elastic-agent install
orelastic-agent enroll
command. -
Once enrollment has completed, Elastic Agent downloads the initial Elastic Agent policy from Fleet Server.
- If the Elastic Agent policy contains mTLS configuration settings, those settings will take precedence over those used during enrollment: This includes both the mTLS settings used for connectivity between Elastic Agent and Fleet Server (and the Fleet application in Kibana, for Fleet-managed Elastic Agent), and the settings used between Elastic Agent and it’s specified output.
- If the Elastic Agent policy does not contain any TLS, mTLS, or proxy configuration settings, these settings will remain as they were specified when Elastic Agent enrolled. Note that the initial TLS, mTLS, or proxy configuration settings can not be removed through the Elastic Agent policy; they can only be updated.
On-premise deployments
edit![Diagram of mutual TLS on premise deployment model](images/mutual-tls-on-prem.png)
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.
Elastic Agent settings
editDuring Elastic Agent installation on premise use the following options:
|
List of CA certificates that are trusted when Fleet Server connects to Elastic Agent |
|
Elastic Agent certificate to present to Fleet Server during authentication |
|
Elastic Agent certificate key to present to Fleet Server |
Fleet Server settings
editDuring 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:
|
CA to use for the Elasticsearch connection |
|
Fleet Server certificate to present to Elasticsearch |
|
Fleet Server certificate key to present to Elasticsearch |
|
List of CA certificates that are trusted when Elastic Agent connects to Fleet Server and when Fleet Server validates the Elastic Agent identity. |
|
Fleet Server certificate to present to Elastic Agents during authentication |
|
Fleet Server’s private certificate key used to decrypt the certificate |
Fleet settings:
editIn 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:
|
List of CA certificates that are trusted when Fleet Server connects to Elastic Agent |
|
This certificate will be passed down to all the agents that have this output configured in their policy. This certificate is used by the agent when establishing mTLS to the output. You may either apply the full certificate, in which case all the agents get the same certificate OR alternatively point to a local directory on the agent where the certificate resides, if the certificates are to be unique per agent. |
|
This certificate key will be passed down to all the agents that have this output configured in their policy. The certificate key is used to decrypt the SSL certificate. |
Note the following when you specify these SSL settings:
- The certificate authority, certificate, and certificate key need to be specified as a path to a local file. You cannot specify a directory.
- You can define multiple CAs or paths to CAs.
- Only one certificate and certificate key can be defined.
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
![Screen capture of output advanced yaml settings](images/mutual-tls-onprem-advanced-yaml.png)
Fleet Server on Elastic Cloud
editIn 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.
![Diagram of mutual TLS on cloud deployment model](images/mutual-tls-cloud.png)
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.
Fleet Server on Elastic Cloud using a proxy
editIn this scenario, where you have access to the proxy, you can configure mTLS between the agent and your proxy.
![Diagram of mutual TLS on cloud deployment model with a proxy](images/mutual-tls-cloud-proxy.png)
Elastic Agent settings
editDuring Elastic Agent installation on premise use the following options:
|
List of CA certificates that are trusted when Elastic Agent connects to Fleet Server or to the proxy between Elastic Agent and Fleet Server |
|
Elastic Agent certificate to present during authentication to Fleet Server or to the proxy between Elastic Agent and Fleet Server |
|
Elastic Agent’s private certificate key used to decrypt the certificate |
Fleet Server on-premise and Hosted Elasticsearch Service
editIn 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.
![Diagram of mutual TLS with Fleet Server on premise and hosted Elasticsearch Service deployment model](images/mutual-tls-fs-onprem.png)
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.
![Diagram of mutual TLS with Fleet Server on premise and hosted Elasticsearch Service deployment model with a proxy](images/mutual-tls-fs-onprem-proxy.png)
Elastic Agent settings
editDuring Elastic Agent installation on premise use the following options, similar to Elastic Agent deployment on premises:
|
List of CA certificates that are trusted for when Elastic Agent connects to Fleet Server |
|
Elastic Agent certificate to present to Fleet Server during authentication |
|
Elastic Agent’s private certificate key used to decrypt the certificate |
Fleet Server settings
editDuring 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:
|
CA to use for the Elasticsearch connection, via secure proxy. This CA is used to authenticate the TLS connection from a secure proxy |
|
List of CA certificates that are trusted when Elastic Agent connects to Fleet Server |
|
Fleet Server certificate to present to Elastic Agents during authentication |
|
Fleet Server’s private certificate key used to decrypt the certificate |
Fleet settings
editThis 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.