Inter-broker and metadata store security

Learn about inter-broker, ZooKeeper, and KRaft security.

Inter-broker security

Kafka exposes ports 9090 and 9091 for inter-broker communication as well as communication with Cruise Control and the operators. These listeners are not configurable and use mTLS authentication by default. As a result, only clients that have access to the certificate secrets can access Kafka through these listeners. To protect these secrets, it is possible to further limit access to the cluster by using RBAC authorization to restrict namespace access to specific users.

By separating internal and external listeners, internal listener configurations can be simplified and kept secure when opening the cluster for access to external clients.

ZooKeeper security

Communication between the ZooKeeper servers on all ports, as well as between clients and ZooKeeper, is encrypted using TLS. Communication between Kafka brokers and ZooKeeper servers is also encrypted.

When both a keystore and a truststore are configured for both Kafka and ZooKeeper, both components use mTLS. There is no separate flag or configuration property you can use. This is enabled by default.

ZooKeeper uses ACLs to restrict access to Znodes. The ACL usage (zookeeper.set.acl) is not configurable, as it is managed by the Strimzi Cluster Operator itself.

KRaft security

KRaft and Kafka node communication as inter-broker communication use listeners which are not configurable and use mTLS authentication. This means the communication is encrypted by default.

If the Kafka resource is configured with the simple authorization plugin that is built into Kafka, so the kafka.security.authorizer.AclAuthorizer was used in an existing ZooKeeper based cluster and migration to KRaft happened, then org.apache.kafka.metadata.authorizer.StandardAuthorizer is used after migration. This transition is done in the background by the Strimzi Cluster Operator, you are not required to make manual configuration changes.

To enable simple authorization, set the spec.kafka.authorization.type property to simple, and configure a list of super users. Super users are always allowed without querying Access Control List (ACL) rules. ACLs allow you to define which users have access to which resources at a granular level. Access rules can be specified for the KafkaUser.

#...
kind: Kafka
spec:
  kafka:
    authorization:
      type: simple
      superUsers:
        - CN=user-1
        - user-2
        - CN=user-3