Principal Propagation at REST Proxy for Mutual TLS (mTLS) in Confluent Platform

When Confluent REST Proxy forwards the identity, or principal, of a client authenticated using mutual TLS (mTLS) to Confluent Server or Kafka brokers, the identity is propagated from the REST Proxy to the Confluent Platform cluster. This process, called principal propagation, enables the Confluent Platform cluster to make authorization decisions based on the identity of the client and ensures that the identity is available to the applications that produce and consume messages to and from the Confluent Platform cluster.

REST Proxy needs to propagate the principal received from the mTLS certificate of its client or user to the Confluent Server brokers or a Confluent Platform cluster. For details on REST Proxy security and principal propagation, see Deploy Secure Standalone REST Proxy in Confluent Platform.

Security challenge

For REST Proxy to propagate the principal using mTLS, it needs to have access to the client certificate on its keystore, which is a security challenge. This principal propagation problem at REST Proxy when using mTLS for authentication exists irrespective of whether the authorization used in the Confluent Platform cluster is access control lists (ACLs) or role-based access control (RBAC).

Impersonation solution

In mTLS RBAC, impersonation at REST Proxy solves this problem by giving REST Proxy an elevated access (super user) in Confluent Platform, allowing it to impersonate its clients without having access to certificates of all its clients.

To further avoid misuse of the new impersonation service, there is also a list of protected users for which impersonation can never be done by REST Proxy.

This new enhanced secure principal propagation at REST Proxy is not available when mTLS is used with ACL authorization when RBAC is not enabled. Also, MDS must be configured in order for impersonation to work.

Understand how principal propagation works with secure impersonation

To understand how principal propagation works with secure impersonation, consider the following flow (see the image below):

  1. When REST Proxy receives a resource request to forward to Confluent Server brokers or a Confluent Platform cluster, it first authenticates the incoming request using the certificate.
  2. After successful authentication, the LoginService extracts the incoming user or client principal.
  3. Using the extracted principal, the LoginService requests an authorization token from the MDS service. This authorization token is built from the client or user principal at the MDS service and needs to be refreshed at regular intervals.
  4. Using the impersonated token, REST Proxy forwards the resource request to the Confluent Server brokers or Confluent Platform cluster.
  5. The Confluent Server brokers or Confluent Platform cluster authenticates and authorizes the resource request using the impersonated token and responds appropriately to the user or client.