[martin-mat]

Why is this pull request needed and what does it do?

With serviceAccount.create: false, the chart's default since its first version, the ClusterRole that lets CoreDNS list and watch pods, services, endpoints, endpointslices and namespaces cluster-wide is bound to the release namespace's default ServiceAccount. Every pod in that namespace that runs as default (kube-system in the documented install) can read those objects across the cluster through its mounted token. Details in #283.

This defaults serviceAccount.create to true:

• charts/coredns/values.yaml: serviceAccount.create: true, with a comment on what the ClusterRole is bound to.
• The templates already support it: the account is named after the release, and the Deployment and the ClusterRoleBinding use it. serviceAccount.create: false with serviceAccount.name still selects an existing account (e.g. kubeadm's coredns when adopting). The token stays mounted, since the kubernetes plugin needs it, and the autoscaler keeps its own account.
• charts/coredns/tests/serviceaccount_default_test.yaml: a new unit test suite for the defaults: the ServiceAccount is created, the ClusterRoleBinding's subject is that account and not default, the Deployment runs as it, and create: false without a name still falls back to default.
• README: the serviceAccount.create row.
• Chart 1.49.0, with a security changelog entry.

On upgrade, the Deployment rolls to the new account, and the binding's subject moves from default to it, so the namespace's default account loses the grant. A release whose generated name matches an existing account (e.g. coredns in kube-system on kubeadm) needs the README's adoption step, or an explicit serviceAccount.name.

Verified on a fork, on the current master:

Case	Run	Result
This repository's Lint and Test Charts on this commit	38961109155	all helm unittest suites pass, including the new one; ct lint and ct install pass
kubectl auth can-i list pods --all-namespaces as the namespace's default account, on kind	38961194213	master: yes (binding subject default). This change: no (subject coredns).
CNTi Test Suite dedicated_service_account	same	fails on master, passes with this change; the essential tests are unchanged at 17 of 19

These are fresh installs; the upgrade path from 1.48.2 was not run.

Which issues (if any) are related?

Closes #283.

Checklist:

• I have bumped the chart version according to versioning.
• I have updated the chart changelog with all the changes that come with this pull request according to changelog.
• Any new values are backwards compatible and/or have sensible default.
• I have signed off all my commits as required by DCO.

🤖 Generated with Claude Code

[hagaibarel]

Thanks for picking this up, definitely a welcomed change!