feat(security): enable mendys-prod NetworkPolicy + guard against FuzeInfra#501 recurring by izzywdev · Pull Request #552 · izzywdev/FuzeFront

izzywdev · 2026-08-04T12:14:29Z

📋 Description

Closes out #493 for real, and adds two guardrails against the class of bug that delayed it (FuzeInfra#501).

Background: #497 added securityService.networkPolicy (default ON) so mendys-prod could reach fuzefront-security in-cluster. Before it ever synced, #523 accidentally dropped its port/namespace keys (and flipped its enabled to false) in a large values.yaml restructuring, which also broke the pre-existing authentik.networkPolicy the same way — rendering port: 0, which the live API server rejects. That failed every Argo sync of the whole fuzefront Application for days (FuzeInfra#501), until #534 restored the values and hardened both templates with inline | default fallbacks. #534 deliberately left securityService.networkPolicy.enabled: false, since the policy had never actually been live — flipping it on was called out as a separate deploy-window decision. This PR is that decision.

Fixes #493

🔄 Type of Change

✨ New feature (non-breaking change which adds functionality)
🔧 Refactoring (CI gate + doc guideline; no functional app-code change)

🔧 Implementation Details

Changes Made

Infra/Helm changes:
- deploy/helm/fuzefront/values-prod.yaml — securityService.networkPolicy.enabled: true, mirroring the authentik.networkPolicy base-off/prod-on pattern already established for the sibling policy.
CI:
- .github/workflows/helm-validate.yml — new gate-networkpolicy-ports step. kubeconform validates that a NetworkPolicy port is shaped like an IntOrString, not that it's in range. A missing values.yaml default renders as port: 0, which type-checks fine and only fails at live API-server admission — exactly how FuzeInfra#501 shipped undetected (a | int cast silently coerced the missing value to 0, which is a syntactically valid integer). This step statically rejects any rendered NetworkPolicy port outside 1–65535, directly against the rendered manifest — no cluster required. Named ports (e.g. port: http) are valid and deliberately left unchecked.
Docs:
- CLAUDE.md — new "Helm values hygiene" section: don't cast around (| int, | default, …) a kubeconform failure — investigate why the value is undefined and restore it explicitly in values.yaml. Also flags that a "fix missing defaults" commit dominated by deletions is a restructuring and needs a rendered-manifest diff, not just a line diff; and that two PRs touching the same top-level values.yaml key concurrently is the highest-risk moment for this exact class of bug.

🧪 Testing

helm lint + helm template (both overlays) — clean.
kubeconform -ignore-missing-schemas against the full rendered manifest set (values.yaml + values-prod.yaml) — 43 valid, 0 errors.
Rendered security-networkpolicy.yaml with the flag on: all three ingress rules render port: 3002 correctly.
Manually validated the new gate-networkpolicy-ports script logic against three cases: (a) the current valid render — passes; (b) a synthetic NetworkPolicy with port: 0 — correctly fails; (c) a synthetic NetworkPolicy with a named port (port: http) — correctly passes (no false positive).
Deploy-window verify after this syncs: from a mendys-prod pod, curl -sv --max-time 5 http://fuzefront-security.fuzefront.svc.cluster.local:3002/api/v1/security/session should reach the service, and the existing Traefik + intra-fuzefront paths to fuzefront-security should still work.

Code Quality

Code follows the project's coding standards
Self-review of code completed

🔗 Related Issues and PRs

Closes NetworkPolicy: allow ingress from mendys-prod to fuzefront-security:3002 (datasets-service token verify) #493
Related to feat(security): allow mendys-prod ingress to fuzefront-security:3002 #497 (original policy), feat(consumer-registration): automated MFE self-registration token bootstrap #523 (regression), fix(chart): restore NetworkPolicy port/namespace values dropped by #523 (unblocks all prod deploys) #534 (outage fix), FuzeInfra#501 (incident)

📝 Additional Notes

Deployment Notes

Requires configuration changes (none needed beyond this PR — Argo syncs master automatically per this repo's GitOps model)

No FuzeInfra-side change needed.

Generated by Claude Code

…nst FuzeInfra#501 recurring Now that FuzeInfra#501 (authentik-server-ingress port:0 blocking every Argo sync) is fixed by #534, this completes #493: securityService.networkPolicy was never actually applied in prod because syncs were already failing when it landed. Flips it on in values-prod.yaml, mirroring the authentik policy's own base-off/prod-on pattern. Also adds the two guardrails discussed while diagnosing #501: - gate-networkpolicy-ports (helm-validate.yml): kubeconform validates that a NetworkPolicy port is shaped like an IntOrString, not that it's in range. A missing values.yaml default renders as `port: 0`, which type-checks fine and only fails at live API-server admission — exactly how #501 shipped undetected. This step statically rejects any rendered NetworkPolicy port outside 1-65535, no cluster required. - CLAUDE.md: a guideline against "fixing" a kubeconform failure by casting around it (`| int`, `| default`, etc.) instead of restoring the missing value — the specific anti-pattern that masked #501's root cause. Closes #493.

github-actions · 2026-08-04T12:14:58Z