This guide walks you through an end-to-end setup of role-based access control
(RBAC) for Confluent Platform with Operator. Note that there are many ways you can modify this
process for your own use cases and environments.
Kafka configuration
In the Confluent Operator configuration file ($VALUES_FILE
), set the following values
for Kafka:
kafka:
services:
restProxy:
authentication:
username: ----- [1]
password: ----- [2]
password: ""
mds:
https: ----- [3]
tokenKeyPair: |- ----- [4]
----- BEGIN RSA PRIVATE KEY -----
...
----- END RSA PRIVATE KEY -----
ldap:
address: ldaps://ldap.operator.svc.cluster.local:636 ----- [5]
authentication:
simple: ----- [6]
principal: cn=mds,dc=test,dc=com
credentials: Developer!
configurations: ----- [7]
groupNameAttribute: cn
groupObjectClass: group
groupMemberAttribute: member
groupMemberAttributePattern: CN=(.*),DC=test,DC=com
groupSearchBase: dc=test,dc=com
userNameAttribute: cn
userMemberOfAttributePattern: CN=(.*),DC=test,DC=com
userObjectClass: organizationalRole
userSearchBase: dc=test,dc=com
tls:
enabled: true
internalTLS: true ----- [8]
authentication:
principalMappingRules: ----- [9]
- RULE:^CN=([a-zA-Z0-9.]*).*$/$1/L
- DEFAULT
cacerts: |-
- [1] Set
username
to the Confluent REST API user you set up in LDAP.
- [2] Set
password
to the password of the user specified in [1].
- [3] Set
https: true
if you want MDS to serve HTTPS traffic.
- [4] Set
tokenKeyPair
to a PEM-encoded RSA key pair that MDS can use for signing tokens. These are required for token authentication between Confluent Platform components. See Create a PEM key pair for details on creating a public-private key pair.
- [5]
address
is the URL for the LDAP server Confluent Platform uses for authentication. If you provide a secure LDAPS URL, kafka.tls.cacerts
must be configured to allow MDS to trust the certificate presented by your LDAP server.
- [6]
principal
and credentials
are used by MDS to authenticate itself with the LDAP server.
- [7]
configurations
should be configured according to your LDAP settings.
- [8] When using NodePort or static routing for external access, set
internalTLS: true
.
- [9] For mTLS (
kafka.tls.authentication.type: tls
), the principal is retrieved from the certificate, and the user must be in the LDAP. For details about using principal mapping rules, see Principal Mapping Rules for SSL Listeners (Extract a Principal from a Certificate).
Confluent Platform components configuration
In the Confluent Operator configuration file ($VALUES_FILE
), set the following values
for each Confluent Platform component.
<component>:
dependencies:
mds:
authentication:
username:
password:
The usernames and passwords must be already set on your LDAP server, as
described in the assumptions.
If you do not want to enter this sensitive data into your $VALUES_FILE
, use
the --set
flag when applying the configuration with the helm upgrade
--install
command for each Confluent Platform component.
ksqlDB configuration with RBAC
When deploying Confluent Platform 5.5.x images with RBAC using Operator 1.6.x, ksqlDB pods will
fail the liveness and readiness probe checks. To workaround the issue, configure
/v1/metadata/id
as the liveness and readiness probe in the <operator home
directory>/helm/confluent-operator/charts/ksql/templates/ksql-psc.yaml
file as
shown in the following example:
liveness_probe:
http:
path: /v1/metadata/id
port: 9088
initial_delay_seconds: 30
timeout_seconds: 10
readiness_probe:
http:
path: /v1/metadata/id
port: 9088
initial_delay_seconds: 30
timeout_seconds: 10
Deploy Kafka with Metadata Service (MDS)
With MDS now configured, deploy Kafka components in the following order as
described in Install Confluent Operator and Confluent Platform:
- Operator
- ZooKeeper
- Kafka
Verify MDS configuration
Log into MDS to verify the correct configuration and to get the Kafka cluster ID.
You need the Kafka cluster ID for component role bindings.
Replace https://<kafka_bootstrap_endpoint>
in the below commands with the
value you set in your config file ($VALUES_FILE
) for
global.dependencies.mds.endpoint
.
Log into MDS as the Kafka super user as below:
confluent login \
--url https://<kafka_bootstrap_endpoint> \
--ca-cert-path <path-to-cacerts.pem>
You need to pass the --ca-cert-path
flag if:
- You have configured MDS to serve HTTPS traffic (
kafka.services.mds.https: true
) in Kafka configuration.
- The CA used to issue the MDS certificates is not trusted by system where you are running these commands.
Provide the Kafka username and password when prompted, in this example, kafka
and kafka-secret
.
You get a response to confirm a successful login.
Verify that the advertised listeners are correctly configured using the following command:
curl -ik \
-u '<kafka-user>:<kafka-user-password>' \
https://<kafka_bootstrap_endpoint>/security/1.0/activenodes/https
Get the Kafka cluster ID using one of the following commands:
confluent cluster describe --url https://<kafka_bootstrap_endpoint>
curl -ik \
https://<kafka_bootstrap_endpoint>/v1/metadata/id
For the examples in the remainder of this topic, save the output Kafka ID
from the above commands as an environment variable, $KAFKA_ID
.
Grant roles to Confluent Platform component principals
This section walks you through the workflow to create role bindings so that Confluent Platform
components are deployed and function correctly.
Log into MDS as described in the first step in Verify MDS configuration, and run the
confluent iam rolebinding
commands as specified in the following sections.
Set the --principal
option to User:<component-ldap-user>
using the
component LDAP users. The commands in this section use the example component
users listed in the assumptions.
Schema Registry role binding
Grant the required roles to the Schema Registry user to deploy the Schema Registry service.
Set --schema-registry-cluster-id
to id_schemaregistry_operator
, or more
generally to id_<SR-component-name>_<namespace>
where <SR-component-name>
is
the value of schemaregistry.name
in your config file ($VALUES_FILE
), and
<namespace>
is the Kubernetes namespace where you want to deploy Schema Registry.
confluent iam rolebinding create \
--kafka-cluster-id $KAFKA_ID \
--principal User:sr \
--role SecurityAdmin \
--schema-registry-cluster-id id_schemaregistry_operator
Set --resource
to Group:id_schemaregistry_operator
, or more generally to
Group:id_<SR-component-name>_<namespace>
.
confluent iam rolebinding create \
--kafka-cluster-id $KAFKA_ID \
--principal User:sr \
--role ResourceOwner \
--resource Group:id_schemaregistry_operator
Set --resource
to Topic:_schemas_schemaregistry_operator
, or more
generally to Topic:_schemas_<SR-component-name>_<namespace>
.
confluent iam rolebinding create \
--kafka-cluster-id $KAFKA_ID \
--principal User:sr \
--role ResourceOwner \
--resource Topic:_schemas_schemaregistry_operator
confluent iam rolebinding create \
--kafka-cluster-id $KAFKA_ID \
--principal User:sr \
--role ResourceOwner \
--resource Topic:_confluent-license
Kafka Connect role binding
Grant the required roles to the Connect user to deploy the Connect
service.
Set --connect-cluster-id
to id_connect_operator
, or more generally to
id_<Connect-component-name>_<namespace>
where <Connect-component-name>
is the value of connect.name
in your config file ($VALUES_FILE
), and
<namespace>
is the Kubernetes namespace where you want to deploy Connect.
confluent iam rolebinding create \
--kafka-cluster-id $KAFKA_ID \
--principal User:connect \
--role SecurityAdmin \
--connect-cluster-id id_connect_operator
Set --resource
to Group:operator.connectors
, or more generally to
<namespace>.<Connect-component-name>
.
confluent iam rolebinding create \
--kafka-cluster-id $KAFKA_ID \
--principal User:connect \
--role ResourceOwner \
--resource Group:operator.connectors
confluent iam rolebinding create \
--kafka-cluster-id $KAFKA_ID \
--principal User:connect \
--role DeveloperWrite \
--resource Topic:_confluent-monitoring \
--prefix
Set --resource
to Topic:operator.connectors-
, or more generally to
<namespace>.<Connect-component-name>-
.
confluent iam rolebinding create \
--kafka-cluster-id $KAFKA_ID \
--principal User:connect \
--role ResourceOwner \
--resource Topic:operator.connectors- \
--prefix
Confluent Replicator role binding
Grant the required roles to the Replicator user to deploy the Replicator service.
Set --resource
to Group:operator.replicator
, or more generally to
<namespace>.<Replicator-component-name>
where <Replicator-component-name>
is
the value of replicator.name
in your config file ($VALUES_FILE
), and
<namespace>
is the Kubernetes namespace where you want to deploy Replicator.
confluent iam rolebinding create \
--kafka-cluster-id $KAFKA_ID \
--principal User:replicator \
--role ResourceOwner \
--resource Group:operator.replicator
confluent iam rolebinding create \
--kafka-cluster-id $KAFKA_ID \
--principal User:replicator \
--role DeveloperWrite \
--resource Topic:_confluent-monitoring \
--prefix
Set --resource
to Topic:operator.replicator-
, or more generally to
<namespace>.<Replicator-component-name>-
where <Replicator-component-name>
is the value of replicator.name
in your config file ($VALUES_FILE
), and
<namespace>
is the Kubernetes namespace where you want to deploy Replicator.
confluent iam rolebinding create \
--kafka-cluster-id $KAFKA_ID \
--principal User:replicator \
--role ResourceOwner \
--resource Topic:operator.replicator- \
--prefix
ksqlDB role binding
Grant the required roles to the ksqlDB user to deploy the ksqlDB service.
Set --ksql-cluster-id
to operator.ksql_
, or more generally to
<namespace>.<ksqldb-component-name>_
where <ksql-component-name>
is the
value of ksql.name
in your config file ($VALUES_FILE
), and
<namespace>
is the Kubernetes namespace to which you want to deploy
ksqlDB.
confluent iam rolebinding create \
--kafka-cluster-id $KAFKA_ID \
--principal User:ksql \
--role ResourceOwner \
--ksql-cluster-id operator.ksql_ \
--resource KsqlCluster:ksql-cluster
confluent iam rolebinding create \
--kafka-cluster-id $KAFKA_ID \
--principal User:ksql \
--role ResourceOwner \
--resource Topic:_confluent-ksql-operator.ksql_ \
--prefix
Confluent Control Center role binding
Grant the required roles to the Control Center user to deploy the Control Center service.
confluent iam rolebinding create \
--principal User:c3 \
--role SystemAdmin \
--kafka-cluster-id $KAFKA_ID
Deploy the remaining Confluent Platform components
After granting roles to the various Confluent Platform components, you can successfully deploy
those components with Confluent Operator, and the components can be authorized to
communicate with each other as necessary.
Follow Install Confluent Operator and Confluent Platform to deploy the rest of Confluent Platform.
Grant roles to the Confluent Control Center user to be able to administer Confluent Platform
Control Center users require separate roles for each Confluent Platform component and resource
they wish to view and administer in the Control Center UI. Grant explicit
permissions to the users as shown below.
In the following examples, the testadmin
principal is used as a Control Center UI user.
Since there’s no access given to testadmin
yet, this user will be able to log
into Confluent Control Center, but nothing will be visible until the appropriate permissions are
granted as described in the following sections.
Grant permission to view and administer the Kafka cluster
confluent iam rolebinding create \
--kafka-cluster-id $KAFKA_ID \
--role ClusterAdmin \
--principal User:testadmin
Grant permission to view and administer the Connect cluster
Set --connect-cluster-id
using the pattern:
<namespace>.<Connect-component-name>
. The following example uses
operator.connectors
.
confluent iam rolebinding create \
--kafka-cluster-id $KAFKA_ID \
--connect-cluster-id operator.connectors \
--principal User:testadmin \
--role SystemAdmin
Grant permission to view and administer the Replicator cluster
Set --connect-cluster-id
using the pattern:
<namespace>.<Connect-component-name>
. You need the Connect cluster ID for
Replicator role binding because Replicator runs in the Connect clusters. The
following example uses operator.connectors
.
confluent iam rolebinding create \
--kafka-cluster-id $KAFKA_ID \
--connect-cluster-id operator.replicator \
--principal User:testadmin \
--role SystemAdmin
Grant permission to view and administer the ksqlDB cluster
Set --ksql-cluster-id
using the pattern:
<namespace>.<ksqldb-component-name>_
. The following example uses
operator.ksql_
.
confluent iam rolebinding create \
--kafka-cluster-id $KAFKA_ID \
--ksql-cluster-id operator.ksql_ \
--resource KsqlCluster:ksql-cluster \
--principal User:testadmin \
--role ResourceOwner