Admin protection

Ory Talos exposes its admin surface (/v2alpha1/admin/*) without any built-in authentication or authorization. Place the admin server behind a trusted proxy or network boundary that authenticates and authorizes every request before it reaches Ory Talos.

Pick one of the deployment patterns below before sending admin traffic to an Ory Talos instance.

warning

Never expose talos serve admin directly to the public internet. Any request that reaches the admin endpoints is treated as authorized.

Why Ory Talos has no built-in admin authentication

Ory Talos composes with the identity, access, and gateway tooling you already run. Embedding an authentication layer would force every operator to either:

• Adopt Ory Talos's choice of identity provider, token format, and policy engine.
• Bypass the embedded layer with another proxy in front, doubling the attack surface.

Instead, Ory Talos accepts a hard contract: the admin server trusts every incoming request. You enforce identity and policy in the layer you already operate.

Deployment patterns

Ory Network

Place Ory Talos behind an Ory Network deployment configured with API token policies or session-based authorization for the admin paths. The Ory Network gateway authenticates and authorizes the caller, then forwards only allowed requests. No extra infrastructure required.

Reverse proxy with mTLS

Run a reverse proxy (Envoy, NGINX, HAProxy, Caddy) in front of talos serve admin and require client certificates from every caller.

• Issue a private CA-signed client certificate to each operator and CI/CD identity that needs admin access.
• Terminate TLS and validate the client certificate at the proxy.
• Reject any request that does not present a valid certificate.

This pattern works well for internal-only admin access where every caller is known and certificate distribution is automated.

Cloud API gateway

Use a managed API gateway (AWS API Gateway, Google Cloud API Gateway, or Azure API Management) configured with an authorizer (IAM, OIDC, or JWT) on the admin route prefix. Run Ory Talos in a private subnet so the gateway is the only public ingress.

• Configure the authorizer for /v2alpha1/admin/* to require a valid IAM principal, OIDC token, or signed JWT.
• Restrict the gateway-to-Ory Talos network path to a private interface (VPC link, private service connect, or equivalent).

Internal-only network

When Ory Talos serves only internal traffic, network controls alone can be enough:

• Bind talos serve admin to a private interface (no public listener).
• Restrict the network path with security groups, firewall rules, or a service mesh policy so only known internal services reach the admin port.
• Pair this with an internal authenticating proxy if internal traffic itself is not implicitly trusted.

Kubernetes with the Helm chart

The talos-oel Helm chart can render a deny-by-default NetworkPolicy set for the release. The set is off unless you set networkPolicy.enabled to true.

The policy set takes effect only on a cluster whose CNI enforces NetworkPolicy; on any other CNI it renders but has no effect. Treat it as a complement to an authenticating proxy from the patterns above, not a replacement for one.

networkPolicy:
  enabled: true
  admin:
    allowedPeers:
      - podSelector:
          matchLabels:
            app.kubernetes.io/name: oathkeeper
  metrics:
    allowedPeers:
      - namespaceSelector:
          matchLabels:
            kubernetes.io/metadata.name: observability
  egress:
    database:
      - to:
          - namespaceSelector:
              matchLabels:
                kubernetes.io/metadata.name: infrastructure
            podSelector:
              matchLabels:
                policy.ory.sh/db: server
        ports:
          - port: 26257
            protocol: TCP

admin.allowedPeers and metrics.allowedPeers each take a bare list of NetworkPolicyPeer entries, because the chart already knows the port each one protects. egress.database takes complete egress rules instead, each carrying its own to and ports, because the chart has no way to know which port a peer listens on for egress traffic.

Enabling the policy set without networkPolicy.egress.database leaves the migration job unable to reach the database, so configure that rule whenever you enable the set. The policy set also covers the chart's helm test pod, and both directions of its traffic are governed: helm test passes only if you grant that pod egress to the public Service with your own policy and list it in networkPolicy.public.allowedPeers, because the public surface is isolated as well.

Combining admin and self-service

If you also run talos serve public for proof-of-possession self-revocation, place that server behind your public edge — it receives untrusted traffic and validates credentials inline.

Expose the two surfaces on different hostnames, ports, or ingresses so admin paths stay unreachable from the public side even if configuration is misapplied.

Verifying your boundary

Before sending production traffic, confirm that the admin endpoints are unreachable from outside your trusted boundary:

# From an unauthenticated network, this must be rejected at your proxy:
curl -sS -o /dev/null -w '%{http_code}\n' \
  https://talos-admin.example.com/v2alpha1/admin/issuedApiKeys
# Expect: 401, 403, or a connection refused/network unreachable error.

Any response that comes from Ory Talos itself — for example 200, 404, or 501 — means the request reached the admin server without authentication. Fix the boundary before going live.

See also

• Separate admin and public APIs — admin-only, public-only, and all-in-one process layouts.
• Security hardening — broader hardening guidance.