The server NetworkPolicy does not select the migration Job pod, so the hook has no egress in a default-deny namespace

[tada5hi]

Found while auditing PR #20. Pre-existing on master.

Problem

templates/server/networkpolicy.yaml selects pods with authup.matchLabels ... component=server. The migration Job's pod template is labelled component=migration (templates/server/migration-job.yaml).

So with server.networkPolicy.enabled=true and allowExternalEgress=false, the server Deployment gets an explicit DNS + in-release egress allowance and the pre-upgrade hook pod gets none. In a namespace with a default-deny policy, which is the only environment where enabling the chart's NetworkPolicy means anything, the hook cannot resolve or reach the database and hangs until helm's timeout.

Why it is awkward

A migration-scoped NetworkPolicy would itself have to be a hook resource at a negative weight, so that it exists when the hook pod runs. That is the same shape as the hook-scoped ConfigMap added in #20.

Suggested fix

Either widen the existing policy's podSelector to cover component=migration (simplest, but then the policy object still has to exist before the hook: it does on any upgrade after the first, which may be good enough given the Job is pre-upgrade only), or render a second, hook-annotated NetworkPolicy at helm.sh/hook-weight: "-5" alongside the migration ConfigMap.

If neither is worth it, values.yaml and NOTES should say that server.networkPolicy does not cover the migration Job.

Test for it

helm template t charts/authup --set server.migration.enabled=true --set server.networkPolicy.enabled=true --set server.networkPolicy.allowExternalEgress=false and compare the policy's podSelector against the Job pod's labels.