Authentication in Confluent for Kubernetes¶
Authentication verifies the identity of users and applications connecting to Kafka and other Confluent components.
Confluent Platform components are configured without authentication by default. This document presents the supported authentication concepts and describes how to configure authentication for Confluent Platform using Confluent for Kubernetes (CFK).
For more details on security concepts in Confluent Platform, see Security in Confluent Platform.
For a comprehensive tutorial scenario for configuring authentication, see Deploy Secure Confluent Platform.
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.
Authentication to access ZooKeeper¶
CFK supports the following authentication mechanisms for Kafka to access ZooKeeper:
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 Confluent 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 only): User principals and password credentials are stored in an LDAP server.
- Single sign-on (for Control Center only) authentication