Networking
The platform's network architecture is designed around a principle: data clusters should never be directly exposed to the internet. All external access to data clusters flows through the platform's authenticated proxy layer, and cross-cluster connectivity uses encrypted mTLS tunnels that require no inbound firewall rules on the data cluster side.
Network Architecture Overview
Alien Hosted Networking
When both the platform and data clusters are hosted by Alien, networking is internal and managed:
- Platform services and data clusters run in the same cloud provider's network
- Communication uses internal service addresses — traffic does not traverse the public internet
- The same mTLS encryption and authentication applies as in On-Premise mode
- No networking configuration is required from the customer
On-Premise Networking: Skupper mTLS Tunnels
For On-Premise data clusters, the platform uses Skupper to create encrypted mTLS tunnels between the platform and your infrastructure. Skupper is a layer 7 service interconnect that operates at the application level, making it work in environments where traditional VPNs or direct connections are impractical.
How Skupper Works
The key property of Skupper tunnels is that they are initiated outbound from the data cluster. Your infrastructure makes an outbound HTTPS connection to the platform — it does not need to accept any inbound connections.
Connection establishment is a one-time process:
Why Skupper Instead of VPN
| Concern | Traditional VPN | Skupper |
|---|---|---|
| Firewall rules | Requires inbound ports open | No inbound rules — outbound HTTPS only |
| Certificate management | Manual PKI setup | Automatic mTLS certificate rotation |
| Service discovery | Manual IP/DNS configuration | Automatic — virtual services appear as local |
| Granularity | Network-level (all traffic flows) | Service-level (only specified services are exposed) |
| Corporate firewalls | Often blocked by IT policies | Uses standard HTTPS — passes through most firewalls |
Skupper tunnels use mutual TLS (mTLS) — both the platform and the data cluster verify each other's identity with certificates. This is not just encryption; it is mutual authentication. A compromised network cannot impersonate either side.
The Proxy Architecture
All external access to data clusters — whether from users, AI workflows, or MCP agents — goes through the platform backend's proxy endpoint. The proxy is a security layer, not just a relay.
Request Flow
Why a Proxy Instead of Direct Access
The proxy architecture provides several guarantees:
- No direct exposure — Data APIs have no public endpoints. There is no attack surface for direct exploitation.
- Centralized authentication — The platform handles all user authentication. Data APIs trust the platform's forwarded identity headers because they come through the authenticated tunnel.
- Unified audit trail — Every data access is logged at the platform level, regardless of whether it originated from a user, a workflow, or an AI agent.
- Cluster status enforcement — Offline or suspended clusters reject all proxy requests. The platform can control access to clusters without modifying the cluster's configuration.
- Source type tracking — The proxy records whether the request came from a human, a worker, or an MCP agent, enabling fine-grained access analytics.
Service Mesh (Platform Internal)
Within the platform cluster, all services communicate through Istio, a service mesh that provides:
- Mutual TLS (mTLS) between all pods — even internal traffic is encrypted and authenticated
- Authorization policies that restrict which services can call which. For example, only the backend can call the Skupper Gateway service.
- Traffic management — VirtualService routing directs requests to the correct service based on hostname and path
- TLS termination at the ingress gateway with automatically renewed certificates
The service mesh is transparent to the application layer — services make standard HTTP calls, and Istio handles encryption, identity verification, and policy enforcement at the network layer.
Data Cluster Internal Networking
Within a data cluster, services communicate over the internal Kubernetes network:
| Service | Access Pattern | Security |
|---|---|---|
| PostgreSQL | TCP from Data API only | Per-tenant database with scoped credentials |
| MinIO | HTTPS from Data API and pipeline pods | TLS with auto-generated certificates, per-tenant IAM |
| Qdrant | HTTP from Data API and pipeline pods | JWT RBAC with per-tenant tokens |
| Meilisearch | HTTP from Data API | Master key + per-tenant API keys |
| Data API | No public ingress | Reachable only via Skupper tunnel from the platform |
Pipeline pods (Argo Workflows) run in the same namespace as the Data API and communicate over the internal cluster network. They do not go through the proxy — they access storage services directly using per-tenant credentials injected as Kubernetes Secrets.
TLS and Encryption
Encryption in transit is enforced at every layer:
| Path | Encryption | Certificate Management |
|---|---|---|
| Internet to platform | TLS (Let's Encrypt) | Automatic renewal via cert-manager |
| Platform service-to-service | mTLS (Istio) | Automatic rotation via Istio CA |
| Platform to data cluster | mTLS (Skupper) | Automatic rotation via Skupper |
| Data API to MinIO | TLS | Auto-generated by MinIO Operator |
| Data API to PostgreSQL | TLS | Managed by CloudNativePG |
No unencrypted traffic flows between any components in the production architecture.
On-Premise Connectivity Requirements
If you deploy data clusters on your own infrastructure, the following network connectivity is required:
Outbound (from your infrastructure)
| Destination | Port | Protocol | Purpose |
|---|---|---|---|
| Platform API | 443 | HTTPS | Operator heartbeats, batch sync, registration |
| Skupper Router (platform) | 443 | HTTPS/WebSocket | mTLS tunnel establishment and data traffic |
| AI provider APIs (optional) | 443 | HTTPS | Mistral OCR, embedding APIs — only if pipelines call external AI services |
Inbound (to your infrastructure)
None. The architecture is designed so that data clusters never need to accept inbound connections. Skupper tunnels are outbound-initiated, and the platform reaches your data cluster through the established tunnel.
This outbound-only model is specifically designed for enterprise environments where IT policies prohibit inbound firewall rules for external services. Your infrastructure initiates the connection; the platform cannot "reach in" without the tunnel being established from your side.
Next Steps
- Infrastructure — Per-cluster infrastructure components and orchestration
- Security Model — Authentication and authorization at every layer
- Deployment Model — Alien Hosted vs On-Premise comparison
- Data Sovereignty — How data isolation is enforced