Network and hardening
Fontana reduces attack surface through narrow perimeter exposure, default-deny networking in every workspace namespace, 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 | The cluster ingress accepts 80 and 443 only (certificate validation and redirect); no standing SSH ingress on Fontana-managed cloud |
| Kubernetes API | Never published to the internet. On a self-hosted server the host firewall closes it and operators reach it over an authenticated SSH session; on AWS the EKS endpoint is reached with your account’s authentication, by roles you grant |
| 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, backend services, and the workflow engine through one origin. Path prefixes route each request to the correct service.
Transmission boundary (TLS)
Section titled “Transmission boundary (TLS)”Fontana terminates TLS at the cluster ingress, where cert-manager obtains and renews certificates from Let’s Encrypt automatically. Traffic between pods is plain HTTP on restricted network paths. Compensating controls are namespace separation per workspace, NetworkPolicy default-deny, and no multi-tenant pod sharing on the data plane.
| Hop | Protocol | TLS termination | Notes |
|---|---|---|---|
| Internet to cluster ingress | HTTPS | Ingress (cert-manager) | Public Flow, backend, engine, and API paths |
| Ingress to application pod | HTTP | None | Cluster network; NetworkPolicy scoped |
| Pod to workspace 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 | Ingress (cert-manager) | 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 cluster 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 |
| Deploy path | The deploy job authenticates with short-lived credentials from your pipeline’s identity provider and runs fontana apply against the cluster API. There is no application server to log into |
| Kubernetes API | Not published to the internet: closed at the host firewall on a self-hosted server, or authenticated by your cloud account on AWS. An operator with SSO can run the same fontana apply as a break-glass path |
| Durable platform changes | Reconciled through the Fontana CLI (fontana apply with a pinned release tag) and Terraform cluster provisioning automation |
| Break-glass diagnostics | Read-only cluster diagnostics where your runbook allows; durable production changes still flow through the 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), Grafana (native login provisioned via API), and the backend 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 cluster credentials. They authenticate through Zitadel OIDC in the browser and are authorised by application RBAC in Flow.
See Deployment environments for which environment 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 workspace 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 | Persistent volumes are snapshotted daily with a rolling retention window, alongside the scheduled online exports |
| 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 namespace applies default-deny NetworkPolicy, 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 the observability API. See Security audit (WORM).
Related documentation
Section titled “Related documentation”- Workspace isolation - per-cluster network boundary
- Secrets and encryption - TLS and workspace-internal HTTP compensating controls
- Deployment architecture - single-origin routing table
- Deployment environments - production-class SOC 2 scope
- SOC 2 control summary - network and authentication rows