Dataplane PODs have a ServiceAccountToken mounted

[hafe]

Describe the bug
Dataplane PODs (nginx) gets a ServiceAccountToken created and mounted into the POD. That should not be needed. It decreases the security posture and is considered a bad practice.

To Reproduce
Just deploy "getting started" and verify that a ServiceAccount is created for each Gateway and that "automountServiceAccountToken" is set to true for the PODs.

Expected behavior

• No ServiceAccount created
• automountServiceAccountToken set to false

Your environment

• NGF 2.2.1
• kind
• Kubernetes 1.34

Additional context

• Security scanners will detect and report this

[nginx-bot]

Hi @hafe! Welcome to the project! 🎉

Thanks for opening this issue!
Be sure to check out our Contributing Guidelines and the Issue Lifecycle while you wait for someone on the team to take a look at this.

[sjberman]

Hi @hafe, the token is necessary because the NGINX data plane presents it when connecting to the control plane. The control plane uses the TokenReview API to verify the identity of all connecting data planes. The audience of the token is configured to be the name of the control plane, and is a bound token that is rotated regularly by the kubelet.

[hafe]

Ok so no API access from the dataplane?

[sjberman]

I'm actually remembering now that our init container that runs as part of the data plane deployment does currently access the k8s API. The NGINX container does not, but the k8s API token is in there because of this.

Though I believe this is only necessary if using NGINX Plus, so we should probably not mount that token for OSS users. We'll need to fix that.

[hafe]

Why does the init container need to access the API?

[sjberman]

Why does the init container need to access the API?

It's for gathering cluster ID information for NGINX Plus licensing reasons.

I'm going to close this issue in favor of #4344, which will address this.