Enable RBAC in a Running Cluster
Note
This section is based on the assumption that you have a security-enabled
cluster. If you are migrating from a PLAINTEXT cluster, refer to
Adding security to a running cluster for more details on enabling security.
You can enable RBAC in a running cluster using rolling restarts without disrupting applications using the cluster.
This is done in phases. If you are configuring a separate new metadata cluster, follow
the instructions in Configure Metadata Service (MDS) to start up the metadata cluster first before migrating other clusters.
You can also convert one of your existing clusters to run Metadata Service (MDS) using the following steps:
- If the broker has only one listener, open up a separate port for inter-broker communication and perform a
rolling restart.
- If a listener was added in step (1), perform another rolling restart using the new listener for inter-broker
communication.
- If brokers are not currently using an authorizer, create ACLs for broker principal as well as user principals
of all applications. You can add ACLs without restarting brokers in this step.
- Enable RBAC and MDS. If using Confluent Platform components, open an additional port for token-based
authentication. Perform a rolling restart with updated configs.
After all the brokers in the metadata cluster have started up, you can enable RBAC in your other clusters and
other Confluent Platform components. These updates can be performed in any order, but you must configure relevant
RBAC role bindings before enabling RBAC in each component. Brokers can continue to use your existing ACLs.
- Configure RBAC for brokers in other clusters using rolling restart. For each cluster, create ACLs or
role bindings for broker resources before restarting the cluster if brokers are not already using
an authorizer. Existing ACLs will continue to be used.
- Configure RBAC role bindings for resources of other components.
- Enable RBAC in all Confluent Platform components.
For more details on configuring security protocols, refer to the sections for the protocols:
Enable RBAC and Metadata Service (MDS) in a Running Cluster
As an example, if you have a running cluster with a single listener using SASL/SCRAM-SHA-256 and you are enabling
RBAC and MDS on this cluster, you can follow these steps to perform incremental updates without disruptions to
applications using the cluster. The example in this section assumes that brokers are running using the
following listener configs:
listeners=SASL_PLAINTEXT://:9092
advertised.listeners=SASL_PLAINTEXT://localhost:9092
security.inter.broker.protocol=SASL_PLAINTEXT
sasl.mechanism.inter.broker.protocol=SCRAM-SHA-256
sasl.enabled.mechanisms=SCRAM-SHA-256
listener.name.sasl_plaintext.scram-sha-256.sasl.jaas.config= \
org.apache.kafka.common.security.scram.ScramLoginModule required \
username="kafka" password="kafka-secret";
Open another listener for inter-broker communication
Brokers running MDS require a separate listener for inter-broker communication that is not shared
with other client listeners that may rely on role-based access control. If inter-broker communication is already
on a separate listener, you can skip this step. Otherwise, create another listener with the same configs as your
existing listener. Add a listener in this step with the existing listener as inter-broker listener. The example
below renames the existing listener for readability.
listeners=EXTERNAL://:9092,INTERNAL://:9093
advertised.listeners=EXTERNAL://localhost:9092,INTERNAL://localhost:9093
listener.security.protocol.map=EXTERNAL:SASL_PLAINTEXT,INTERNAL:SASL_PLAINTEXT
inter.broker.listener.name=EXTERNAL
sasl.mechanism.inter.broker.protocol=SCRAM-SHA-256
listener.name.external.sasl.enabled.mechanisms=SCRAM-SHA-256
listener.name.internal.sasl.enabled.mechanisms=SCRAM-SHA-256
listener.name.external.scram-sha-256.sasl.jaas.config= \
org.apache.kafka.common.security.scram.ScramLoginModule required \
username="kafka" password="kafka-secret";
listener.name.internal.scram-sha-256.sasl.jaas.config= \
org.apache.kafka.common.security.scram.ScramLoginModule required \
username="kafka" password="kafka-secret";
Note
When modifying an existing cluster to enable RBAC or changing the authorization
mechanism for RBAC, be aware that the listener name must be in lowercase.
The format adhered to in the preceding example is: listener.name.<lowercase-listener-name>.sasl.enabled.mechanisms=SCRAM-SHA-256
.
Incrementally update all brokers using rolling restart.
Switch to new listener for inter-broker communication
After the new internal listener is added to all brokers, perform another incremental update to switch inter-broker
communication to the new listener.
inter.broker.listener.name=INTERNAL
listener.name.external.scram-sha-256.sasl.jaas.config= \
org.apache.kafka.common.security.scram.ScramLoginModule required;
Create ACLs
If your brokers are not configured with an authorizer, you must first configure ACLs for the broker principal
and principals used by other applications using the cluster. Otherwise access will be denied when RBAC is enabled.
If you are already using SimpleAclAuthorizer
or LDAP Authorizer, then your existing ACLs will be applied and
no additional ACLs are required. For brokers without authorizer, you can create ACLs for broker resources
directly in ZooKeeper using kafka-acls
command as described in Authorization using ACLs. You do not have
to restart brokers in this step.
Enable RBAC and Metadata Service (MDS)
Brokers are now ready to be RBAC-enabled. Perform these config updates for each broker and
incrementally update all brokers using rolling restart.
Configure broker to use Confluent Server Authorizer. You must retain ACL provider along with RBAC to ensure that existing ACLs
are applied. Configure at least one principal in super.users
for brokers in the metadata cluster
to enable role bindings to be created for other clusters. In this example, the user admin
is granted access to create role bindings for any cluster.
authorizer.class.name=io.confluent.kafka.security.authorizer.ConfluentServerAuthorizer
confluent.authorizer.access.rule.providers=ZK_ACL,CONFLUENT
super.users=User:admin
Follow the instructions in Configure Metadata Service (MDS) to create a key pair for MDS. Configure MDS
on the broker. You must update paths to the key files to match your set up.
confluent.metadata.server.listeners=http://0.0.0.0:8090
confluent.metadata.server.advertised.listeners=http://localhost:8090
confluent.metadata.server.authentication.method=BEARER
confluent.metadata.server.token.key.path=<path-to-mds-token-key.pem>
If you are using other Confluent Platform components, create a new listener to enable token-based
authentication using MDS.
listeners=EXTERNAL://:9092,INTERNAL://:9093,TOKEN://:9094
advertised.listeners=EXTERNAL://localhost:9092,INTERNAL://localhost:9093,TOKEN://localhost:9094
listener.security.protocol.map=EXTERNAL:SASL_PLAINTEXT,INTERNAL:SASL_PLAINTEXT,TOKEN:SASL_PLAINTEXT
listener.name.token.sasl.enabled.mechanisms=OAUTHBEARER
listener.name.token.oauthbearer.sasl.jaas.config= \
org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \
publicKeyPath="/path/to/publickey.pem";
listener.name.token.oauthbearer.sasl.login.callback.handler.class=io.confluent.kafka.server.plugins.auth.token.TokenBearerServerLoginCallbackHandler
listener.name.token.oauthbearer.sasl.server.callback.handler.class=io.confluent.kafka.server.plugins.auth.token.TokenBearerValidatorCallbackHandler
If you are using LDAP group-based authorization in any of your clusters,
you must configure LDAP for brokers running MDS. Replace
the prefix ldap.authorizer.
with ldap.
in all the LDAP configs. For example:
ldap.java.naming.provider.url=ldap://LDAPSERVER.EXAMPLE.COM:3268/DC=EXAMPLE,DC=COM
If you are enabling RBAC in other Confluent Platform components, you should configure brokers running MDS with
LDAP configs that match your LDAP server to enable centralized authentication using LDAP. Refer to
Configure LDAP Authentication for details.
If your metadata cluster has less than 3 brokers, adjust the replication factor for metadata topics.
For example:
confluent.metadata.topic.replication.factor=1
confluent.license.replication.factor=1
Restart Confluent Platform Components with RBAC
You can now enable RBAC for all your Confluent Platform components. You may do this in any order. Refer
to the sections for each component to enable RBAC in the component: