Advisories for Maven/Io.strimzi/Strimzi package

When only the Topic or only the User operators are deployed as part of the Entity Operator in the Kafka custom resource, the RBAC rights are not following the principle of least-privilege and the Entity Operator ServiceAccount still has access rights corresponding to both operators. That might allow the ServiceAccount to access KafkaUser custom resources and Secrets when the User operator is not deployed and access KafkaTopic custom resources when …

Having the Topic and User operators to watch different namespaces than the one where the Kafka cluster is deployed, is a fully documented feature. When the watchedNamespace field is used within the Topic or User operator (as part of the Kafka.spec.entityOperator field), the Cluster Operator creates a Role granting full CRUD on Secrets into the specified namespace. It also creates a RoleBinding to bind such Role to the entity operator …

In some situations, Strimzi creates an incorrect Kubernetes Role which grants the Apache Kafka Connect and Apache Kafka MirrorMaker 2 operands the GET access to all Kubernetes Secrets that exist in the given Kubernetes namespace. The exact scenario when this happens is when: Apache Kafka Connect is deployed without at least one of the following options configured: TLS encryption with configured trusted certificates (no .spec.tls.trustedCertificates section in the KafkaConnect CR) …

Incorrect access control in the Kafka Connect REST API in the STRIMZI Project 0.41.0 and earlier allows an attacker to deny the service for Kafka Mirroring, potentially mirror the topics' content to his Kafka cluster via a malicious connector (bypassing Kafka ACL if it exists), and potentially steal Kafka SASL credentials, by querying the MirrorMaker Kafka REST API.