Attack Chain

1. Attacker identifies a Kubernetes namespace where they possess 'create' permissions on Console custom resources.
2. Attacker crafts a malicious Console custom resource definition containing a crafted 'spec.containers.api.spec.image' value pointing to an attacker-controlled container image.
3. Attacker submits the malicious Console custom resource to the Kubernetes API server.
4. The Strimzi operator reconciles the malicious resource and pulls the attacker-controlled image.
5. The Strimzi operator deploys the malicious image into a pod context managed by the operator.
6. The pod initializes with a ServiceAccount bound via ClusterRoleBinding to a high-privilege Strimzi ClusterRole.
7. Attacker executes code within the running container to access the projected ServiceAccount token located in the filesystem.
8. Attacker uses the stolen ServiceAccount token to perform unauthorized cross-tenant operations, such as modifying KafkaUsers or Kafka resources.

Impact

Successful exploitation allows a low-privileged tenant to gain elevated, cluster-wide control over Strimzi Kafka deployments. This results in unauthorized access to sensitive Kafka data, the ability to modify or delete Kafka users and cluster configurations, and potential disruption to cross-tenant messaging services.

Recommendation

1. Audit Kubernetes RBAC policies to restrict 'create' permissions on Console custom resources to trusted administrative principals only.
2. Implement admission controllers to validate image registry sources for pods created by operators, ensuring only authorized container images are deployed.
3. Review existing ClusterRoleBindings associated with Strimzi ServiceAccounts to ensure they adhere to the principle of least privilege.
4. Upgrade to the latest patched version of the Strimzi operator as provided by the vendor.