[Bug]: Missing RoleBinding for ServiceAccount for KafkaConnect custom resource with ApiVersion v1

[n-badtke-cg]

Bug Description

Hi,

I updated the Strimzi Helm Chart from 0.49.0 to 0.49.1, with that came the update to CRD API version v1. I am not seeing the RoleBinding for the automatically created ServiceAccount for a KafkaConnect resource anymore. In my case, I am using a KafkaConnector that references a Kubernetes Secret in the namespace of the KafkaConnect Pod. After the update, the KafkaConnect pods is unable to retrieve the Secret content due to missing permissions.

After some more research, I assume, that this is related to GHSA-xrhh-hx36-485q which got addressed with 0.49.1. Am I wrong?

Steps to reproduce

1. install Strimzi Helm Chart with version 0.49.1 with watchNamespace on a different namespace
2. create a KafkaConnect custom resource in a watched namespace with:

   spec:
     config:
       config.providers: secrets
       config.providers.secrets.class: io.strimzi.kafka.KubernetesSecretConfigProvider

3. look for the new ServiceAccount in the watched namespace
4. look for the missing role and rolebinding in the watched namespace

Expected behavior

with v0.49.0, Role and Rolebinding did exist with

rules:
  - apiGroups:
      - ""
    resources:
      - secrets
    verbs:
      - get

Strimzi version

0.49.1

Kubernetes version

1.32.4

Installation method

Helm Chart

Infrastructure

Azure AKS (should be irrelevant)

Configuration files and logs

Strimzi Helm Chart values:

  values:
    watchNamespaces:
      - kafka-connect-system

KafkaConnect Resource:

apiVersion: kafka.strimzi.io/v1
kind: KafkaConnect
metadata:
  annotations:
    strimzi.io/use-connector-resources: "true"
  name: connect-cluster
  namespace: kafka-connect-system
spec:
  authentication:
    passwordSecret:
      password: connection-string
      secretName: bootstrap-server-secret
    type: plain
    username: $ConnectionString
  bootstrapServers: [REDACTED]
  groupId: connect-cluster-group
  configStorageTopic: connect-cluster-configs
  offsetStorageTopic: connect-cluster-offsets
  statusStorageTopic: connect-cluster-status
  config:
    config.providers: secrets
    config.providers.secrets.class: io.strimzi.kafka.KubernetesSecretConfigProvider
    config.storage.replication.factor: 1
    key.converter: org.apache.kafka.connect.json.JsonConverter
    key.converter.schemas.enable: true
    offset.flush.interval.ms: 10000
    offset.storage.replication.factor: 1
    status.storage.replication.factor: 1
    value.converter: org.apache.kafka.connect.json.JsonConverter
    value.converter.schemas.enable: true
  replicas: 1
  tls:
    trustedCertificates: []
  version: 4.0.0

Additional context

https://strimzi.io/docs/operators/0.49.1/deploying#assembly-loading-config-with-providers-str

[scholzj]

Converting to discussion as this is not really a bug.

---

In general, you are right, you issue seems to be related to the CVE that was fixed in Strimzi 0.49.1. The CVE issue was causing an incorrect Role/RoleBinding to be created whcih gave the Pod access to all Secrets in a namespace. That was a security issue as this access can be easily missused and it was never intended to have such access automatically granted.

If you want to use the KubernetesSecretConfigProvider for some configuration in Connect or Connector, you can do it. But you have to create your own Role/RoleBinding with the required permissions together with it. You can see an example here: https://github.com/strimzi/kafka-kubernetes-config-provider?tab=readme-ov-file#using-it-with-strimzi (you just need to change it from ConfigMap to Secret and use the right names).

[n-badtke-cg]

Thank you for the important information, that clears things up.

you have to create your own Role/RoleBinding with the required permissions together with it.

We already deployed this (create custom Role/RoleBinding) as a workaround - which seems to be the official solution then :D that means we solved the issue then already, thank you :)