Choosing egress and connectivity strategies
Last updated: 10/13/2026
Use this topic to choose the right outbound network strategies for Dynamic Engine based on
your security constraints, endpoint stability, and operational overhead.
Choose the strategies that match your environment
| Use case | Recommended topic |
|---|---|
| You need outbound traffic through a corporate proxy in restricted or air-gapped environments. | Using an HTTP proxy for Dynamic Engine services in air-gapped environments |
| You want baseline network controls with default policy behavior. | Deploying Dynamic Engine with default network policies |
| You must allow egress only to known destinations and keep a strict allowlist. | Restricting egress to known IP addresses for Dynamic Engine |
| You allow broader outbound access but still need internal traffic restrictions. | Allowing general egress with internal restrictions for Dynamic Engine |
Scope impact and volatility
- These changes are environment-wide and can affect all workloads deployed in the Dynamic Engine namespace.
- Known-IP policies require more maintenance because external endpoint IP addresses can change over time.
Verify and recover
After applying any model, validate connectivity and workload behavior. If requests fail, review policy and mount diagnostics in Troubleshooting Kubernetes resource mounting in Dynamic Engine environments and in the relevant network policy topic.