Security

Altuur Secure Ingress treats security as architecture, not configuration. The platform’s outbound-only connectivity model, edge-enforced authentication, and mutual TLS produce security properties that are structurally guaranteed rather than bolted on after deployment.

This section covers four areas:

1. Transport security: TLS 1.3, mutual authentication, and Altuur’s internal PKI
2. Authentication model: edge-enforced auth, per-route policies, identity propagation
3. Data protection: data handling, privacy principles, and encryption
4. Standards conformance: the exact OAuth 2.1 and OpenID Connect surface the platform implements

The outbound-only security model

Traditional internet services require an inbound stack: public IP addresses, open ports, firewall rules, reverse proxies, and TLS termination at the origin. Each layer expands the attack surface.

Secure Ingress inverts this model. Warpgate initiates all connections outward. Your workloads need:

• No open inbound ports: Warpgate dials out, so nothing has to listen for the internet
• No public inbound origin: no public IP address and no DNS record pointing to the workload are required
• No origin exposure: unlike traditional CDN or reverse proxy setups, once direct access is closed there is no discoverable origin IP that attackers can target around the edge

End-user traffic enters through the Altuur Edge, where TLS termination, route policy, and, on protected routes, end-user authentication are applied before any request reaches your infrastructure. Public routes (for example a health check) pass through without end-user authentication.

These properties depend on the edge being the only route in. Adding Warpgate does not remove an existing public IP, listener, or firewall rule; remove or firewall them so that no direct path to the workload remains. See Close the direct path.

Defense in depth

Security policies are enforced at two layers:

1. Edge enforcement: the Altuur Edge authenticates requests on protected routes, applies route policies, and filters malicious traffic before forwarding
2. Warpgate validation: Warpgate validates routes and identity context as a second line of defense before delivering traffic to the upstream workload

This layered approach means that even if one enforcement point were compromised, the other continues to protect the workload.

Transport encryption

All connections in the Secure Ingress architecture are encrypted:

Certificates are managed by Altuur’s internal certificate authority. You do not need to provision, rotate, or manage any certificates.

The mTLS identity on the edge-to-Warpgate connection is a connector identity: it proves which Warpgate is connected. It is distinct from end-user authentication, which is enforced per route and applies to the people, devices, and services calling your service.

Read the full details in mTLS and TLS 1.3.

Authentication at the edge

When authentication is enabled on a route, Secure Ingress handles the complete identity lifecycle at the edge:

• Login, signup, and password reset flows
• Session management and token validation
• Per-route authorization policies
• Identity context forwarding to the workload

Your application receives pre-authenticated traffic with trusted identity headers; no token validation libraries, no auth middleware, no integration project.

Read the full details in Authentication Model.

Data protection

Secure Ingress processes request traffic at the edge and forwards it to your workload. Identity data (user accounts, directories, credentials) is stored in the control plane with encryption at rest.

The outbound-only architecture means your workload’s data and infrastructure remain private. Secure Ingress never requires access to your application’s internal state, database, or file system.

Read the full details in Data Protection.