Request Forwarding from Follower to Leader with mTLS RBAC in Confluent Platform

When role-based access control (RBAC) is enabled and token-based authorization is used, a follower node receives a request with a token in the Authorization header and performs the following steps:

  1. The follower node extracts the principal from the token.
  2. The follower node authorizes the principal against Metadata Service (MDS).
  3. The follower node forwards the request containing the token to the leader.
  4. The leader extracts the principal from the token and performs its own authorization.

However, with mTLS-based authentication with RBAC authorization, the initial request lacks an Authorization header, so the following actions are performed:

  1. The follower node extracts the principal from the client TLS certificate.
  2. The follower node forwards the request to the leader using its own certificate for the connection.
  3. The leader extracts the principal from the follower’s TLS certificate, not the client’s certificate.
  4. For the follower to forward the request to the leader, the follower can impersonate the client and obtain a token from MDS on their behalf. This token would then be added to the Authorization header before forwarding the request to the leader.
  5. The leader then authorizes based on this token, correctly reflecting the client’s identity and permissions in the resource access request.

Impersonation controls

To avoid impersonation of privileged users, you can:

  • Configure a list of protected identities to avoid impersonation of privileged users. For example, in MDS, you can configure a list of protected identities that cannot be impersonated by using the following configuration:

    confluent.metadata.server.impersonation.protected.users=User:<protected-user1>;User:<protected-user2>

  • Allow impersonation for specific service identities to facilitate 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 that are allowed to impersonate other users, replacing <service-identity1> and <service-identity2> with the actual service identities:

    confluent.metadata.server.impersonation.allowed.identities=User:<service-identity1>;User:<service-identity2>

Related content