Just finished a forced migration off Umbrella to Netskope ZTNA. The security team's win was our SRE team's headache. The core promise was the same: secure egress for our workloads. The implementation was not.
Our main breakage was all DNS & egress-dependent automation in CI/CD and monitoring. Netskope's proxy-first model doesn't play nice with everything that assumes a direct, DNS-resolved connection.
Specific breaks:
* **Helm chart pulls** from internal repositories started failing. The `helm` CLI and some chart tools don't respect the `HTTP_PROXY` environment variables consistently.
* **K8s liveness/readiness probes** to external dependencies (like a dependency API) timed out. The pod network doesn't automatically route through the ZTNA client.
* **Container builds** inside pipelines (`docker build`) that need to `apt-get update` or fetch binaries failed. Build containers often don't have the ZTNA client or proxy settings.
Biggest issue was the shift from DNS-based policies (Umbrella) to app-id/URL-based in Netskope. Our automation that talks to, say, `api.github.com:443` isn't an "application" Netskope recognizes by default. Had to manually define hundreds of allowances.
Temporary fix was adding proxy env vars to pod specs and pipeline runners, but that's messy.
```yaml
env:
- name: HTTPS_PROXY
value: "http://netskope-gateway.company.com:port"
- name: NO_PROXY
value: ".svc,.svc.cluster.local,169.254.169.254"
```
Long-term, we're pushing for a dedicated egress CIDR with relaxed policies for automation, but it's a fight.
Anyone else hit this? How did you handle service accounts, non-interactive workloads, and internal registry traffic?
— a2
Ship it, but test it first
We're a mid-market SaaS, around 150 people. I run our billing and subscription platform. All our transactional microservices and CI/CD run in EKS, with Recurly handling payments.
**Primary Use Case Fit:** Umbrella is for straightforward DNS-level policy. Netskope is for deep app-layer inspection. If your stack just needs egress control, Netskope is heavy.
**Real Cost Gap:** Umbrella was about $3-5 per user per month for us. Netskope entered at $8-12 per user minimum, and that's before the ZTNA module add-on.
**Deployment Model:** Umbrella deploys via DNS resolver config in your VPC. Netskope requires a client or explicit proxy config on every workload. That's the root of your automation breakage.
**Where Netskope Breaks:** Exactly your points. Anything not proxy-aware fails. We saw the same with Helm, apt-get in builds, and probes. You must maintain a detailed allow-list of every external FQDN and port as an "application."
**Where Netskope Wins:** If you need granular, session-aware control over SaaS app usage (like "allow Google Drive download but block upload"), Netskope does that. Umbrella only sees DNS queries.
I'd stick with Umbrella for pure workload egress. For your described use case, it's the simpler fit. The choice depends on two things: does your security team actually need app-layer policies, and are they willing to fund the engineering time to retrofit all your automation?
You hit the nail on the head with the proxy-aware vs. DNS-level model. The real cost here is the operational debt.
Every container, every CI job, every custom tool now needs explicit proxy config. You'll find more breakage: custom operators, service mesh sidecars, even some SDKs for AWS services (looking at you, Boto3 in certain modes) will ignore `HTTP_PROXY`.
Your point about manually defining allowances is the killer. With Umbrella, you controlled DNS resolution. With Netskope, you're now maintaining an application catalog for your automation. That's a full-time job they didn't budget for.
Did your security team even run a TCO analysis, or was this just a checkbox for their "zero trust" roadmap? The forced migrations I see always blow the ops budget.
cost optimization, not cost cutting