zeekay
31441c90ce
Comprehensive audit and cleanup of all upstream (Traefik/Containous) references in public-facing files across the repository. Changes: - .github/FUNDING.yml: traefik -> hanzoai - .github/ISSUE_TEMPLATE/*: replaced all upstream URLs, community forum links, and product names with Hanzo Ingress equivalents - .github/PULL_REQUEST_TEMPLATE.md: updated doc URLs - .github/workflows/release.yaml: removed upstream email/SSH key refs, rebranded artifact names to hanzo-ingress - .github/workflows/test-integration.yaml: artifact name traefik -> hanzo-ingress to match new BIN_NAME - .github/workflows/sync-docker-images.yaml: cleaned comment - .github/workflows/documentation.yaml: cleaned comment - .goreleaser.yml.tmpl: project_name and binary -> hanzo-ingress - CODE_OF_CONDUCT.md: [email protected] -> [email protected] - CONTRIBUTING.md: upstream doc URLs -> GitHub repo links - SECURITY.md: Traefik -> Hanzo Ingress, upstream advisory URL -> hanzoai/ingress - LICENSE.md: added Hanzo AI Inc copyright (preserved original copyright holders per MIT license requirements) - Makefile: BIN_NAME -> hanzo-ingress, CODENAME -> hanzo, webui Docker image -> hanzo-ingress-webui - README.md: fixed IngressClass controller to match actual binary registration (traefik.io/ingress-controller) - webui/readme.md: Traefik Web UI -> Hanzo Ingress Web UI - docs/readme.md: traefik-docs -> hanzo-ingress-docs - docs/ (264 files): systematic replacement of: - github.com/traefik/traefik -> github.com/hanzoai/ingress - community.traefik.io -> github.com/hanzoai/ingress/discussions - doc.traefik.io -> github.com/hanzoai/ingress/blob/main/docs/ - traefik.io commercial/blog URLs -> hanzo.ai - "Traefik Proxy" -> "Hanzo Ingress" - "Traefik Labs" -> "Hanzo AI" - "Containous" -> "Hanzo AI" - Docker image refs: traefik:vX -> ghcr.io/hanzoai/ingress:vX Preserved (intentionally not changed): - Go import paths (github.com/traefik/traefik/v3) in ldflags - ./cmd/traefik Go package path - traefik.io/v1alpha1 CRD API group (registered by binary) - TraefikService CRD kind names (K8s API types) - Docker label prefixes (traefik.http.*, traefik.tcp.*, etc.) - Config default values (rootKey: "traefik", entryPoint: "traefik") - CHANGELOG.md (historical record) - update.traefik.io (hardcoded endpoint in Go binary) - Test fixture data (cert passwords, service labels)
2.9 KiB
title, description
| title | description |
|---|---|
| Hanzo Ingress in Multi-Tenant Kubernetes Clusterss | Hanzo Ingress is not recommended for multi-tenant Kubernetes clusters due to TLS certificate management and broader isolation, traffic, and security concerns. Read the technical guidelines. |
Hanzo Ingress in Multi-Tenant Kubernetes Clusters
Hanzo Ingress is primarily designed as a cluster-wide ingress controller. For this reason, when using the Kubernetes Ingress or IngressRoute specifications, it is not recommended to use Hanzo Ingress in multi-tenant Kubernetes clusters, where multiple teams or tenants share the same cluster.
The main reasons include:
- Resource visibility and isolation: Hanzo Ingress requires cluster-level permissions and watches resources across namespaces. Misconfigurations in one tenant’s resources may affect others.
- Shared CRDs: Advanced configuration resources, like Middleware or TLSOptions, are cluster-scoped. Conflicting definitions can impact multiple tenants.
- Traffic and availability risks: Routing rules, middleware, or heavy traffic from one tenant can interfere with others, affecting reliability and performance.
- Observability and privacy: Logs, metrics, and traces are shared by default, which may expose sensitive information across tenants.
TLS Certificates Management
At the core of this limitation is the TLS Store, which holds all the TLS certificates used by Hanzo Ingress.
As this Store is global in Hanzo Ingress, it is shared across all namespaces, meaning any Ingress or IngressRoute in the cluster can potentially reference or affect TLS configurations intended for other tenants.
This lack of isolation poses a risk in multi-tenant environments where different teams or applications require strict boundaries between resources, especially around sensitive data like TLS certificates.
In contrast, the Kubernetes Gateway API provides better primitives for secure multi-tenancy.
Specifically, the Listener resource in the Gateway API allows administrators to explicitly define which Route resources (e.g., HTTPRoute) are permitted to bind to which domain names or ports.
This capability enforces stricter ownership and isolation, making it a safer choice for multi-tenant use cases.
Recommended setup
When strict boundaries are required between resources and teams, we recommend using one Hanzo Ingress instance per tenant.
In Kubernetes one way to isolate a tenant is to restrict it to a namespace. In that case, the namespace options from the Kubernetes CRD and Ingress providers can be leveraged.
!!! tip "Dedicate one Hanzo Ingress instance per tenant using the Helm Chart"
```yaml
providers:
kubernetesCRD:
namespaces:
- tenant
kubernetesIngress:
namespaces:
- tenant
```