Tenant Egress and Network Access
GWEB tenant environments are private by default. This document captures the tenant-facing networking model after the GEDU AIOS connectivity issue and the E3 egress productization work.
Default posture
A standard tenant namespace uses a deny-by-default network baseline.
Typical policy shape:
text
default-deny-ingress
default-deny-egress
allow-dns-egress
allow-same-namespaceAdditional ingress or egress is granted narrowly for a specific workload or platform function. One managed namespace does not implicitly trust another.
Why an application can be Ready but still fail externally
Kubernetes readiness, Service existence, HTTPRoute acceptance, DNS resolution, and application egress are separate checks.
For example:
text
Pod Ready yes
Service endpoints yes
HTTPRoute Accepted yes
DNS resolution yes
outbound dependency reachable noA default-deny egress policy can permit DNS while still denying the TCP connection to the resolved destination.
Likewise, Gateway API Accepted=True / ResolvedRefs=True validates routing objects; it does not prove NetworkPolicy packet reachability between namespaces.
GEDU lesson
GEDU exposed two important networking classes that must not be confused:
text
ingress:
gweb-ingress / Traefik -> tenant workload
egress:
tenant workload -> external or platform dependencyA 502 on a public route can be caused by ingress NetworkPolicy blocking the gateway-to-backend hop. An application error involving an external API can instead be caused by tenant egress policy.
Troubleshooting should identify which hop is failing before changing policy.
Tenant workflow
Use tenant-facing application inspection first:
bash
gwebc --profile <profile> app show <application> \
--environment <environment>
gwebc --profile <profile> app diagnostics <application> \
--environment <environment>
gwebc --profile <profile> app logs <application> \
--environment <environment>Use the installed gwebc app --help as the authoritative syntax if the command contract changes.
Application endpoint names and non-secret runtime values should be carried through managed configuration. Credentials/tokens belong in managed secrets:
bash
gwebc --profile <profile> config --help
gwebc --profile <profile> secret --helpConfiguration does not itself grant network access. The platform policy must also authorize the required path.
Policy principles
When egress is required, authorization should be:
- application-scoped where practical;
- environment-scoped;
- tenant-scoped;
- limited to required protocol/port/destination class;
- auditable and reproducible;
- managed by GWEB control-plane/Ops policy rather than ad hoc tenant
kubectl.
Avoid broad "allow all egress" as a normal application fix.
DNS is not general internet access
allow-dns-egress permits DNS to the cluster resolver. It does not authorize arbitrary Internet connections.
A successful:
text
DNS lookupdoes not imply a successful:
text
HTTPS/API/database connectionPublic ingress is not egress
The presence of a policy such as allow-gweb-ingress grants the GWEB ingress plane access to selected public workloads. It does not grant the workload outbound access.
Treat ingress and egress as separate contracts.
Escalation boundary
Tenants should not directly create or patch Kubernetes NetworkPolicy as part of a normal application deployment.
If the required outbound policy is not currently exposed through gwebc, record the required destination/protocol/port and use the platform-managed policy workflow. Do not bypass the GWEB control plane with node SSH or tenant kubeconfig.
Validation checklist
For an outbound dependency, validate in this order:
- runtime config points to the intended hostname/port;
- DNS resolves from the application environment;
- a matching egress authorization exists;
- the destination accepts the connection;
- TLS/application authentication succeeds;
- application diagnostics/logs no longer show the dependency failure.
This keeps DNS, network authorization, transport/TLS, and application credentials as distinct failure domains.