CONFLUENT FOR KUBERNETES
Whereas authentication verifies the identity of users and applications,
authorization allows you to define the actions they are permitted to take once
Confluent for Kubernetes supports the following authorization mechanisms:
We recommend you use Confluent Role Based Access Control (RBAC) for production deployments.
With RBAC, CFK will automate the entire secure setup to adhere to production best practices.
Confluent for Kubernetes supports Role-Based Access Control (RBAC). RBAC is powered by
Confluent’s Metadata Service (MDS), which integrates with an LDAP server and
acts as the central authority for authorization and authentication data. RBAC
leverages role bindings to determine which users and groups can access specific
resources and what actions can be performed within those resources (roles).
Confluent provides audit logs, that record the runtime decisions of the
permission checks that occur as users/applications attempt to take actions that
are protected by ACLs and RBAC.
Confluent components also authorize access to Kafka using RBAC. There are a set
of principals and RoleBindings required for the Confluent components to function,
and these will be automatically generated as part of the automated deployment.
This comprehensive security guide
walks you through an end-to-end setup of role-based access control (RBAC) for Confluent with CFK.
We recommend you take the CustomResource spec and steps outlined there and adjust for your environment.
When you deploy with RBAC enabled, Confluent for Kubernetes automates the complete security setup. Here’s the end state architecture:
The following are the requirements for enabling and using RBAC with CFK:
You must have an LDAP server that Confluent Platform can use for authentication.
Confluent REST API is automatically enabled for RBAC and cannot be disabled when RBAC is enabled.
Use the Kafka bootstrap endpoint (same as the MDS endpoint) to access Confluent REST API.
You must create the user principals in LDAP that will be used by Confluent Platform components.
These are the defaul user principals:
You have created the LDAP user/password for a user who has a minimum of LDAP read-only permissions to allow Metadata Service (MDS) to query LDAP
about other users. For example, you’d create a user mds with password Developer!
You must create a user for Confluent REST API in LDAP and provide the username and password.
Confluent for Kubernetes auto-magically creates all required role bindings for Confluent Platform components
to function. These are created as ConfluentRoleBinding CustomResource
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 example, the testadmin principal is used as a Control Center UI user.
This set of rolebinding CRs represent the permissions needed:
kubectl apply -f https://raw.githubusercontent.com/confluentinc/confluent-kubernetes-examples/master/security/production-secure-deploy/controlcenter-testadmin-rolebindings.yaml
kubectl get confluentrolebinding
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
Log into MDS as the Kafka super user as below:
confluent login \
--url https://<kafka_bootstrap_endpoint> \
You need to pass the --ca-cert-path flag if:
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>' \
Get the Kafka cluster ID using one of the following commands:
confluent cluster describe --url https://<kafka_bootstrap_endpoint>
curl -ik \