Exposing SecureAuth on Kubernetes

The SecureAuth Helm chart deploys SecureAuth as a Kubernetes Service. How that service is exposed to clients is your choice – the chart supports rendering an Ingress resource out of the box, and it works equally well behind a Gateway API HTTPRoute or any other gateway/proxy you operate.

This page documents both common approaches.

Approach	When to pick it
Option A – Helm-managed Ingress	You already operate an Ingress controller (such as ingress-nginx, traefik, istio, kong, an AWS ALB controller, etc.) and want the chart to produce the Ingress resource for you.
Option B – Gateway API HTTPRoute	You operate a Gateway API implementation (such as NGINX Gateway Fabric, Istio, Envoy Gateway, Contour, Cilium, etc.) and prefer to manage routing through Gateway + HTTPRoute.

note

Neither approach is required – SecureAuth's chart only depends on its application dependencies (database, cache, etc.). Networking is up to you. SecureAuth runs internally behind NGINX Gateway Fabric, but this is an implementation choice, not a requirement for the product.

Option A – Helm-managed Ingress

The SecureAuth Helm chart can render an Ingress resource that any conformant Ingress controller will satisfy. To enable it, set ingress.enabled=true.

In the most common scenario, one host name is mapped to the deployment:

• ingress.hosts – host names served by the Ingress.
• ingress.tls – TLS configuration for those host names.

acp:
  ingress:
    ## If true, the chart will create an Ingress resource for ACP.
    enabled: true

    ## Ingress host name(s) – required when enabled.
    hosts:
      - host: acp.example.com
        paths:
          - path: /
            pathType: ImplementationSpecific

Prerequisites

• Kubernetes cluster v1.16+

• An Ingress controller installed in the cluster (for example, ingress-nginx, traefik, kong, or one provided by your cloud)

• Helm v3.0+

Ingress TLS

Bring your own key/cert pair for the host(s) you protect.

• Create a TLS secret in the namespace.

  kubectl create secret tls acp-server-tls --cert=path/to/tls.cert --key=path/to/tls.key

  acp:
    ingress:
      enabled: true
      hosts:
        - host: acp.example.com
          paths:
            - path: /
              pathType: ImplementationSpecific
      tls:
        - secretName: acp-server-tls
          hosts:
            - acp.example.com

• Or include the cert directly in values:

  acp:
    ingress:
      enabled: true
      hosts:
        - host: acp.example.com
          paths:
            - path: /
              pathType: ImplementationSpecific
      tls:
        - secretName: acp-server-tls
          hosts:
            - acp.example.com
      tlsSecrets:
        - name: acp-server-tls
          cert: |
            -----BEGIN CERTIFICATE-----
            <certificate body>
            -----END CERTIFICATE-----
          key: |
            -----BEGIN RSA PRIVATE KEY-----
            <key body>
            -----END RSA PRIVATE KEY-----

Ingress TLS with cert-manager

If you run cert-manager (or an equivalent automatic certificate provider), annotate the Ingress to have it issued automatically:

acp:
  ingress:
    enabled: true
    annotations:
      cert-manager.io/cluster-issuer: letsencrypt-prod
    hosts:
      - host: acp.example.com
        paths:
          - path: /
            pathType: ImplementationSpecific
    tls:
      - secretName: acp-server-tls
        hosts:
          - acp.example.com

If your cluster cannot satisfy HTTP-01 challenges, use external-dns and a DNS-01 solver instead.

Ingress mTLS

A second Ingress can be configured to terminate mTLS to SecureAuth. Use this if your primary Ingress cannot forward client certificates. This is advanced functionality – only enable it if you need it.

Configuration is the same as the base Ingress, plus the serverURLMtls parameter.

serverURLMtls: https://mtls.acp.example.com:8443
ingressMtls:
  enabled: true
  hosts:
    - host: mtls.acp.example.com
      paths:
        - path: /
          pathType: ImplementationSpecific
  tls:
    - secretName: acp-server-mtls
      hosts:
        - mtls.acp.example.com

Option B – Gateway API HTTPRoute

If your cluster runs a Gateway API implementation, you can disable the chart's Ingress and route traffic to SecureAuth's Service via an HTTPRoute.

Prerequisites

• Kubernetes cluster v1.25+ (Gateway API v1 went GA in 2023)

• A Gateway API implementation installed in the cluster (for example, NGINX Gateway Fabric, Istio, Envoy Gateway, Contour, Cilium, Kong, Traefik, or your cloud provider's offering)

• Gateway API CRDs installed: kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.2.0/standard-install.yaml

• A Gateway resource with at least one listener for the host name(s) you want to expose

• Helm v3.0+

Disable chart-managed Ingress

acp:
  ingress:
    enabled: false

Create an HTTPRoute targeting the SecureAuth Service

Replace acp-gateway / nginx-gateway with your own Gateway name and namespace, and acp.example.com with your host.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: acp
  namespace: acp
spec:
  parentRefs:
    - name: acp-gateway
      namespace: nginx-gateway
  hostnames:
    - "acp.example.com"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: acp
          port: 8443

If your Gateway lives in a different namespace from the SecureAuth Service, also create a ReferenceGrant so the gateway is permitted to route there. See the Gateway API ReferenceGrant docs for the exact shape.

TLS

TLS is terminated at the Gateway listener, not at the HTTPRoute. Configure your listener with the desired certificate (cert-manager, manual Secret, or your gateway implementation's preferred mechanism). For example, with NGF and cert-manager:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: acp-gateway
  namespace: nginx-gateway
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
  gatewayClassName: nginx
  listeners:
    - name: https
      protocol: HTTPS
      port: 443
      hostname: "acp.example.com"
      tls:
        mode: Terminate
        certificateRefs:
          - kind: Secret
            name: acp-server-tls
      allowedRoutes:
        namespaces:
          from: All

mTLS

mTLS termination is gateway-implementation-specific. Consult your Gateway API implementation's docs (for example, NGF's ClientSettingsPolicy or Istio's PeerAuthentication). Once mTLS is terminated, route the resulting traffic to SecureAuth's mTLS port (8443 by default) the same way as any other HTTPRoute.