Skip to content

Ingress auth

Experimental: public ingress, identity data, and certificate issuance are operator-managed security work.

Ingress authentication uses Authelia forward-auth with LLDAP and is separate from console auth, which protects the console and management APIs.

A FleetApp route opts in with route.requireAuth: true; routes without that setting remain public by design.

Before enabling a public route:

  1. Confirm the cluster is ready and site edge matches the route:
    • route.mode: site needs a bound port_forward or reverse_proxy ingress.
    • route.mode: hub needs hubGateway on the site (or hub-managed path).
    • route.mode: none is out of scope unless the chart exposes its own ingress.
  2. Configure DNS for the application and authentication portal with your DNS provider.
  3. Enable and verify the authentication stack through the authenticated console or approved API client.
  4. Confirm unauthenticated requests are challenged and authorized users reach the intended application.
  5. Keep LDAP service access internal. Expose an administration UI only through a reviewed, restricted management path.

Never copy passwords from Kubernetes Secrets into commands, tickets, or documentation. TLS, ACME, DNS, NAT, firewall rules, and session-cookie behavior are deployment-specific. Validate the live route, certificate, redirect, and external network policy before treating an application as protected.

See fleet-edge and examples/site-profiles/.