From 171c8c96aa9f5c7c82b76bf381801cc33d445784 Mon Sep 17 00:00:00 2001 From: Brad Rodgers Date: Tue, 22 Sep 2026 15:57:09 -0400 Subject: [PATCH] k8s: add LAN-only staging host bcs.int.7tl-homelab.com with TLS There was no way to view the rebuild in a browser: the ingress answered only on websecure for the production hostnames, which have no cert and still belong to the live WordPress site. Review meant a port-forward. Add bcs.int.7tl-homelab.com as a staging route. The *.int zone resolves to the internal traefik LB (10.66.15.30) and is not reachable from the internet, so this exposes nothing publicly and leaves the real domain untouched. It follows the same pattern as the existing argocd/lidarr/tautulli ingresses. Enable cert-manager on the ingress, but scope the tls block to the staging host only. The production hostnames stay out of it deliberately: requesting a cert for names the live site still serves is a cutover step, not a prerequisite. Fix the issuer name while here. The commented-out placeholder said "letsencrypt-production"; the ClusterIssuer is actually "letsencrypt-prod", so the old hint would have silently failed to issue. Note for cutover: letsencrypt-prod solves via DNS-01 against Cloudflare, so the production cert can be issued before DNS moves, avoiding the HTTP-01 ordering problem. Conditional on bluecapstrategies.com being reachable by the cert-manager Cloudflare token, which is not yet verified. --- k8s/ingress.yaml | 41 +++++++++++++++++++++++++++++++++-------- 1 file changed, 33 insertions(+), 8 deletions(-) diff --git a/k8s/ingress.yaml b/k8s/ingress.yaml index 44bb9f1..3e5e296 100644 --- a/k8s/ingress.yaml +++ b/k8s/ingress.yaml @@ -1,3 +1,20 @@ +# Two audiences, deliberately separated: +# +# 1. bcs.int.7tl-homelab.com — STAGING. LAN-only (*.int resolves to the internal traefik LB at +# 10.66.15.30) with a real Let's Encrypt cert. This is how the rebuild is reviewed before +# launch. Safe: it is not reachable from the internet and does not touch the real domain. +# +# 2. www.bluecapstrategies.com / bluecapstrategies.com — PRODUCTION. Listed as routes so the +# cluster is ready, but deliberately NOT in the tls block yet: the live WordPress site still +# serves these names and must keep doing so until cutover. Requesting a cert for them is a +# launch step, not a prerequisite. +# +# TLS: ClusterIssuer is `letsencrypt-prod` (NOTE: not "letsencrypt-production" — an earlier comment +# here had the name wrong). It solves via DNS-01 against Cloudflare, which means a cert can be +# issued BEFORE any DNS points at this cluster. At cutover, add the two production hosts to the +# tls block and let the cert issue first, then move DNS — no insecure window, no HTTP-01 +# chicken-and-egg. That requires bluecapstrategies.com to be in the Cloudflare account the +# cert-manager API token can reach; verify that before relying on it. apiVersion: networking.k8s.io/v1 kind: Ingress metadata: @@ -5,16 +22,24 @@ metadata: namespace: bluecap-strategies annotations: traefik.ingress.kubernetes.io/router.entrypoints: websecure - # If cert-manager is installed, uncomment and set your ClusterIssuer. - # cert-manager.io/cluster-issuer: letsencrypt-production + cert-manager.io/cluster-issuer: letsencrypt-prod spec: - # If cert-manager is installed, uncomment tls and set the secret name. - # tls: - # - hosts: - # - www.bluecapstrategies.com - # - bluecapstrategies.com - # secretName: bluecap-website-tls + tls: + # Staging only, for now. Production hosts join this list at cutover (see header). + - hosts: + - bcs.int.7tl-homelab.com + secretName: bcs-int-tls rules: + - host: bcs.int.7tl-homelab.com + http: + paths: + - path: / + pathType: Prefix + backend: + service: + name: bluecap-website + port: + name: http - host: www.bluecapstrategies.com http: paths: