<a id="co-authenticate"></a>

# Configure Confluent Platform Authentication with 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](https://docs.confluent.io/platform/current/kafka/overview-authentication-methods.html).

For a comprehensive tutorial scenario for configuring authentication, see
[Deploy Secure Confluent Platform](https://github.com/confluentinc/confluent-kubernetes-examples/tree/master/security/secure-authn-encrypt-deploy).

#### 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](co-authenticate-kafka.md#co-authenticate-kafka-plain): 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](co-authenticate-kafka.md#co-authenticate-kafka-plain-ldap):
  Clients use a username/password for authentication. The username/passwords are
  stored in an LDAP server.
- [mTLS authentication](co-authenticate-kafka.md#co-authenticate-kafka-mtls): 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.
- [OAuth authentication](co-authenticate-kafka.md#co-authenticate-kafka-oauth)

The SASL/GSSAPI (Kerberos) and SASL/SCRAM methods are currently not supported in
CFK directly through the CFK API. Use the [Configuration overrides](co-configure-misc.md#co-config-overrides) feature
to configure SASL/GSSAPI and SASL/SCRAM. For the required configuration
settings for the methods, see [SASL/GSSAPI](https://docs.confluent.io/platform/current/kafka/authentication_sasl/authentication_sasl_gssapi.html#configuration)
and [SASL/SCRAM](https://docs.confluent.io/platform/current/kafka/authentication_sasl/authentication_sasl_scram.html#configuration).
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.

- [SASL/DIGEST authentication](co-authenticate-cp.md#co-authenticate-zookeeper-digest)
- [mTLS authentication](co-authenticate-cp.md#co-authenticate-zookeeper-mtls)

## 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](co-authenticate-cp.md#co-authenticate-cp-basic): 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](co-authenticate-cp.md#co-authenticate-cp-mtls): Clients use TLS
  certificates for authentication.
- [LDAP authentication (for Control Center and Control Center Legacy only)](co-authenticate-cp.md#co-authenticate-c3-ldap): User principals and password credentials are
  stored in an LDAP server.
- [OAuth authentication](co-authenticate-cp.md#co-authenticate-cp-oauth)
- [Single sign-on authentication (for Control Center and Control Center Legacy only)](co-authenticate-cp.md#co-authenticate-c3-sso)

## Authentication to access MDS

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

- [Bearer authentication](co-authenticate-kafka.md#co-authenticate-mds-bearer)
- [OAuth authentication](co-authenticate-kafka.md#co-authenticate-mds-oauth)