potiuk opened a new pull request, #72209:
URL: https://github.com/apache/airflow/pull/72209
The chart ran a create-user job on every install and provisioned a FAB
account with a username and password that were the same on every installation:
```yaml
createUserJob:
enabled: true
defaultUser:
role: Admin
username: admin
password: admin
```
Anything able to reach the API server could sign in with the Admin role.
That is not narrow by default: `networkPolicies.enabled` is `false`, so every
workload in the cluster can reach the service, and the documented ingress path
widens it further.
## What changed
`createUserJob` is now **disabled by default**, and the chart ships **no
default username or password**.
Enabling the job without setting both fails the render, naming the two
values and the alternative, rather than falling back to an account whose
credentials are public knowledge:
```
createUserJob.enabled is true but createUserJob.defaultUser.username and/or
createUserJob.defaultUser.password are not set. Set both to credentials of
your own,
or leave createUserJob.enabled false and create the user yourself with
`airflow users create`.
```
Generating a random password instead was considered and rejected: it keeps a
default account in existence and only makes its credential harder to guess. Not
creating the account removes the class of problem, and matches how the chart
already treats other opt-in components.
`NOTES.txt` no longer prints the password after install. It prints the
username when the job ran, and the `airflow users create` invocation when it
did not — advertising the credential was part of the same problem.
## Behaviour
| Invocation | Result |
|---|---|
| default | renders; no user created |
| `--set createUserJob.enabled=true` | fails, with the message above |
| `enabled=true` + password only | fails |
| `enabled=true` + username and password | renders |
`helm lint` clean; Celery, Kubernetes and Local executors all render.
## Tests
Tests covering the job opt in the way a deployment would. The job's own test
module renders through a wrapper that supplies `admin`/`admin` and lets each
test's own values win over it, so the opt-in is stated once and is
self-explanatory. The other four affected files carry the credentials inside
their existing `createUserJob` values.
Worth noting for review: adding a *second* `"createUserJob"` key to those
dicts is not equivalent — Python keeps the last one, which silently discards
the test's own `serviceAccount` setup and leaves the test passing while no
longer testing what it was written to test. The credentials are merged into the
existing keys for that reason.
## Docs
- `production-guide.rst` gains a *Creating the first user* section covering
both routes, and recommends supplying the password from a Kubernetes Secret
rather than `values.yaml`, since values files are frequently committed.
- A `significant` newsfragment records the behaviour change and the
migration path.
- `values.schema.json` default for `enabled` corrected to `false`.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
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]
