Configure Simple ACLs for Confluent Platform Using Confluent for Kubernetes

Configure Kafka with simple ACL

To deploy Kafka with the Access Control Lists authorization:

1. Specify the settings in your Kafka custom resource (CR):

   kind: Kafka
   spec:
     authorization:
       type: simple             --- [1]
       superUsers:
     configOverrides:
       server:                  --- [2]
   

   • [1] Required. Set to simple to configure Kafka to use the simple ACL authorization.

   • [2] Specify an alternate authorizer class to use.

     The default authorizer class (authorizer.class.name) is io.confluent.kafka.security.authorizer.ConfluentServerAuthorizer.

     To use an alternate class, such as kafka.security.authorizer.AclAuthorizer, org.apache.kafka.metadata.authorizer.StandardAuthorizer, specify the class here.

     For example:

     kind: Kafka
     spec:
       authorization:
         type: simple
         superUsers:
           - User:kafka
       configOverrides:
         server:
           - authorizer.class.name=kafka.security.authorizer.AclAuthorizer
     

2. 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 as described in the previous step. Do not specify the authorizer class here in the KRaftController CR.

Configure Schema Registry with simple ACL

To deploy Schema Registry with the 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

      confluent.schema.registry.authorizer.class=io.confluent.kafka.schemaregistry.security.authorizer.RbacAndAclAuthorizer

• 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 confluent.schema.registry.authorizer.class=io.confluent.kafka.schemaregistry.security.authorizer.schemaregistryacl.SchemaRegistryAclAuthorizer or confluent.schema.registry.authorizer.class=io.confluent.kafka.schemaregistry.security.authorizer.RbacAndAclAuthorizer.

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

mTLS authentication: Extracting principal from certificate

When mTLS authentication 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), the username will be extracted 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 cert user name is required.

Typically, you will have many different users and clients of Confluent Platform. In some cases, you may have shared client certificates across multiple users/clients, but the best practice is to issue unique client certificates for each user and certificate, and each certificate should have a unique subject/username. For each user/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/username of their corresponding client certificates. Follow the instructions in Authorization using ACLs to enable ACL authorization for Kafka objects.