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.

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, principalMappingRules in 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:

• SASL/DIGEST authentication
• mTLS authentication

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

Authentication to access MDS

CFK supports the following authentication mechanism for client applications and Confluent Platform components to access Metadata Service (MDS):

• Bearer authentication