Install
Important
This software is available under a
Confluent enterprise license. You can use
this software for a 30-day trial period without a license key. If you are a subscriber, please contact
Confluent Support at support@confluent.io for more information.
The Confluent security plugins are an extension to Confluent Platform components. The security plugins are installed by default if you are
using ZIP and TAR archives, but must be installed manually if you are using DEB or RPM packages.
The following JAR files must be available in the classpath of the Schema Registry deployment. The default location for
the Schema Registry Security Plugins is:
<path-to-confluent>/share/java/confluent-security/schema-registry/confluent-security-plugins-common-<version>.jar
<path-to-confluent>/share/java/confluent-security/schema-registry/confluent-schema-registry-security-plugin-<version>.jar
ZIP and TAR Archives
If you installed Confluent Platform by using ZIP or TAR archives, the security plugins are installed by
default and are located in <path-to-confluent>/share/java/
in the individual component directories.
Ubuntu and Debian
If you installed Confluent Platform in a Ubuntu or Debian environment, you must install the plugins
separately with this command:
sudo apt-get update && sudo apt-get install confluent-security
Activate the Plugins
After installation, you can activate the plugins by adding the following to the Schema Registry config file (/etc/schema-registry/schema-registry.properties
).
resource.extension.class=io.confluent.kafka.schemaregistry.security.SchemaRegistrySecurityResourceExtension
resource.extension.class
Fully qualified class name of a valid implementation of the
SchemaRegistryResourceExtension
interface. This can be used to inject user
defined resources like filters. Typically used to add custom capability like
logging, security, etc. (Use resource.extension.class
instead of deprecated
schema.registry.resource.extension.class
.)
- Type: string
- Default: “”
- Importance: low
Note
resource.extension.class
should be configured to enable the plugin
ssl.client.auth
should be set to true
to use SSL auth mechanism
inter.instance.protocol
should be used set to https
, otherwise all secondary to primary forwards will fail. See also Additional configurations for HTTPS in the Schema Registry Security Overview. (schema.registry.inter.instance.protocol
is deprecated; use inter.instance.protocol
instead.)
- The X500 principal from ssl.keystore.location is used for secondary to primary forwarding. This user requires super user access, so should not be used for general Schema Registry access.
Authentication Mechanisms
The authentication mechanism for incoming requests to Schema Registry is determined by the confluent.schema.registry.auth.mechanism
config. Both SSL and Jetty authentication mechanisms are supported.
For Role Based Access Control, use Jetty as the authentication mechanism by setting the following in the Schema Registry config: confluent.schema.registry.auth.mechanism=JETTY_AUTH
To use the SSL mechanism for authentication, set the ssl.client.auth
to true
in the Schema Registry config. For the SSL authentication mechanism, the incoming X500
principal from the client is used as the principal for authorizing the Schema Registry
requests.
If the authentication mechanism is not set, all requests are rejected with a HTTP error code of 403.
See Schema Registry Authorization
for details on how this authorization happens and how to configure it.
- License Client Authentication
If you are using principal propagation, you must configure license client authentication for SASL
OAUTHBEARER (RBAC), SASL PLAIN, SASL SCRAM, and mTLS. For more information, see the following
documentation:
- License Client Authorization
If you are using principal propagation, you must configure authorization for RBAC and ACLs.
RBAC authorization
Run this command to add ResourceOwner
for the component user for the Confluent license
topic resource (default name is _confluent-license
).
confluent iam rolebinding create \
--role ResourceOwner \
--principal User:<service-account-id> \
--resource Topic:_confluent-license \
--kafka-cluster-id <kafka-cluster-id>
ACL authorization
Run this command to configure Kafka authorization, where bootstrap server, client configuration,
service account ID is specified. This grants create, read, and write on the _confluent-license
topic.
kafka-acls --bootstrap-server <broker-listener> --command-config <client conf> \
--add --allow-principal User:<service-account-id> --operation Create --operation Read --operation Write \
--topic _confluent-license
Configuration
confluent.license
Confluent will issue a license key to each subscriber. The license key will be a short snippet of text that you can copy and paste. Without the license key, you can use Confluent security plugins for a 30-day trial period. If you are a subscriber and don’t have a license key, please contact Confluent Support at support@confluent.io.
- Type: string
- Default: “”
- Importance: high
confluent.schema.registry.authorizer.class
The implementation used to authorize Schema Registry requests. Needs to be an implementation of the interface SchemaRegistryAuthorizer.
- Type: string
- Default: “”
- Importance: high
confluent.schema.registry.acl.topic
The topic used to store ACLs for the Schema Registry operations. This is optional. If this configuration is used, the
topic name is derived as kafkastore.topic
and is suffixed with _acl
.
confluent.topic.acl.super.users
Semicolon separated list of users who can be super users. One needs to be a super user to perform all global operations that don’t involve a subject like read or write compatibility. For example admin1;admin2
would make both admin1 and admin2 as super users.
- Type: string
- Default: “”
- Importance: medium
confluent.schema.registry.auth.mechanism
The mechanism used to authenticate Schema Registry requests. The principal from the
authentication mechanism is then used to optionally authorize using a configured authorizer.
- Type: string
- Default: “SSL”
- Importance: low
confluent.schema.registry.auth.ssl.principal.mapping.rules
Used for HTTPS. A list of rules for mapping distinguished name (DN) from the client certificate
to short name. The rules are evaluated in order and the first rule that matches
a principal name is used to map it to a short name. Any later rules in the list
are ignored. By default, DN of the X.500 certificate is the principal. For details
see mTLS to SASL Authentication.
- Type: list
- Default: “DEFAULT”
- Importance: low