Strimzi vulnerabilities

A Kubernetes tenant with create permission on Console custom resources can set spec.containers.api.spec.image to an arbitrary container image. The operator deploys this image into a pod whose ServiceAccount is bound via ClusterRoleBinding to a ClusterRole granting cluster-wide get/list/watch on all Strimzi CRDs (including KafkaUsers), patch on Kafkas/KafkaRebalances, and cluster-monitoring-view. The attacker's code reads the projected SA token and gains cross-tenant Strimzi control-plane read+write access.

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.

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.

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.