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
The NetworkPolicy attached to every app namespace permits three 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 (data path) | To the data broker only. App code cannot resolve or reach an upstream service directly. |
| Egress (DNS) | To the cluster’s kube-dns only, for resolving the broker’s internal service name. No external DNS. |
Everything else — pod-to-pod across namespaces, public-internet egress, direct database connections, raw TCP to arbitrary IPs — is blocked at the NetworkPolicy layer.
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.
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
The Greenlight control plane runs in its own namespace inside the customer’s cluster. It is not reachable from app namespaces. The only path from an app to the control plane is through the data broker — and the broker 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
If an app needs to reach a new upstream system, IT registers it as an integration. 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 60-second registration and gives the app a stable proxy URL, an audited credential, and a clean revocation story.
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 broker: enforces integration grants and per-call audit at the application layer.
- 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.