Authentication Methods Overview
By default, Kafka is installed with no authentication. Confluent Platform supports the following
authentication mechanisms and protocols for Kafka brokers.
SASL (Simple Authentication Security Layer) is a framework that provides developers
of applications and shared libraries with mechanisms for authentication, data
integrity-checking, and encryption.
SASL using JAAS
Kafka uses the Java Authentication and Authorization Service (JAAS) for SASL
configuration. You must provide JAAS configurations for all SASL authentication
mechanisms. This topic explains how to configure JAAS for SASL.
SASL/GSSAPI uses your Kerberos or Active Directory server for authentication.
Only suitable for use in non-production Kafka installations, SASL/OAUTHBEARER
enables the use the OAuth 2 Authorization framework in a SASL context to create
and validate unsecured JSON web tokens for authentication.
SASL/PLAIN uses a simple username and password for authentication.
SASL/SCRAM uses usernames and passwords stored in ZooKeeper. Credentials are created
Delegation Tokens (SASL/SSL)
Performs authentication based on delegation tokens that use a lightweight
authentication mechanism that you can use to complement existing SASL/SSL
methods. Delegation tokens are shared secrets between Kafka brokers
Performs client authentication with LDAP (or AD) across all of your Kafka clusters
that use SASL/PLAIN.
With mTLS (mutual TLS) authentication–also known as “two-way authentication”–both
Kafka clients and servers use TLS certificates to verify each other’s identities to
ensure that traffic is secure and trusted in both directions.
HTTP Basic Auth
You can use HTTP Basic Authentication
to authenticate with the Admin REST APIs using a username and password pair, which
are presented to the REST Proxy server using the
Authorization HTTP header.