Network isolation
Security
Every Greenlight app runs inside a dedicated Kubernetes namespace, and every namespace carries a NetworkPolicy that defines exactly which traffic can enter and leave. Greenlight does not rely on the cluster default-allow behavior; the rules are explicit, the rules are tight, and there are no per-app overrides.
The rules
Section titled “The rules”The NetworkPolicy attached to every app namespace permits a few specific flows and blocks the rest.
| Direction | What’s allowed |
|---|---|
| Ingress | From the cluster’s ingress controller only. The controller terminates TLS and enforces SSO before any traffic reaches an app pod. |
| Egress (proxied integrations) | To the Greenlight data proxy. For a proxied integration the app never holds the upstream credential — it calls the proxy, which resolves the grant, swaps in the real credential, and audits the call. App code cannot resolve or reach the upstream itself. |
| Egress (injected integrations) | To the specific host of a granted integration whose credential IT delivers directly into the app’s environment (used for things an HTTP proxy can’t carry — a database connection string, a binary wire protocol). The allow-list carries one entry per granted injected host, and nothing wider. |
| Egress (own database) | To the app’s own provisioned Postgres on port 5432, inside the cluster network. A database wire protocol can’t ride the HTTP proxy, so the app connects to its own database directly — it still can’t reach any other app’s database. |
| Egress (DNS) | To the cluster’s kube-dns only, for resolving in-cluster service names. No external DNS. |
Everything else — pod-to-pod across namespaces, public-internet egress, raw TCP to arbitrary hosts — is blocked at the NetworkPolicy layer. An injected integration’s host is reachable only because IT granted that integration to that app; revoke the grant and the egress entry goes with it.
What this gives you in practice
Section titled “What this gives you in practice”A compromised app cannot pivot to other Greenlight apps in the cluster. A code-injection bug cannot exfil data to an attacker-controlled host. An accidental hard-coded URL in app code returns a network error rather than reaching the internet. An SSRF vulnerability cannot reach the cloud’s metadata service because the metadata IP is not on the egress allow-list.
The egress surface is exactly the set of upstreams IT granted to the app, plus the proxy, the app’s own database, and cluster DNS — nothing else. A proxied integration adds no new outbound host at all (the app only ever talks to the proxy); an injected integration adds exactly one. There is no app-controlled way to widen it.
These are the boring everyday properties a security review asks about. They are enforced by the cluster, not by app-side configuration the developer might forget.
What’s on the control-plane side
Section titled “What’s on the control-plane side”The Greenlight control plane runs in its own namespace inside the customer’s cluster. It is not reachable from app namespaces except through the data proxy — and the proxy rejects requests that don’t match a granted integration.
The control plane’s own egress is restricted to the customer’s IdP, the configured cloud provider APIs, and Key Vault. It does not call out to Shift-operated services at runtime. The control plane never has a path from a compromised app pod.
What needs new integrations vs ad-hoc egress
Section titled “What needs new integrations vs ad-hoc egress”If an app needs to reach a new upstream system, IT registers it as an integration — from the built-in catalog of common services, or via the custom path for anything not catalogued. There is no “let one app out to one IP” exception path; that would create an asymmetric audit trail and a per-app NetworkPolicy that drifts. Adding the upstream through Greenlight is a quick registration and gives the app a stable proxy URL (or, for an injected credential, a named environment variable), an audited credential, and a clean revocation story.
What’s enforced where
Section titled “What’s enforced where”- Container runtime: blocks privileged operations, host networking, host PID namespace.
- NetworkPolicy: blocks unauthorized network flows as described above.
- Ingress controller: enforces TLS termination and SSO before traffic reaches an app.
- Data proxy: enforces integration grants and per-call audit at the application layer, for proxied integrations.
- Cloud provider IAM: enforces workload-identity scoping so a compromised workload cannot use its identity outside its app’s role.
Each layer enforces something independent. A bypass would need a real defect in the layer, not just a misconfiguration.