Important

You are viewing documentation for an older version of Confluent Platform. For the latest, click here.

RBAC REST Proxy security configuration

This is a commercial component of Confluent Platform.

Prerequisites:

Confluent REST Proxy supports the cross-component, proprietary role-based access control (RBAC) solution to enforce access controls across the platform. The Confluent REST Proxy security plugin supports a bearer token-based authentication mechanism. With token authentication, Confluent REST Proxy can impersonate the user requests when communicating with Kafka brokers and Schema Registry clusters.

RBAC REST Proxy security resolves a number of usability challenges, including:

  • Local configuration of principals. With RBAC REST Proxy security, principals are no longer configured locally; instead, principals are handled by the Metadata service (MDS).
  • Existing REST Proxy security capabilities do not scale for very large deployments without significant manual operations; in RBAC REST Proxy security, the MDS binds and enforces a Kafka cluster configuration across different resources (Topics, Connectors, Schema Registry, etc.), thereby saving users the time and challenge associated with reconfiguring ACLs and roles separately for each Kafka cluster resource.

See also

To get started, try the automated RBAC example that showcases the RBAC functionality in Confluent Platform.

RBAC REST Proxy workflow

Here is a summary of the RBAC REST Proxy security workflow:

  1. A user makes REST API call (SSL/Basic auth) to REST Proxy using LDAP credentials for HTTP Basic authentication.
  2. The REST Proxy Security plugin authenticates the user with the MDS by acquiring a token for the authenticated user.
  3. The generated token is used to impersonate the user request and authenticate between Kafka clients and the Kafka cluster. For Kafka clients, the SASL_PLAINTEXT/SASL_SSL security protocol is used and the proprietary callback handler passes the token to the Kafka cluster. Similarly, when communicating with Schema Registry, the authentication token is passed to the Schema Registry client using a proprietary implementation of the BearerAuthCredentialProvider interface.
  4. If the user doesn’t have the requisite role or ACL permission for the requested resource (for example, topic, group, or cluster), then the REST API call fails and returns an error with the HTTP 403 status code.
../../_images/rbac-rest-proxy-security.png

RBAC REST Proxy security workflow

Configuring RBAC REST Proxy security

Note

RBAC REST Proxy Security uses the same plugin and activation method as Confluent REST Proxy Plugin. For details, see Using the Confluent REST Proxy Security Plugin.

To enable token authentication (in the kafka-rest.properties file) set rest.servlet.initializor.classes to io.confluent.common.security.jetty.initializer.InstallBearerOrBasicSecurityHandler and kafka.rest.resource.extension.class to io.confluent.kafkarest.security.KafkaRestSecurityResourceExtension.

rest.servlet.initializor.classes=io.confluent.common.security.jetty.initializer.InstallBearerOrBasicSecurityHandler
kafka.rest.resource.extension.class=io.confluent.kafkarest.security.KafkaRestSecurityResourceExtension
public.key.path

Location of the PEM encoded public key file to be used for verifying tokens.

  • Type: string
  • Default: “”
  • Importance: high
confluent.metadata.bootstrap.server.urls

Comma-separated list of bootstrap metadata server URLs to which this REST Proxy connects. For example: http://localhost:8080,http://localhost:8081

  • Type: string
  • Default: “”
  • Importance: high
confluent.metadata.basic.auth.user.info

Service user credentials information in the format: user:password.

  • Type: string
  • Default: “”
  • Importance: high

Principal propagation

Note

REST Proxy SSL-based propagation and RBAC-based propagation are mutually exclusive. REST Proxy security supports only one propagation method.

When token authentication is enabled, the generated token is used to impersonate the API requests. REST Proxy Kafka clients use the SASL_PLAINTEXT or SASL_SSL authentication mechanism to authenticate with Kafka brokers.

client.security.protocol
Set to either SASL_PLAINTEXT or SASL_SSL. For SASL_SSL, configure the required SSL client configurations as described in SSL encryption.
  • Type: string
  • Default: PLAINTEXT
  • Importance: high