martin-mat opened a new issue, #1025: URL: https://github.com/apache/apisix-helm-chart/issues/1025
### What happens With default values, the APISIX pods run as the namespace's `default` ServiceAccount: `serviceAccount.create` is `false`, and `apisix.serviceAccountName` then falls back to `default`. The other two charts in this repository don't do that: `apisix-dashboard` creates its own account by default (`serviceAccount.create: true`), and `apisix-ingress-controller` always does. ### Why it matters - **Isolation.** Whatever is granted to `default` in the namespace, by the user or by another chart installed there, applies to the gateway too, and the gateway is the component that faces untrusted traffic. The CIS Kubernetes Benchmark (5.1.5) and the Kubernetes documentation recommend not running workloads as the `default` ServiceAccount. - **Attribution.** In the API server's audit log the gateway appears as its own identity, not as "default in this namespace". - **Consistency.** The same behaviour as the dashboard and ingress-controller charts, and as the chart `helm create` generates. ### Proposal Default `serviceAccount.create` to `true`. - The chart then creates `<fullname>` and the Deployment uses it. The templates already support this (#278); only the default changes. - `rbac.create` stays `false`, so the new account has no permissions at all. Kubernetes service discovery still needs `rbac.create: true`, exactly as today, and users who enable it already set `serviceAccount.create: true` with it (as in #539). - `serviceAccount.create: false` keeps the current behaviour; `serviceAccount.name` still selects an existing account. **Upgrade note.** A user who enabled Kubernetes service discovery but granted `endpoints` access to the namespace's `default` account by hand, instead of through `rbac.create`, would lose that access on upgrade, because the pods move to the new account. Setting `serviceAccount.create: false` keeps their setup. This is worth a line in the release notes. ### Tried on a fork Chart at master and with `serviceAccount.create: true`, installed in standalone mode on kind, CNTi test suite v2.3.0 ([run](https://github.com/martin-mat/apisix-helm-chart/actions/runs/39148581504)): | | master | `serviceAccount.create: true` | |---|---|---| | APISIX pod's ServiceAccount | `default` | `apisix` (its own, no permissions) | | `dedicated_service_account` | failed | passed | | CNTi essential tests | 15 of 19 | 15 of 19 | | A request through the gateway | `404 Route Not Found` from APISIX | `404 Route Not Found` from APISIX | `helm lint`, `ct lint`, `ct install` and the helm-docs check pass on the change ([this repository's CI on the fork](https://github.com/martin-mat/apisix-helm-chart/actions/runs/39148581193), Kubernetes 1.22 and 1.23), and the chart renders as expected with `serviceAccount.create: false` (pods on `default`) and with `serviceAccount.name` (the named account). This came up while running the CNTi test suite against the chart for #1024. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
