Confluent REST Proxy Security Plugin


The REST Proxy Security plugin and ACLs do not work with the V1 consumer APIs because it uses a simple consumer that doesn’t support Kafka Security.

This is a commercial component of Confluent Platform.

Prerequisites: Either SSL or Basic authentication


Confluent REST Proxy allows producing and consuming messages of different formats through a REST interface. The security plugin provides the capability to authenticate an incoming request, build the principal, and then propagate the same requests to Apache Kafka® using the configured security mechanism. The authorization is enforced through Kafka ACLs, which provide granular access controls based on Kafka’s ACL implementation (such as limiting access to topics, in which case the client principal is propagated to Kafka and has the same access as if connected with that principal in any other client).

Client Security

Before configuring REST Proxy security, you must successfully implement client security (either SSL or Basic authentication) and verify that whichever security mechanism you have implemented is working. As authentication mechanisms, SSL and Basic authentication are mutually exclusive; you should only implement one or the other, not both. After confirming client security, you can use the REST Proxy Security plugin.

REST Proxy Connections Security

REST Proxy connections–one to a client and the other to the broker–are separate and distinct, and each of these connections requires a completely separate and different security setup. Essentially, you must set up security twice: once for the client-REST Proxy connection, and again for the REST proxy-broker connection.

SSL or Basic authentication are used for communication between a client and REST Proxy. SSL and SASL are used for communication between REST Proxy and the brokers.

HTTP Basic Auth also enables Confluent REST Proxy security to provide basic access limitations (for example, when you wish to deny access to specific users).

REST Proxy authentication occurs in two stages:

  1. Using the HTTP Client (the application communicating with REST Proxy client connection). The client authenticates using SSL, in which the incoming X500 principal is the distinguished name (DN) from the client SSL certificate, which is required for the principal propagation.
  2. Using REST Proxy (the Kafka Client). Using the Kafka protocol, the client authenticates using SSL or SASL, as with any other client.

REST Proxy security workflow

In stage 1, there is a basic work request to REST Proxy. Such requests are plain text/JSON, and contain metadata and content to be stored in Kafka, or requests to retrieve data from Kafka. REST Proxy receives these requests, translates them into Kafka requests, and satisfies them with the Kafka broker.

Credentials for all principals that will propagate must be present on the REST Proxy server. Note that this is both a technical challenge (for example, SSL principals must map to Kerberos principals) and a security challenge (everything required to impersonate a user is stored in REST Proxy outside the user’s control).

From a security perspective, there is authentication on the first JSON request (over HTTP), and REST Proxy translates the principal used in this HTTP authentication into a principal that can be authenticated (SSL/SASL) against the Kafka broker in stage 2. For example, if you use SSL for both stages then you must have the client SSL certificates for REST Proxy too.

No authorization actually occurs on REST Proxy (unlike in Schema Registry) so you must set broker ACLs to enforce any restrictions.