About TLS encryption
The encryption of DC/OS communications varies according to your security mode.
|Security mode||External communications*||Internode communications|
||HTTP connections are not redirected to HTTPS or vice versa. HTTPS connections will be rejected because the Admin Router is not configured to serve them.||Unencrypted|
HTTP requests to the root path (i.e., to
||All HTTP connections are redirected to HTTPS.||Encryption enforced**|
* Communications with clients outside of the cluster. For example, browsers and the DC/OS CLI.
** Except internode communications between instances of ZooKeeper, which are not encrypted in any security mode. Each master node has a ZooKeeper instance. These ZooKeeper instances communicate periodically to keep their in-memory databases in sync. You can use IPsec to manually encrypt these communications. We plan to automatically encrypt communications between instances of ZooKeeper in a future release.
Not all existing user services support encryption at this time. If the service supports encryption, you can enable it in
permissive mode. In
strict mode, encryption of user service communications is enforced. As a result, only user services that support encryption can be deployed in
Internode communications occur over TLS 1.2. To ensure browser support, external communications currently accept TLS 1.0, 1.1, and 1.2. These settings are configurable.
strict security modes, your DC/OS Certificate Authority signs the TLS certificates and provisions them to systemd-started services during the bootstrap sequence. This accomplishes encrypted communications with no manual intervention. Each DC/OS cluster has its own DC/OS Certificate Authority and a unique root certificate to protect DC/OS clusters from each other.
Because your DC/OS Certificate Authority does not appear in any lists of trusted certificate authorities, requests coming in from outside the cluster, such as from a browser or curl, will result in warning messages.
To establish trusted communications with your DC/OS cluster and stop the warning messages:
Perform one of the following.
Set up a proxy between DC/OS and requests coming in from outside of the cluster. The proxy terminates the requests and resends them to DC/OS. By configuring this proxy to trust the root certificate of your DC/OS CA, you can ensure that it connects securely to your DC/OS cluster.
Configuring HAProxy in Front of Admin Router
You can use HAProxy to set up an HTTP proxy in front of the DC/OS Admin Router. For example, this can be useful if you want to present a custom server certificate to user agents connecting to the cluster via HTTPS. DC/OS does not currently support adding your own certificates directly into Admin Router.…Read More
Obtaining the root certificate of your DC/OS CA
As a first step in ensuring that clients communicate with your DC/OS cluster and not another party, obtain the root certificate of your DC/OS CA. …Read More
Configuring browsers to trust your DC/OS CA
How to configure Chrome and Firefox to trust your DC/OS CA. …Read More
Configuring the DC/OS CLI to trust your DC/OS CA
By default, the DC/OS CLI does not verify the signer of TLS certificates. We recommend completing the following brief procedure to ensure that the DC/OS CLI trusts only your DC/OS CA and refuses connections with other parties. …Read More
Establishing trust in your curl commands
If you have not set up a proxy, you should use `--cacert dcos-ca.crt` in your curl commands in `permissive` and `strict` security modes. …Read More
Certificate Authority API
The Certificate Authority API allows you to view the TLS certificates used by DC/OS Enterprise, create Certificate Signing Requests (CSRs), and have the DC/OS CA sign CSRs. …Read More