docs(gateway): child-tenant ACME is no longer a limitation

Remove the child-tenant ACME HTTP-01 entry from Known limitations in
the gateway README. With the per-tenant Issuer added in the previous
commit, each tenant that opts into gateway: true gets its own ACME
account, its own HTTPRoute solver targeting its own Gateway, and no
dependency on the publishing tenant's Gateway.

In its place, document the actual remaining constraint: the
per-tenant Issuer template currently supports two issuer names
(letsencrypt-prod, letsencrypt-stage) — any other value fails the
render with an actionable error. Supporting more ACME providers is
a one-case extension of templates/issuer.yaml, so operators know
exactly where to hook in.

Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Aleksei Sviridkin <f@lex.la>
This commit is contained in:
Aleksei Sviridkin 2026-04-23 20:13:03 +03:00
parent 49d896caca
commit 0f44e2af57
No known key found for this signature in database
GPG key ID: 7988329FDF395282

View file

@ -48,6 +48,6 @@ The default for a fresh tenant is unlimited; operators running shared-apex multi
## Known limitations
- **Child-tenant ACME HTTP-01** currently relies on the publishing tenant's Gateway; a child tenant that turns on `gateway: true` but still has its issuer pointed at `letsencrypt-prod` (HTTP-01) must either share the parent Gateway or switch to `dns01`. A proper fix is a namespace-scoped `Issuer` per tenant — tracked as a follow-up.
- **Upstream application gaps** — some chart-level features (harbor ACL integrations, bucket upstream limitations) remain on ingress-nginx workflows in upstream docs; cozystack tracks those separately as upstream PRs.
- **Supported ACME issuers**`publishing.certificates.issuerName` for Gateway-based tenants must be `letsencrypt-prod` or `letsencrypt-stage` (the chart maps those names to concrete ACME server URLs). To support another ACME provider, extend `templates/issuer.yaml` with an additional branch.