Migrate from LDAP to mutual TLS (mTLS) authentication in a RBAC-enabled Confluent Platform Cluster

An existing RBAC-enabled Confluent Platform cluster can be migrated from HTTP Basic Authentication (LDAP) to mTLS authentication. Migrating from LDAP to mTLS provides the following benefits:

RBAC principal compatibility

There is no impact on the already defined RBAC access rules if principal compatibility is maintained before and after the migration. For example, if an access policy is defined for user schema-registry with principal schema-registry in the existing cluster, the principal extracted from mTLS certificate should match schema-registry as the principal for user schema-registry after migrating to mTLS.

Zero downtime for clients

During the migration phase, Confluent Platform services can simultaneously accept both an mTLS certificate and LDAP tokens for authentication by using the AuthenticationHandler. Metadata Service (MDS) can also accept both mTLS for authentication along with having LDAP for the backing user store. This ensures there is backward compatibility and zero downtime for clients that are not migrated to mTLS from LDAP.

Limitations with group-based authorization

Confluent Platform mTLS identities for RBAC authorization does not support group-based authorization. Ensure the access policies defined for group-based authorization before migration are explicitly defined for individual principals after a Confluent Platform service or client application is migrated from LDAP to mTLS.

Sample Cluster with Migration from LDAP to mTLS

The following sample migration cluster state diagram shows a Confluent Platform cluster before migrating from HTTP Basic Authentication (LDAP) to mTLS while using RBAC authorization.

• Before migration, the cluster uses HTTP Basic Authentication with LDAP server as the user store at MDS.
• For Confluent Server brokers, SASL/Plain authentication is used, but powered by LDAP as the user store.
• After MDS validates the HTTP Basic Authentication credentials of a client using LDAP server, MDS issues a token to the client.
• The client uses the token in Bearer Auth for subsequent authentication requests across the cluster. Here, the client can be a Confluent Platform service or a producer/consumer application.

The following diagram shows the Confluent Platform cluster in the migration phase where the cluster accepts both LDAP and mTLS from the client applications.

• mTLS authentication is enabled at MDS which accepts a TLS certificate for authentication.
• Confluent Platform services, like Schema Registry and Connect, are now using AuthenticationHandler, allowing them to accept the previous LDAP-based tokens as well as the mTLS certificates for authentication. Additionally, Confluent Server is configured to accept mTLS for client authentication.
• Client App1 started using mTLS for authentication while Client App2 continues using LDAP. Also, all internal service-to-service authentications within the cluster are migrated to mTLS.
• No changes were required for RBAC access rules because the principals of the Confluent Platform services, including Client App1 and Client App2, Connect, and Schema Registry, are the same before and after the migration to mTLS.
• In cases where request forwarding is required, for example, Confluent Control Center request forwarding end user requests to underlying Confluent Platform services, authentication can still use mTLS for authentication of Confluent Platform services along with token based authorization for the end user.

To avoid authentication failures for clients, the platform services may need to enable REQUESTED mode for certificate-based authentication in some cases. To learn about this mode and other options, see Deployment patterns for mTLS authentication with RBAC authorization in Confluent Platform.

Steps to migrate LDAP to mTLS in a Confluent Platform cluster

To ensure a smooth transition, review and complete the following process:

1. Ensure the access policies defined for group-based authorization before you migrate are explicitly defined for individual principals after a Confluent Platform service or client application migrates from LDAP to mTLS.

   Confluent Platform mTLS identities for RBAC authorization does not support group-based authorization.

2. Enable mTLS authentication for MDS.

3. Enable AuthenticationHandler for all Confluent Platform services.

4. Enable the certificate or token-based authentication for Confluent Platform services.

5. Migrate from LDAP to mTLS for Confluent Platform service authentication to each other.

Related content

• For information regarding a configuration that simultaneously uses two or more authentication protocols, see Use Multi-Protocol Authentication in Confluent Platform.
• To learn how to configure mTLS authentication with role-based access control (RBAC) authorization, see Configure mTLS RBAC in Confluent Platform.
• For information on how to use MDS as the token issuer for client authentication and authorization, see Metadata Service (MDS) as Token Issuer in Confluent Platform.
• To understand the capabilities that help enable mTLS Authentication with RBAC authorization, see Use mTLS Authentication with RBAC Authorization in Confluent Platform.
• For an explanation of request forwarding from follower to leader in RBAC without and with mTLS authentication see Request Forwarding from Follower to Leader in Confluent Platform.
• To see examples of migrating from LDAP to mTLS in a running RBAC-enabled cluster. see the Confluent for Kubernetes and Ansible Playbooks for Confluent Platform