<a id="co-simple-acls"></a>

# Configure Simple ACLs for Confluent Platform Using Confluent for Kubernetes

## Configure Kafka with simple ACL

To deploy Kafka with the [Access Control Lists
authorization](/platform/current/kafka/authorization.html#kafka-authorization):

1. Specify the settings in your Kafka custom resource (CR):
   ```yaml
   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`, and
     it handles RBAC and ACL (for ZooKeeper and KRaft). Therefore, when you use the
     default authorizer class in CFK, it’s not required to set
     `org.apache.kafka.metadata.authorizer.StandardAuthorizer` for
     KRaft-based Kafka clusters.

     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:
     ```yaml
     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:
   ```yaml
   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](/platform/current/kafka/authorization.html#kafka-authorization), specify the
settings in your Schema Registry CR. For example:

```yaml
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](https://docs.confluent.io/platform/current/confluent-security-plugins/schema-registry/authorization/sracl_authorizer.html)
and  [Schema Registry ACL Configuration](https://docs.confluent.io/platform/current/confluent-security-plugins/schema-registry/install.html#configuration).

## 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`.

```none
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](/platform/current/kafka/authorization.html#kafka-authorization) to enable ACL authorization for Kafka
objects.