Network and hardening
Fontana reduces attack surface through narrow perimeter exposure, default-deny networking inside each workspace cluster, and workload hardening (dedicated service accounts, resource limits, and Vault Agent injection). Backend services validate opaque tokens through RFC 7662 introspection using dedicated OAuth clients.
Perimeter and exposure
Section titled “Perimeter and exposure”| Surface | Typical production posture |
|---|---|
| Public HTTPS | Host edge accepts 80 and 443 (ACME + redirect) only; no standing SSH ingress on Fontana-managed cloud |
| Kubernetes API | Bound to 127.0.0.1 on the host; remote administration reaches the API through an authenticated host session (AWS SSM Session Manager on Fontana-managed cloud) |
| Workspace backends | Same-origin path routing behind one hostname per workspace; no cross-service browser CORS in tenant mode |
| Shared sandbox MCP | Public HTTPS with ForwardAuth; unauthenticated requests fail closed before reaching the sandbox server |
Inside a workspace, the browser talks to Flow, Convex, platform-api, and the workflow engine through one origin. Traefik strips /_* path prefixes to the correct in-cluster service.
Transmission boundary (TLS)
Section titled “Transmission boundary (TLS)”Fontana terminates TLS at the public edge. Traffic inside the host and inside each workspace cluster is plain HTTP on restricted network paths. Compensating controls are cluster-per-tenant separation, NetworkPolicy default-deny, and no multi-tenant pod sharing on the data plane.
| Hop | Protocol | TLS termination | Notes |
|---|---|---|---|
| Internet to host edge | HTTPS | Host edge (ACME) | Public Flow, Convex, engine, and API paths |
| Edge to in-cluster ingress | HTTP | None (localhost or bridge) | Same physical host |
| Ingress to application pod | HTTP | None | Cluster network; NetworkPolicy scoped |
| Pod to in-cluster Vault | HTTP | None | NetworkPolicy scoped to Vault clients |
| Pod to external LLM or connector | HTTPS | Provider | Egress allow on port 443 from approved workloads |
| Internet to shared sandbox MCP | HTTPS | Host edge | ForwardAuth before MCP server; unauthenticated requests fail closed |
Single-origin routing means the browser never needs cross-service CORS in tenant mode: every call stays on one workspace hostname with path prefixes such as /_convex, /_platform, and /_engine.
Operator and host access
Section titled “Operator and host access”Platform operators (your Fontana deployment team or managed-service administrators) reach the host through controlled paths:
| Access type | Typical production posture |
|---|---|
| Public Internet | HTTPS 80 and 443 only for application traffic; the security group carries no SSH rule on Fontana-managed cloud |
| Shell access | AWS SSM Session Manager on Fontana-managed cloud (authenticated, audited sessions); SSH is a documented break-glass path enabled only per change window |
| Kubernetes API | Bound to 127.0.0.1 on the host; remote administration reaches the API through the same authenticated host session |
| Durable platform changes | Reconciled through the Fontana CLI (fontana apply, pinned tenant upgrades) and Terraform host provisioning automation |
| Break-glass diagnostics | Read-only host diagnostics where your runbook allows; production durable changes still flow through CLI and infrastructure as code |
| Cluster RBAC | Namespaced operator roles (read-only, deploy, secret-admin) are versioned in git and applied at bootstrap; drift is checked with kubectl diff against the committed manifests |
| Operator dashboards | Gatus (HTTP basic auth), HyperDX (native login provisioned via API), and the Convex dashboard (admin key) each require authentication before any data; credentials live in workspace Vault and surface through fontana secrets <tenant> |
Workspace end users never receive host or cluster credentials. They authenticate through Zitadel OIDC in the browser and are authorised by application RBAC in Flow.
See Deployment environments for which host classes are in SOC 2 scope.
Cloud account perimeter (Fontana-managed AWS)
Section titled “Cloud account perimeter (Fontana-managed AWS)”On Fontana-managed cloud, the AWS account surrounding the production host carries its own Terraform-managed control set, complementing the in-cluster stack (Vault, NetworkPolicy, ImmuDB WORM audit):
| Control | What it provides |
|---|---|
| Organization CloudTrail | Every operator sign-in and cloud API call is recorded to a dedicated audit bucket with log-file validation |
| AWS Config rules | Continuous drift detection: security-group ports, volume encryption, public bucket exposure, trail status |
| GuardDuty and Security Hub | Threat detection plus FSBP and CIS benchmark checks; high and critical findings route to the security mailbox |
| Daily volume snapshots | The persistent data volume is snapshotted daily with a rolling retention window (complements platform snapshots) |
| SSO-only operator identity | Operators authenticate through IAM Identity Center with least-privilege permission sets; no long-lived IAM access keys |
| WORM evidence bucket | S3 Object Lock in compliance mode archives integrity-scan evidence off-box for the retention period |
Customer VPC deployments can apply the same pattern in their own account; the audit surface (CloudTrail, Config, GuardDuty) is standard AWS tooling driven by infrastructure as code.
NetworkPolicy (default deny)
Section titled “NetworkPolicy (default deny)”Each workspace cluster applies default-deny NetworkPolicy in the application namespace, then scoped allow rules per workload:
- DNS resolution for allowed pods
- Postgres, Vault, and Convex only from designated clients
- Egress to external HTTPS for approved connector and LLM traffic from engine and Convex paths
- Observability and health probes on documented ports
The goal is least privilege between pods: a compromised workload cannot reach arbitrary cluster services or the Internet without an explicit allow rule.
Pod and workload hardening
Section titled “Pod and workload hardening”| Control | Approach |
|---|---|
| Service accounts | Per-workload Kubernetes ServiceAccounts; no reliance on the default SA |
| Pod Security | Baseline profile enforced on tenant workloads |
| Resources | CPU and memory limits on Deployments |
| Secret injection | Vault Agent sidecars where required; no long-lived secrets in plain env ConfigMaps |
| Single-replica file store | Workflow engine uses Recreate strategy on ReadWriteOnce PVC so only one pod mounts run data at a time |
Service authentication
Section titled “Service authentication”Human users authenticate through Zitadel OIDC in the browser. Backend services use dedicated OAuth clients and token introspection:
- Workflow engine validates opaque tokens before executing privileged paths
- observability-api gates security audit ingest and operational routing
- Misconfigured introspection or discovery causes fail-closed errors rather than anonymous access
See Identity and access for SSO, MFA, SCIM, and application RBAC.
Identity events in audit
Section titled “Identity events in audit”Sign-in, MFA challenges, role changes, and deprovisioning feed the immutable security audit trail through observability-api. See Security audit (WORM).
Related documentation
Section titled “Related documentation”- Workspace isolation - per-cluster network boundary
- Secrets and encryption - TLS and in-cluster HTTP compensating controls
- Deployment architecture - single-origin routing table
- Deployment environments - production-class SOC 2 scope
- SOC 2 control summary - network and authentication rows