pal-e-docs

Review: Keycloak realm config via Terraform provider

review-142-2026-03-28 Doc

review needs-refinement
Project

Verdict: NEEDS_REFINEMENT

Template Completeness

Checklist of required issue template fields:
  • [x] Type -- Feature
  • [x] Lineage -- plan-pal-e-platform, Platform Hardening, discovered scope from PR #130
  • [x] Repo -- forgejo_admin/pal-e-platform
  • [x] User Story -- platform operator wants declarative Keycloak realm config via tofu apply
  • [x] Context -- explains gap from PR #130 theme deployment, references mrparkers/keycloak provider
  • [x] File Targets -- terraform/main.tf, terraform/providers.tf
  • [x] Acceptance Criteria -- 3 criteria listed
  • [x] Test Expectations -- tofu plan command provided with -lock=false
  • [x] Constraints -- import safety, credential reuse, scope warning
  • [x] Checklist -- present, includes Phase 28 verification step
  • [x] Related -- project, PR #130, issue #140, board items #276/#277/#278
All template sections present. Well-structured issue. Notably, the issue includes a self-referential [SCOPE] section that flags potential redundancy with Phase 28 and instructs: "If Phase 28 covers everything, close this ticket as redundant."

Traceability

  • [x] story:WS-S3 -- Westside user story S3 (present on board item #270)
  • [x] arch:keycloak -- Keycloak architecture component (present on board item #270)
  • [x] Forgejo issue -- forgejo_admin/pal-e-platform#142, open
Traceability triangle is complete.

File Targets

  • [ ] terraform/main.tf -- ISSUE: File exists in pal-e-platform but is a module composition file. Keycloak deployment infra lives in terraform/modules/keycloak/main.tf (namespace, PVC, deployment, service, theme ConfigMap). Realm-level config (provider, realms, clients) already lives in pal-e-services/terraform/keycloak.tf -- the correct architectural home for service-level config.
  • [ ] terraform/providers.tf -- ISSUE: File exists with kubernetes, helm, tailscale, and minio providers. Adding the Keycloak provider here would duplicate what already exists in pal-e-services/terraform/versions.tf (mrparkers/keycloak ~> 5.0).
Both file targets point to the wrong repo. pal-e-platform owns Keycloak infrastructure (k8s deployment). pal-e-services owns Keycloak configuration (realms, clients, themes). This separation is correct and intentional.

Repo Placement

MISMATCH. The issue is filed on forgejo_admin/pal-e-platform, but the work it describes (Keycloak provider for realm/client management) was correctly implemented in forgejo_admin/pal-e-services by Phase 28. The pal-e-platform repo manages Keycloak via raw Kubernetes resources (namespace, deployment, service, ConfigMap). It should NOT have a Keycloak Admin API provider -- that responsibility belongs to pal-e-services, where it already exists.

Dependencies

  • [x] #276 Phase 28: Keycloak Declarative Onboarding -- DONE (parent phase that delivered this capability)
  • [x] #277 Import Keycloak realms/clients into Terraform -- DONE (the specific implementation ticket in pal-e-services)
  • [x] #278 Update service onboarding SOP with Keycloak docs -- DONE (documentation for the delivered feature)
  • [x] #280 Spike: validate Phase 28 Keycloak + secrets -- DONE (validation completed)
All four dependency items are DONE. The work this ticket describes has been fully delivered and validated in pal-e-services.

Acceptance Criteria

All three acceptance criteria are already satisfied by pal-e-services:
  • "tofu apply sets realm login themes (no manual API calls)" -- SATISFIED. pal-e-services/terraform/k3s.tfvars declares login_theme = "westside" for westside-basketball realm. Applied via keycloak_realm.this in pal-e-services/terraform/keycloak.tf.
  • "Existing realms imported without drift" -- SATISFIED. westside-basketball and mcd-tracker realms are managed. Spike #280 validated clean state.
  • "Client configurations for westside-app and other OIDC clients managed in Terraform" -- SATISFIED. Four clients managed: westside-app, westside-spa, mcd-tracker-app, mcd-tracker-ios. Plus protocol mappers, roles, SMTP config, and brute force detection.
Since all AC are met, no agent work is needed.

Blast Radius

No implementation blast radius -- the ticket should not be implemented. If it were implemented as written, it would create duplicate Keycloak provider management across two repos (pal-e-platform and pal-e-services), causing Terraform state conflicts and violating the platform/services separation. Closing as redundant has zero blast radius.

Decomposition Assessment

Not applicable. The ticket should be closed as redundant, not decomposed. For completeness:
  • File targets: 2 files, 1 repo -- within limits, but targets are wrong
  • Acceptance criteria: 3 -- within limits, but all already satisfied
  • Estimated agent work: 0 minutes -- no work to do
  • No independent subtasks to parallelize
No decomposition needed.

Recommendation

  • [SCOPE] Close Forgejo issue #142 as redundant. Phase 28 (board items #276, #277, #278) delivered all three acceptance criteria in pal-e-services. The ticket's own [SCOPE] section anticipated this outcome: "If Phase 28 covers everything, close this ticket as redundant."
  • [LABEL] Remove board item #270 from board-pal-e-platform (or move to done with a "redundant" note).