This page provides instructions on how to enable TLS/SSL authentication and encryption for network communication with and between Flink processes.
When securing network connections between machines processes through authentication and encryption, Apache Flink differentiates between internal and external connectivity. Internal Connectivity refers to all connections made between Flink processes. These connections run Flink custom protocols. Users never connect directly to internal connectivity endpoints. External / REST Connectivity endpoints refers to all connections made from the outside to Flink processes. This includes the web UI and REST commands to start and control running Flink jobs/applications, including the communication of the Flink CLI with the JobManager / Dispatcher.
For more flexibility, security for internal and external connectivity can be enabled and configured separately.
Internal connectivity includes:
All internal connections are SSL authenticated and encrypted. The connections use mutual authentication, meaning both server and client side of each connection need to present the certificate to each other. The certificate acts effectively as a shared secret.
A common setup is to generate a dedicated certificate (may be self-signed) for a Flink deployment. The certificate for internal communication is not needed by any other party to interact with Flink, and can be simply added to the container images, or attached to the YARN deployment.
Note: Because internal connections are mutually authenticated with shared certificates, Flink can skip hostname verification. This makes container-based setups easier.
All external connectivity is exposed via an HTTP/REST endpoint, used for example by the web UI and the CLI:
The REST endpoints can be configured to require SSL connections. The server will, however, accept connections from any client, meaning the REST endpoint does not authenticate the client.
If authentication of connections to the REST endpoint is required, we recommend to deploy a “side car proxy”: Bind the REST endpoint to the loopback interface (or the pod-local interface in Kubernetes) and start a REST proxy that authenticates and forwards the requests to Flink. Examples for proxies that Flink users have deployed are Envoy Proxy or NGINX with MOD_AUTH.
The rationale behind delegating authentication to a proxy is that such proxies offer many more authentication options than the Flink project could reasonably implement itself, and thus offer better integration into existing infrastructures.
Connections to the queryable state endpoints is currently not authenticated or encrypted.
SSL can be enabled separately for internal and external connectivity:
Note: For backwards compatibility, the security.ssl.enabled option still exists and enables SSL for both internal and REST endpoints.
For internal connectivity, you can optionally disable security for different connection types separately.
security.ssl.internal.enabled is set to
true, you can set the following parameters to
false to disable SSL for that particular connection type:
taskmanager.data.ssl.enabled: Data communication between TaskManagers
blob.service.ssl.enabled: Transport of BLOBs from JobManager to TaskManager
akka.ssl.enabled: Akka-based RPC connections between JobManager / TaskManager / ResourceManager
The SSL configuration requires to configure a keystore and a truststore. The keystore contains the public certificate (public key) and the private key, while the truststore contains the trusted certificates or the trusted authorities. Both stores need to be set up such that the truststore trusts the keystore’s certificate.
Because internal communication is mutually authenticated, keystore and truststore typically contain the same dedicated certificate. The certificate can use wild card hostnames or addresses, because the certificate is expected to be a shared secret and host names are not verified. It is even possible to use the same file (the keystore) also as the truststore.
REST Endpoints (external connectivity)
For REST endpoints, the keystore is used by the server endpoint, and the truststore is used by the REST clients (including the CLI client) to accept the server’s certificate. In the case where the REST keystore has a self-signed certificate, the truststore must trust that certificate directly. If the REST endpoint uses a certificate that is signed through a proper certification hierarchy, the roots of that hierarchy should be in the trust store.
The IETF RFC 7525 recommends to use a specific set of cipher suites for strong security. Because these cipher suites were not available on many setups out of the box, Flink’s default value is set to a slightly weaker but more compatible cipher suite. We recommend that SSL setups update to the stronger cipher suites, if possible, by adding the below entry to the Flink configuration:
If these cipher suites are not supported on your setup, you will see that Flink processes will not be able to connect to each other.
Keys, Certificates, and the Keystores and Truststores can be generated using the keytool utility. You need to have an appropriate Java Keystore and Truststore accessible from each node in the Flink cluster.
For the externally facing REST endpoint, the common name or subject alternative names in the certificate should match the node’s hostname and IP address.
Execute the following keytool commands to create a key pair in a keystore:
The single key/certificate in the keystore is used the same way by the server and client endpoints (mutual authentication). The key pair acts as the shared secret for internal security, and we can directly use it as keystore and truststore.
The REST endpoint may receive connections from external processes, including tools that are not part of Flink (for example curl request to the REST API). Setting up a proper certificate that is signed though a CA hierarchy may make sense for the REST endpoint.
However, as mentioned above, the REST endpoint does not authenticate clients and thus typically needs to be secured via a proxy anyways.
REST Endpoint (simple self signed certificate)
This example shows how to create a simple keystore / truststore pair. The truststore does not contain the primary key and can be shared with other applications. In this example, myhost.company.org / ip:10.0.2.15 is the node (or service) for the Flink master.
REST Endpoint (with a self signed CA)
Execute the following keytool commands to create a truststore with a self signed CA.
Now create a keystore for the REST endpoint with a certificate signed by the above CA. Let flink.company.org / ip:10.0.2.15 be the hostname of the Flink master (JobManager).
Now add the following configuration to your
For YARN and Mesos, you can use the tools of Yarn and Mesos to help:
Configuring security for internal communication is exactly the same as in the example above.
To secure the REST endpoint, you need to issue the REST endpoint’s certificate such that it is valid for all hosts that the Flink master may get deployed to. This can be done with a wild card DNS name, or by adding multiple DNS names.
The easiest way to deploy keystores and truststore is by YARN client’s ship files option (
Copy the keystore and truststore files into a local directory (say
deploy-keys/) and start the YARN session as
flink run -m yarn-cluster -yt deploy-keys/ flinkapp.jar
When deployed using YARN, Flink’s web dashboard is accessible through YARN proxy’s Tracking URL. To ensure that the YARN proxy is able to access Flink’s HTTPS URL, you need to configure YARN proxy to accept Flink’s SSL certificates. For that, add the custom CA certificate into Java’s default truststore on the YARN Proxy node.