Configure Simple ACLs

Configure Access Control Lists (ACLs) to authorize Apache Kafka®, KRaftController, and Schema Registry access using Confluent for Kubernetes. This topic also covers extracting principals from mTLS client certificates.

Configure Kafka with simple ACL

This section describes how to enable simple ACL authorization for Kafka and, if using KRaft, the KRaftController.

To deploy Kafka with the Access Control Lists authorization:

Specify the settings in your Kafka custom resource (CR):
```
kind: Kafka
spec:
  authorization:
    type: simple             # [1]
    superUsers:               # [2]
  configOverrides:
    server:                  # [3]
```
- [1] Required. Set to simple to configure Kafka to use the simple ACL authorization.
- [2] Optional. List of principals that bypass ACL authorization, in the format User:<principal>. For how principal names are derived from client certificates, see mTLS authentication: Extracting principal from certificate.
- [3] Specify an alternate authorizer class to use.
  
  The default authorizer class (authorizer.class.name) already handles both role-based access control (RBAC) and ACL authorization for ZooKeeper and KRaft deployments. KRaft-based Kafka clusters don’t need to separately set org.apache.kafka.metadata.authorizer.StandardAuthorizer when using this default class.
  
  If you want to use a more deployment-specific, alternate class, such as the following, specify the class here:
  
  kafka.security.authorizer.AclAuthorizer
  This class is used for ZooKeeper deployments in Confluent Platform 7.9 and earlier.
  
  org.apache.kafka.metadata.authorizer.StandardAuthorizer
  This class is used for KRaft deployments.
  
  For example:
```
kind: Kafka
spec:
  authorization:
    type: simple
    superUsers:
      - User:kafka
  configOverrides:
    server:
      - authorizer.class.name=kafka.security.authorizer.AclAuthorizer
```
If configuring a KRaft-based deployment, specify the settings in your KRaftController CR:
```
kind: KRaftController
spec:
  authorization:
    type: simple             # [1]
    superUsers:
  configOverrides:
    server:                  # [2]
```
- [1] Required. Set to simple to use the simple ACL authorization.
- [2] To use an alternate authorizer class, set the class only in the Kafka CR. Do not specify the authorizer class here in the KRaftController CR.

Configure Schema Registry with simple ACL

This section describes how to enable simple ACL authorization for Schema Registry.

To deploy Schema Registry with the Access Control Lists authorization, specify the settings in your Schema Registry CR. For example:

kind: SchemaRegistry
spec:
  configOverrides:
    server:
      - resource.extension.class=io.confluent.kafka.schemaregistry.security.SchemaRegistrySecurityResourceExtension
      - confluent.schema.registry.authorizer.class=io.confluent.kafka.schemaregistry.security.authorizer.schemaregistryacl.SchemaRegistryAclAuthorizer

Activate the Schema Registry Security Plugin using resource.extension.class.
Add the Schema Registry authorizer class using confluent.schema.registry.authorizer.class. You could specify io.confluent.kafka.schemaregistry.security.authorizer.schemaregistryacl.SchemaRegistryAclAuthorizer or io.confluent.kafka.schemaregistry.security.authorizer.RbacAndAclAuthorizer.

For details, see Schema Registry ACL Authorizer for Confluent Platform and Schema Registry ACL Configuration.

mTLS authentication: Extracting principal from certificate

This section describes how Confluent Platform derives a client principal from the Subject field of an mTLS certificate. It assumes mutual TLS (mTLS) authentication is already configured for Kafka; see mTLS authentication for setup instructions.

When mTLS is enabled, Confluent Platform determines the identity of the authenticated principal via data extracted from the client certificate. The Subject section of the certificate is used to determine the username.

For example, with the following certificate’s subject (C=US, ST=CA, L=Palo Alto), Confluent Platform extracts the username as User:L=Palo Alto,ST=CA,C=US.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            omitted...
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, ST=Palo Alto, L=CA, O=Company, OU=Engineering, CN=TestCA
        Validity
            Not Before: Mar 28 16:37:00 2019 GMT
            Not After : Mar 26 16:37:00 2024 GMT
        Subject: C=US, ST=CA, L=Palo Alto
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:

User:ANONYMOUS is the default user for internal clients and inter-broker communication.

When Kafka is configured with mTLS authentication, in addition to User:ANONYMOUS, the certificate username is required.

Typically, you have many different users and clients of Confluent Platform. In some cases, you may have shared client certificates across multiple users or clients, but the best practice is to issue unique client certificates for each user and certificate, and each certificate should have a unique subject or username. For each user or client, you must decide what they should be authorized to access within Confluent Platform, and ensure that the corresponding ACLs have been created for the subject or username of their corresponding client certificates. Follow the instructions in Access Control Lists authorization to enable ACL authorization for Kafka objects.