[Enhancement]: Add Support for Configuring automountServiceAccountToken

[germanattanasio]

Related problem

Currently, it is not possible to set automountServiceAccountToken: false for Kafka and Zookeeper pods or their associated service accounts in Strimzi. This limitation is a blocker for environments with strict security policies, such as those on Azure or other secured clusters, where automounting service account tokens is not permitted by default.
Enforcing automountServiceAccountToken: false is a common security requirement in certain managed environments (e.g., Azure). Other frameworks and tools such as Snyk or ARMO have recently added this vulnerability. Finally existing tools like Cert-manager, Linkerd, and Kubernetes Ingress, allow you to set the value to false and use volume-based configurations for accessing service account tokens.

Here is the picture with the warning for the running pods with automount as true.

Suggested solution

1. Set the automountServiceAccountToken to false for those pods that don't need access to Kubernetes API. This is backward compatible and easy to do.
2. Allow users to define volume and volumeMount along with automountServiceAccountToken in the CRD or automatically add the volumes if the CRD has the flag as false.

Alternatives

No response

Additional context

Relevant References

• Cert-manager: Restrict Auto-mount of Service Account Tokens
• Linkerd Issue #4651
• Kubernetes Ingress-nginx Issue #9735
• Trust-manager implementation: PR #513
• https://github.com/orgs/strimzi/discussions/4866

[scholzj]

TBH, I'm not sure I follow the motivation. The token is in many cases needed so why should it be mounted separately in a complicated way? The idea to let the users do it just means that there will be a huge support load on us with people who are able to disable some flag but are unable to configure it properly. So I think the first point is relatively feasible, but will affect only few pods. The second point is IMHO not realistic. If you want to use some tooling to check on these things, you need to be able to configure it to know where it is ok and where it is not.

[germanattanasio]

If we do (1) and disable it where it’s not needed, we would at least move closer to the principle of least privilege. Using volumes instead of the automatic service account could come later.

Which pods actually need access to the Kube API? I imagine the main operator needs the token. Do Kafka or Zookeeper containers need it?

[scholzj]

ZooKeeper is already gone. So pretty much the Kafka Exporter and I guess Cruise Control. Kafka needs it for rack awareness or node port access.

[im-konge]

Triaged on 9.1.2025: Based on the discussion during the community call, @ShubhamRwt is currently working on proposal for the self-healing feature with CC and one of the components will need the access token for its operations. So we can end up with just Kafka Exporter needing this kind of option. Anyway, this needs a proposal - @germanattanasio are you interested in writing the proposal and working on the implementation?