This document briefly describes how Flink security works in the context of various deployment mechanisms (Standalone, native Kubernetes, YARN, or Mesos), filesystems, connectors, and state backends.
The primary goals of the Flink Kerberos security infrastructure are:
In a production deployment scenario, streaming jobs are understood to run for long periods of time (days/weeks/months) and be able to authenticate to secure data sources throughout the life of the job. Kerberos keytabs do not expire in that timeframe, unlike a Hadoop delegation token or ticket cache entry.
The current implementation supports running Flink clusters (JobManager / TaskManager / jobs) with either a configured keytab credential or with Hadoop delegation tokens. Keep in mind that all jobs share the credential configured for a given cluster. To use a different keytab for a certain job, simply launch a separate Flink cluster with a different configuration. Numerous Flink clusters may run side-by-side in a Kubernetes, YARN or Mesos environment.
In concept, a Flink program may use first- or third-party connectors (Kafka, HDFS, Cassandra, Flume, Kinesis etc.) necessitating arbitrary authentication methods (Kerberos, SSL/TLS, username/password, etc.). While satisfying the security requirements for all connectors is an ongoing effort, Flink provides first-class support for Kerberos authentication only. The following services and connectors are supported for Kerberos authentication:
Note that it is possible to enable the use of Kerberos independently for each service or connector. For example, the user may enable Hadoop security without necessitating the use of Kerberos for ZooKeeper, or vice versa. The shared element is the configuration of Kerberos credentials, which is then explicitly used by each component.
The internal architecture is based on security modules (implementing
are installed at startup. The following sections describes each security module.
This module uses the Hadoop
UserGroupInformation (UGI) class to establish a process-wide login user context. The login user is
then used for all interactions with Hadoop, including HDFS, HBase, and YARN.
If Hadoop security is enabled (in
core-site.xml), the login user will have whatever Kerberos credential is configured. Otherwise,
the login user conveys only the user identity of the OS account that launched the cluster.
This module provides a dynamic JAAS configuration to the cluster, making available the configured Kerberos credential to ZooKeeper, Kafka, and other such components that rely on JAAS.
Note that the user may also provide a static JAAS configuration file using the mechanisms described in the Java SE Documentation. Static entries override any dynamic entries provided by this module.
This module configures certain process-wide ZooKeeper security-related settings, namely the ZooKeeper service name (default:
and the JAAS login context name (default:
Here is some information specific to each deployment mode.
Steps to run a secure Flink cluster in standalone/cluster mode:
security.kerberos.login.keytabon all cluster nodes.
Steps to run a secure Flink cluster in native Kubernetes, YARN and Mesos mode:
security.kerberos.login.keytabon the client node.
In YARN, Mesos and native Kubernetes mode, the keytab is automatically copied from the client to the Flink containers.
To enable Kerberos authentication, the Kerberos configuration file is also required. This file can be either fetched from the cluster environment or uploaded by Flink. In the latter case, you need to configure the
security.kerberos.krb5-conf.path to indicate the path of the Kerberos configuration file and Flink will copy this file to its containers/pods.
Note that the property
java.security.krb5.conf, which was available in Mesos mode previously, has been deprecated. Despite it’s still taking effect for backward compatibility, please be aware this property can be removed in future releases.
For more information, see YARN security documentation.
In YARN mode, it is possible to deploy a secure Flink cluster without a keytab, using only the ticket cache (as managed by
This avoids the complexity of generating a keytab and avoids entrusting the cluster manager with it. In this scenario, the Flink CLI acquires Hadoop delegation tokens (for HDFS and for HBase).
The main drawback is that the cluster is necessarily short-lived since the generated delegation tokens will expire (typically within a week).
Steps to run a secure Flink cluster using
Each component that uses Kerberos is independently responsible for renewing the Kerberos ticket-granting-ticket (TGT). Hadoop, ZooKeeper, and Kafka all renew the TGT automatically when provided a keytab. In the delegation token scenario, YARN itself renews the token (up to its maximum lifespan).