bluejay-infra/apps/fc-devicemgmt/ADMIN-CONSOLE-INFRA.md

Admin / Helpdesk Console — Infra Finding (Cl-5, ADR-204)

Outcome: ZERO new cluster infra required. The Admin/helpdesk console rides the existing FlowerCore.DeviceManagement.Web deploy as routes inside DM.Web (ADR-204). The ingress already in this directory covers every path the admin console serves.

What already exists for DM.Web (this directory)

Manifest	Resource	Notes
certificate-web.yaml	cert-manager Certificate fc-devicemgmt-web-tls	issuerRef → step-ca-acme ClusterIssuer; dnsNames: [devices.iamworkin.lan]; secretName: fc-devicemgmt-web-tls. DNS preflight gate documented (pfSense A record devices.iamworkin.lan → 10.0.56.200 required before ACME sync).
ingressroute-web.yaml	Traefik IngressRoute fc-devicemgmt-web	entryPoints: [websecure], match: Host(\devices.iamworkin.lan`), service fc-devicemgmt-web:80, tls.secretName: fc-devicemgmt-web-tls`.
service-web.yaml	Service fc-devicemgmt-web (ClusterIP, 80→8080)	Owned by the DM.Web deploy.
deployment-web.yaml	Deployment fc-devicemgmt-web	Currently replicas: 0 (gated on fc-mysql operator + flowercore_devicemgmt DB + 1Password runtime item — see header comment). Not a Cl-5 concern.
also present	operator RBAC, namespace, network-policy, 1password-item	Full app dir, ArgoCD-managed.

Why the admin console needs nothing new

The existing IngressRoute matches **Host(\devices.iamworkin.lan`)with noPathPrefixconstraint**. Traefik therefore forwards *all* paths on that host to thefc-devicemgmt-webservice — including any admin/helpdesk routes the DM.Web app exposes under itsFlowerCore:PathBase(e.g./admin, /helpdesk). The same TLS secret (fc-devicemgmt-web-tls) and the same step-ca ACME Certificate` already protect them.

This matches the established TLS-only-app pattern (e.g. apps/fc-library/fc-library.yaml, apps/fc-retail/fc-retail.yaml): Certificate (issuerRef step-ca-acme ClusterIssuer) + host-matched IngressRoute sharing the secretName. Per ADR-204 the admin console's Deployment/Service stay with the DM.Web deploy — no separate workload is created.

ArgoCD repo URL convention (for reference, not changed here): http://gitea-clusterip.gitea.svc.cluster.local:3000/bluejay/bluejay-infra.git (internal HTTP — step-ca cert isn't trusted by ArgoCD). Apps in apps/* are picked up by the bluejay-infra ApplicationSet directory generator; this dir has no kustomization.yaml, consistent with that pattern.

Recommendation

Ride DM.Web at a PathBase path → no new Certificate, no new IngressRoute, no new Deployment/Service. Close the lane. The admin console reaches users at https://devices.iamworkin.lan/<PathBase> through the manifests already in this directory.

Open question (operator decision — NOT actioned)

Q-MP-ADMIN-HOST — Distinct admin hostname vs PathBase path under DM.Web? If the operator ever wants the admin/helpdesk console on its own hostname (e.g. admin.iamworkin.lan) rather than a path under devices.iamworkin.lan, that is a deliberate routing/auth-surface choice, not a mechanical infra add. It would require:

1. a pfSense / FlowerCore.DNS A record admin.iamworkin.lan → 10.0.56.200 (ACME preflight gate — step-ca HTTP-01 can't see the CoreDNS wildcard);
2. a second cert-manager Certificate (step-ca-acme ClusterIssuer, dnsNames: [admin.iamworkin.lan], own secretName);
3. a second host-matched IngressRoute → the same fc-devicemgmt-web:80 service (still no new Deployment/Service — same app behind a second host).

Default taken (do not block): PathBase path under DM.Web = zero new infra. A separate admin hostname is left UNBUILT pending an explicit operator answer to Q-MP-ADMIN-HOST, because it changes the public/auth surface and conflicts with the ADR-204 "routes inside DM.Web" intent. If the answer is "separate host," author only the Certificate + IngressRoute above (no Deployment/Service), mirroring apps/fc-library/fc-library.yaml.

Verification

• kubectl apply --dry-run=client (kubectl v1.34.2, no live cluster): ingressroute-web.yaml, service-web.yaml, deployment-web.yaml validated clean. certificate-web.yaml returned "no matches for kind Certificate in cert-manager.io/v1" — expected with no cluster connection (CRD discovery unavailable client-side); the YAML shape is identical to the proven fc-library Certificate. Server-side dry-run + live host resolution = fix-forward (cluster may be unreachable from this lane).
• No manifest authored or changed by this lane — finding note only.