Strimzi vulnerabilities

Strimzi provides a way to run an Apache Kafka cluster on Kubernetes or OpenShift in various deployment configurations. In Strimzi 1.0.0 and earlier, deploying only the Topic Operator or only the User Operator through the Kafka custom resource leaves the Entity Operator ServiceAccount with RBAC permissions for both components. The excess permissions can allow access to KafkaUser custom resources and Secrets when the User Operator is absent, or access to KafkaTopic custom resources when the Topic Operator is absent.

In Strimzi 1.0.0 and earlier, an attacker who can create a Kafka custom resource can set Kafka.spec.entityOperator watchedNamespace to a target namespace, causing the Cluster Operator to create a Role with full Secret CRUD permissions there and bind it to the Entity Operator ServiceAccount in the attacker's namespace. The attacker can mint a token for that ServiceAccount and read or write Secrets in any target namespace where the Cluster Operator has been granted permissions, regardless of STRIMZI_NAMESPACE. Fixed in versions 1.0.1 and 1.1.0.

Incorrect access control in the Kafka Connect REST API in Strimzi Project 0.41.0 and earlier allows an attacker to perform DoS on Kafka Mirroring, potentially mirror topics' content to their own Kafka cluster (bypassing Kafka ACLs), and steal Kafka SASL credentials by querying the MirrorMaker Kafka REST API.

A vulnerability in Strimzi versions 0.49.0 through 0.50.0 involves incorrect configuration of trusted certificates for mTLS authentication when using a custom CA with a multistage CA chain. This causes all CAs in the chain to be trusted, allowing users with certificates signed by any CA in the chain to authenticate.