Request Forwarding from Follower to Leader in Confluent Platform

On this page you’ll find an explanation of request forwarding from follower to leader in role-based access control (RBAC) without and with mTLS authentication.

Token-based authentication with RBAC authorization

This section describes RBAC with token-based authentication alone. In this scenario, RBAC relies on token-based authorization. In this flow, the following happens:

  1. The client makes a request.

  2. A follower node receives the request with a token in the Authorization header and extracts the principal from the token.

  3. The follower node authorizes the principal against the Metadata Service (MDS).

  4. The follower node forwards the request containing the token to the leader.

  5. The leader extracts the principal from the token and performs its own authorization.

mutual TLS (mTLS) authentication authentication with RBAC authorization

In contrast, when RBAC relies on mTLS-based authentication, the initial request lacks an Authorization header, instead the system does the following sequence:

Request forwarding from follower to leader

  1. The client makes a request.

  2. The follower node extracts the principal from the client’s Transport Layer Security (TLS) certificate.

  3. The follower node impersonates the client by requesting an ImpersonationToken from MDS.

  4. MDS generates an ImpersonationToken, which the follower then includes in the Authorization header for the next step.

  5. The follower node forwards the request to the leader node using the follower’s own certificate for the connection.

  6. The leader node validates the principal from the follower’s TLS certificate, not the client’s certificate.

  7. The leader authorizes the user principal based on the ImpersonationToken, correctly reflecting the client’s identity and permissions in the resource access request.

Impersonation controls

You must set mandatory properties on the MDS server that prevent others from impersonating specific principals. You can also list the principals that can impersonate others.

To enable request forwarding with mTLS, you must provide both the list of protected users and the list of users allowed to impersonate others.

Mandatory impersonation protection

List the protected, privileged identities that others can’t impersonate for security reasons, for example:

confluent.metadata.server.impersonation.protected.users=User:<rp-principal-name>;User:<other-super-user>

You should always include super users in the list of protected users.

Who can impersonate

List the users that can impersonate a targeted user, for example:

confluent.metadata.server.impersonation.super.users=User:<rp-principal-name>;User:<sr-principal-name>;User:<connect-principal-name>;User:<other-super-user>

You can allow impersonation for specific service identities to enable request forwarding from followers to leaders. For example, multi-node Schema Registry or Connect clusters. Add the following configuration to MDS, specifying the service identities permitted to impersonate other users, replacing <service-identity1> and <service-identity2> with the actual service identities:

confluent.metadata.server.impersonation.super.users=User:<service-identity1>;User:<service-identity2>

Related content