Configure Authentication with Confluent for Kubernetes¶

This document presents the authentication concepts and describes how to configure authentication with Confluent for Kubernetes.

For more details on security concepts in Confluent Platform, see Security.

For a comprehensive tutorial scenario on configuring authentication, see Deploy Secure Confluent Platform.

Authentication Overview¶

Authentication verifies the identity of users and applications connecting to Kafka and other Confluent components.

There are multiple aspects of authentication in Confluent:

Authentication to access Kafka - for client applications and Confluent components
Authentication to access ZooKeeper - for client applications and Confluent components
Authenticating to access Confluent REST API
Authentication to access Confluent Control Center

Authentication to access Kafka¶

Confluent for Kubernetes supports the following authentication mechanisms for client applications and Confluent Platform components to access Kafka:

SASL/Plain: Client applications use a username/password for authentication. The username/passwords are stored server-side in Kubernetes Secrets.
mTLS: Client applications use TLS certificates for authentication. The certificate has a CN that identifies the client application principal name.

Authentication to access ZooKeeper¶

Confluent for Kubernetes supports the following authentication mechanisms for Confluent components to access ZooKeeper:

Digest authentication

Authentication to access Confluent Control Center¶

Confluent Control Center is a web application that provides a GUI management and monitoring interface for Confluent. Users authenticate and sign in to Confluent Control Center through a login page.

Confluent for Kubernetes supports the following authentication mechanisms for Confluent Control Center:

Basic authentication: Username/password for authentication, where the username/passwords are stored server-side in Kubernetes Secrets.
LDAP authentication: User principals and password credentials are stored in a LDAP server.

Authentication to access Confluent REST API¶

The following Confluents component provide a HTTP(S) REST interface:

Connect
ksqlDB
Admin REST APIs
Schema Registry

Confluent for Kubernetes supports the following authentication mechanisms for these REST APIs:

Basic authentication: Username/password for authentication, where the username/passwords are stored server-side in Kubernetes Secrets.

Configure authentication to access Kafka¶

You have two options to choose from:

SASL/Plain: Client applications use a username/password for authentication. The username/passwords are stored server-side in Kubernetes Secrets.
mTLS: Client applications use TLS certificates for authentication. The certificate has a CN that identifies the client application principal name.

SASL/Plain¶

SASL/PLAIN is a simple username/password authentication mechanism that is typically used with TLS network encryption to implement secure authentication.

The username is used as the authenticated principal, which can then be used in authorization.

Enable SASL/Plain as the authentication mechanism

Configure a Kafka listener to use SASL/Plain as the authentication mechanism.

spec:
  listeners:
    internal:
      authentication:
        type: plain              --- [1]
        jaasConfig:
          secretRef: credential  --- [2]

[1] Required. Set it to plain.
[2] Required. Provide a Kubernetes Secret with the username/passwords.

Enable Confluent components to connect to Kafka

For each of the Confluent components that communicate with Kafka, configure the authentication mechanism.

spec:
  dependencies:
    kafka:
      authentication:
        type: plain                 --- [1]
        jaasConfig:
          secretRef: credential     --- [2]

[1] Required. Set it to plain.
[2] Required. Provide a Kubernetes Secret with the username/password used to authenticate to Kafka.

The secret content format is:
```
key: plain.txt
value:
username=username1
password=password1
```

mTLS¶

mTLS utilizes TLS certificates as an authentication mechanism. The certificate provides the identity.

The certificate Common Name (CN) is used as the authenticated principal, which can then be used in authorization.

Enable mTLS as the authentication mechanism

Configure a Kafka listener to use mTLS as the authentication mechanism.

spec:
  listeners:
    internal:
      authentication:
        type: mtls                                     --- [1]
        principalMappingRules:
        - RULE:.*CN[\s]?=[\s]?([a-zA-Z0-9.]*)?.*/$1/   --- [2]

[1] Required. Set it to mTLS.
[2] Optional. This specifies a mapping rule that extracts the principal name from the certificate Common Name.

Enable Confluent components to connect to Kafka

For each of the Confluent components that communicate with Kafka, configure the authentication mechanism.

spec:
  dependencies:
    kafka:
      authentication:
        type: mtls               --- [1]
      tls:
        enabled: true

[1] Required. Set it to mtls.

Configure Authentication to access ZooKeeper¶

Enable |zk| authentication

