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>