Do not create a default Airflow user in the chart

[potiuk]

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:

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