ZooKeeper supports authentication using the SASL Digest-MD5 mechanism.

spec:
  authentication:
    type: digest                 --- [1]
    jaasConfig:
      secretRef: credential      --- [2]

[1] Required. Set it to digest.

[2] Required. Provide a Kubernetes Secret with the username/passwords.

The secret content format is:

key: digest-users.json
value:
{
  "username1": "password1",
  "username2": "password2"
}

Enable |ak| to authenticate against |zk|

For components, like Kafka, that need to authenticate against ZooKeeper, configure the authentication mechanism with the following CR properties:

dependencies:
  zookeeper:
    authentication:
      type: digest               --- [1]
      jaasConfig:
        secretRef: credential    --- [2]

[1] Required. Set it to digest.
[2] Required. Provide a Kubernetes Secret with the username/password used to authenticate to ZooKeeper.

The secret content format is:
```
key: digest.txt
value:
username=username1
password=password1
```

Configure Authentication to access Confluent Control Center¶

Confluent Control Center supports authentication the following authentication methods:

Basic authentication mechanism
LDAP authentication.

Basic Authentication¶

The credentials are stored server side, in the following format: <username>: <password>, <role that user is assigned to>

By default, there are two roles available for a user:

Administrators
Restricted

Configure the Confluent Control Center CR with basic authentication:

kind: ControlCenter

spec:

  authentication:
    type: basic                 --- [1]
    basic:
      secretRef: credential     --- [2]

[1] Required. Set it to basic.
[2] Required. Provide a Kubernetes Secret with the username/passwords.

The secret content format is:
```
key: basic.txt
value:
admin: Developer1,Administrators
admin1: Developer1,Administrators
```

LDAP Authentication¶

Configure the Confluent Control Center CR to pull users and groups from an LDAP server:

kind: ControlCenter
spec:
  authentication:
    type: ldap                                       --- [1]
    ldap:
      secretRef:                                     --- [2]
      roles:                                         --- [3]
      restrictedRoles:                               --- [4]
      property:                                      --- [5]
      #properties
        #  useLdaps : "true"
        #  contextFactory: "com.sun.jndi.ldap.LdapCtxFactory"
        #  hostname: ""
        #  port: "389"
        #  bindDn: ""
        #  bindPassword: ""
        #  authenticationMethod: ""
        #  forceBindingLogin: "true"
        #  userBaseDn: ""
        #  userRdnAttribute: "sAMAccountName"
        #  userIdAttribute: "sAMAccountName"
        #  userPasswordAttribute: "userPassword"
        #  userObjectClass: "user"
        #  roleBaseDn: ""
        #  roleNameAttribute: "cn"
        #  roleMemberAttribute: "member"
        #  roleObjectClass: "group"

[1] Required. Set to ldap.
[2] Secret for LDAP credentials.

The expected key is ldap.txt in the secretRef. The content of the ldap.txt is:
```
username=<username>
password=<password>
```
[3] Optional. By default, it’s set to [“Administrators”, “Restricted”]
[4] Optional. List of roles with limited read-only access. No editing or creating allowed in Control Center.
[5] Required. See Configure LdapLoginModule for details.

Configure Authentication to access Confluent REST API¶

Server-side REST basic authentication¶

All Confluent Platform component require basic authentication configuration in the REST interface.

Username/passwords are used for authentication. The username/passwords are loaded through the secretRef or directoryPathInContainer.

Depending on the component, there is an additional roles functionality:

For Connect: there is no support for roles.
For ksqlDB: there is support for roles, and admin, developer, user, ksql-user roles are available.
For Schema Registry: there is support for roles, and admin, developer, user, sr-user roles are available.

The credentials are stored server side, in the following format: <username>: <password>, <role that user is assigned to>

Configure the component CR with basic authentication:

spec:
  authentication:
    type: basic                 --- [1]
    basic:
      secretRef: credential     --- [2]

[1] Required. Set it to basic.
[2] Required. Provide a Kubernetes Secret with the username/passwords.

The Secret content format is:
```
key: basic.txt
value:
username1: password1,role1
username2: password2,role2
```

Client-side REST basic authentication¶

All Confluent Platform components are required to communicate to other Confluent components using the basic authentication.

The username/password for basic authentication are either loaded through the secretRef or through directoryPathInContainer.

The Secret content format is:

key: basic.txt
value:
username=<username>
password=<password>