Configure Authentication
Authentication verifies the identity of users and applications connecting to Apache Kafka® and other Confluent components.
Confluent Platform components have no authentication enabled by default. Configure one of the following supported mechanisms for Confluent Platform using Confluent for Kubernetes (CFK).
Available authentication mechanisms
Configure authentication to access Kafka and KRaft: Configure authentication for Kafka, KRaft, and Metadata Service (MDS).
Configure Authentication for Confluent Platform Components: Configure authentication for other Confluent Platform components.
For more details on authentication concepts in Confluent Platform, see Authentication in Confluent Platform.
For a comprehensive tutorial scenario for configuring authentication, see Deploy Secure Confluent Platform.
Note
The files that you use to create authentication secrets must use the
Linux-style line ending that only uses line feed (\n). The
Windows-style line ending that uses carriage return and line feed
(\r\n) does not work in Kubernetes secret files.
Authentication to access Kafka
CFK supports the following authentication mechanisms for client applications and Confluent Platform components to access Kafka:
SASL/PLAIN authentication: Clients use a username/password for authentication. The username/passwords are stored server-side in a Kubernetes secret or a directory in the container.
SASL/PLAIN with LDAP authentication: Clients use a username/password for authentication. The username/passwords are stored in an LDAP server.
mTLS authentication: Clients use TLS certificates for authentication.
The client application principal name can be identified in the certificate as a Common Name (CN). Alternatively,
principalMappingRulesin the Kafka CR can be used to identify the principal name.
The SASL/GSSAPI (Kerberos) and SASL/SCRAM methods are currently not supported in CFK directly through the CFK API. Use the Configuration overrides feature to configure SASL/GSSAPI and SASL/SCRAM. For the required configuration settings for the methods, see SASL/GSSAPI and SASL/SCRAM. Issues with SASL/GSSAPI (Kerberos) or SASL/SCRAM setups with CFK are outside the scope of Confluent Support.
Authentication to access ZooKeeper
CFK supports the following authentication mechanisms for Kafka to access ZooKeeper.
Important
Starting with Confluent Platform version 8.0, ZooKeeper is no longer part of Confluent Platform.
Authentication to access other Confluent Platform components
CFK supports the following authentication mechanisms for the rest of the Confluent components, specifically Connect, ksqlDB, Schema Registry, and Control Center:
Basic authentication: Clients use a username/password for authentication. The username/passwords are stored in a Kubernetes secret or in a directory in the container.
mTLS authentication: Clients use TLS certificates for authentication.
LDAP authentication (for Control Center and Control Center Legacy only): User principals and password credentials are stored in an LDAP server.
Single sign-on authentication (for Control Center and Control Center Legacy only)
Authentication to access MDS
CFK supports the following authentication mechanism for client applications and Confluent Platform components to access Metadata Service (MDS):