Use mTLS Authentication with RBAC Authorization in Confluent Platform

Starting with the Confluent Platform 7.8 release, Confluent Platform security has the following new capabilities to help enable mTLS Authentication with RBAC authorization:

  • Metadata Service (MDS) in Confluent Server brokers accept TLS certificates for authentication from clients.
  • All the Confluent Platform REST interfaces accept TLS certificates for authentication from which the principal for RBAC authorization can be extracted from.
  • RBAC authorization can be enabled without using any identity provider.

Limitations

For the Confluent Platform 7.8 release, the following limitations apply to the use of mTLS authentication with RBAC authorization:

  • Only new deployments are supported. Upgrading from access control lists (ACLs) to RBAC with mTLS identity and without the use of a backing identity provider is currently not supported.
  • ksqlDB is not supported with mTLS RBAC.
  • Group authorization is not supported with mTLS RBAC. More specifically, group based RBAC authorisation will not be available for principals (identities) extracted from mTLS certificates.
  • Confluent CLI currently does not support user authentication with mTLS RBAC on the cluster.

Example of mTLS authentication with RBAC authorization

The following diagram shows a high-level example of a resource authorization request using mTLS authentication and RBAC authorization.

mTLS authentication with RBAC authorization

The following steps describe the mTLS authentication with RBAC authorization process displayed in the diagram:

  1. Schema Registry and MDS are configured to accept TLS certificates for authentication.
  2. MDS is configured for RBAC authorization.
  3. Schema Registry receives a resource access request.
  4. Schema Registry checks if the authentication request contains a certificate or if there is any additional token present in the request because mTLS can be used for authentication along with token authentication.
  5. Assuming the client provided only a certificate, Schema Registry validates the certificate.
  6. Once certificate validation is successful, client authentication is successful.
  7. Post successful authentication, principal of the client is extracted from the certificate.
  8. Now, Schema Registry authenticates to MDS using a service-to-service mTLS authentication setup by providing its own certificate for authentication with MDS.
  9. Post successful authentication, Schema Registry checks for access policy rules defined for the extracted principal and requested resource.
  10. MDS verifies the rolebindings and allows/denies the resource request.