Configure Authorization with 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 connected.

Confluent for Kubernetes (CFK) supports the following authorization mechanisms:

No Authorization
Confluent Role Based Access Control (RBAC) authorization, with a dependency on LDAP server

We recommend you use Confluent Role Based Access Control (RBAC) for production deployments. With RBAC, CFK automates the entire security setup to adhere to production best practices.

Confluent Role Based Access Control (RBAC)¶

CFK 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.

Note

RBAC with CFK can be enabled only for new installations. You cannot upgrade an existing cluster and enable it with RBAC.

The comprehensive security tutorial 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 the steps outlined in the scenario and adjust for your environment.

When you deploy Confluent Platform with RBAC enabled, CFK automates the complete security setup. Here’s the end state architecture:

LDAP server requirements¶

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.

Currently, CFK only supports the GROUPS LDAP search mode. The search mode indicates if the user-to-group mapping is retrieved by searching for group or user entries. If you need to use the USERS search mode, specify using the configOverrides setting in the Kafka CR as below:
```
spec:
  configOverrides:
    server:
      - ldap.search.mode=USERS
```
See Sample Configuration for User-Based Search for more information.
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 default user principals:
- Kafka: kafka/kafka-secret
- Confluent REST API: erp/erp-secret
- Confluent Control Center: c3/c3-secret
- ksqlDB: ksql/ksql-secret
- Schema Registry: sr/sr-secret
- Replicator: replicator/replicator-secret
- Connect: connect/connect-secret
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.

Automated creation of rolebindings for Confluent Platform component principals¶

CFK automatically creates all required role bindings for Confluent Platform components as ConfluentRoleBinding custom resources (CRs).

Review the role bindings created by CFK:

kubectl get confluentrolebinding

Grant roles to a 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 example, the testadmin principal is used as a Control Center UI user.

Grant permission to view and administer Confluent Platform components¶

The rolebinding CRs in the examples GitHub repo specifies the permissions needed in CFK. Create the rolebindings with the following command:

kubectl apply -f \
  https://raw.githubusercontent.com/confluentinc/confluent-kubernetes-examples/master/security/production-secure-deploy/controlcenter-testadmin-rolebindings.yaml

Check the roles created:

kubectl get confluentrolebinding

Troubleshooting: 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://<mds_endpoint> in the below commands with the value you set in the spec.dependencies.mds.endpoint in the Kafka CR.

Log into MDS as the Kafka super user as below:
```
confluent login \
 --url https://<mds_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.spec.dependencies.mds.tls.enabled: true).
- 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://<mds_endpoint>/security/1.0/activenodes/https

Get the Kafka cluster ID using one of the following commands:

confluent cluster describe --url https://<mds_endpoint>

curl -ik \
 https://<mds_endpoint>/v1/metadata/id