pal-e-docs

Review: basketball-api default-deny NetworkPolicy

review-605-2026-03-28 Doc

review needs-refinement
Project

Verdict: NEEDS_REFINEMENT

Template Completeness

  • [x] Type — Feature
  • [x] Lineage — discovered during review-595-2026-03-28
  • [x] Repo — forgejo_admin/pal-e-platform (but WRONG — see Repo Placement)
  • [x] User Story — clear who/what/why
  • [x] Context — sufficient background
  • [x] File Targets — specific path given (but WRONG target — see File Targets)
  • [x] Acceptance Criteria — 4 testable criteria
  • [x] Test Expectations — commands provided (but wrong tool — tofu vs kustomize)
  • [x] Constraints — present
  • [x] Checklist — present
  • [x] Related — links to parent project and target repo
All template sections present. Content accuracy is the problem, not structure.

Traceability

  • [x] story:safety — security posture for basketball-api namespace
  • [x] arch:A4 — infrastructure/platform component
  • [x] Forgejo issue — forgejo_admin/westside-ai-assistant#9, open
Traceability triangle is complete.

File Targets

  • [ ] terraform/network-policies.tf — ISSUE: Wrong layer. This file manages NetworkPolicies for platform namespaces only (monitoring, forgejo, woodpecker, harbor, minio, keycloak, postgres, ollama, cnpg-system). All reference module.*.namespace outputs from terraform modules. basketball-api is an application namespace managed by pal-e-deployments via kustomize/ArgoCD — it has no terraform module in pal-e-platform.
Correct file targets should be in pal-e-deployments:
  • bases/standard/kustomization.yaml — uncomment networkpolicy.yaml resource (line 8)
  • overlays/basketball-api/prod/kustomization.yaml — uncomment NetworkPolicy patch (lines 54-72) and add westside-ai-assistant namespace to allowlist

Repo Placement

MISMATCH. The issue targets forgejo_admin/pal-e-platform but the correct repo is forgejo_admin/pal-e-deployments. Evidence:
  • pal-e-deployments/bases/standard/networkpolicy.yaml — a standard NetworkPolicy base already exists (default-deny ingress, allows tailscale + monitoring)
  • pal-e-deployments/overlays/basketball-api/prod/kustomization.yaml lines 54-72 — a commented-out NetworkPolicy overlay patch already exists for basketball-api, including a westsidekingsandqueens allowlist entry
  • pal-e-deployments/bases/standard/kustomization.yaml lines 7-8 — the networkpolicy.yaml resource is commented out globally: "TEMPORARY: disabled due to kube-router ipset bug (Forgejo #24)"
  • ALL 8 application overlays (basketball-api, pal-e-docs, pal-e-app, westsidekingsandqueens, mcd-tracker, mcd-tracker-app, platform-validation, gcal-scheduler) have their NetworkPolicy patches commented out for the same reason

Dependencies

  • [ ] kube-router ipset bug (Forgejo #24) — BLOCKER. ALL application NetworkPolicies are disabled due to this bug. This ticket cannot proceed until #24 is resolved. The fix already exists in pal-e-deployments but is commented out.
  • [x] Board item #595 (NetworkPolicy update in pal-e-platform, issue #3) — related but separate. That ticket correctly targets only the keycloak NetworkPolicy allowlist in pal-e-platform. Issue #3 explicitly notes: "Do NOT create a basketball-api NetworkPolicy (that's separate discovered scope)."

Acceptance Criteria

Criteria are reasonable in intent but wrong in implementation details:
  • "basketball-api namespace has default-deny ingress NetworkPolicy" — correct goal, wrong location
  • "Allowlist includes: westsidekingsandqueens, westside-ai-assistant, monitoring, tailscale" — tailscale and monitoring are already in the base template. The overlay only needs to ADD westsidekingsandqueens and westside-ai-assistant.
  • "tofu plan -lock=false shows only basketball-api NetworkPolicy addition" — wrong tool. Should be kustomize build overlays/basketball-api/prod validation
  • "Existing services (westside-app) still reach basketball-api after apply" — good criterion but untestable until kube-router bug is fixed
AC are not testable in their current form because they assume the wrong tool and location.

Blast Radius

  • If the kube-router ipset bug is fixed, uncommenting bases/standard/kustomization.yaml would enable NetworkPolicies for ALL 8 application namespaces, not just basketball-api. This is a platform-wide change.
  • Enabling just basketball-api while others remain open would require a per-overlay approach (uncomment only basketball-api overlay patches while keeping the base commented out), which is inconsistent.
  • Rollback is straightforward: re-comment the lines or revert the commit.

Decomposition Assessment

If re-scoped correctly (pal-e-deployments, uncomment existing code), this is a small change — 1-2 files, ~15 lines uncommented, plus adding westside-ai-assistant to the allowlist. Fits within the five-minute rule. No decomposition needed for basketball-api alone.
However, the kube-router blocker and the platform-wide implications suggest this should be part of a larger "enable all application NetworkPolicies" effort after Forgejo #24 is resolved. That larger effort would need decomposition (8 overlays, each needing their own allowlists reviewed).
  • Discrete changes: 2 (uncomment base + uncomment/update overlay) — under three-thing limit
  • Agent time: <5 minutes if kube-router bug is resolved — fits five-minute rule
  • No independent subtasks to parallelize

Recommendation

  • [BODY] Change target repo from forgejo_admin/pal-e-platform to forgejo_admin/pal-e-deployments
  • [BODY] Replace file target terraform/network-policies.tf with: (1) bases/standard/kustomization.yaml — uncomment networkpolicy.yaml resource, (2) overlays/basketball-api/prod/kustomization.yaml — uncomment NetworkPolicy patch and add westside-ai-assistant namespace to allowlist
  • [BODY] Replace test expectations: tofu commands should be kustomize build overlays/basketball-api/prod plus kubectl diff validation
  • [SCOPE] Kube-router ipset bug (Forgejo #24) is a blocker. This ticket is not actionable until that bug is resolved. Should this ticket be deferred, or should resolving the kube-router bug be scoped first?
  • [SCOPE] Enabling basketball-api NetworkPolicy alone while 7 other apps remain open is inconsistent. Should this be re-scoped as "enable all application NetworkPolicies" after the kube-router fix, or is per-app enablement acceptable?