Zscaler ZPA: Securing GPU-Native AI Workloads on CoreWeave with Zero Trust App Access (ZPA + CKS)

Zscaler ZPA: Securing GPU-Native AI Workloads on CoreWeave with Zero Trust App Access (ZPA + CKS)

AI teams are moving fast, spinning up GPU clusters for training, scaling inference fleets for new product launches, and iterating on pipelines that blend data, models, and orchestration into one continuous delivery loop. But as these workloads shift to cloud-native, Kubernetes-based platforms, the traditional security model often cannot scale to the new architecture. Teams still expose “temporary” endpoints to the internet, punch holes in firewalls for admin tools, or rely on legacy VPN patterns that were never designed for high-value AI services distributed across ephemeral infrastructure.

At Zscaler, a consistent theme emerges: AI infrastructure is becoming one of the most sensitive environments in the enterprise. It now hosts a business critical environment including proprietary models, customer datasets, vector indexes, internal tooling, and privileged control planes. The question is no longer “how do teams connect?” – it is “how does the organization provide secure access that is least-privileged, continuously verified, and operationally simple for Kubernetes-scale platforms?”

That is where the combination of Zscaler Private Access (ZPA) and CoreWeave Kubernetes Service (CKS) becomes compelling: purpose-built AI cloud workloads paired with Zero Trust app access—without reintroducing a conventional network perimeter.

Why legacy VPN access breaks down for modern AI platforms

Traditional VPNs were built to connect by extending the network to a remote user. In practice, that means exposing gateways to the internet; and connecting users to broad internal address space—creating a large attack surface while also enabling lateral movement if credentials or endpoints are compromised. This “network-first” model also makes segmentation difficult and increases operational overhead as environments scale across clouds and regions.

AI environments amplify these risks:

• More high-value targets per cluster: model artifacts, training data, API keys, control planes, and internal dashboards
• More identities that need access: ML engineers, platform engineers, data scientists, SREs, and partner teams—often globally distributed
• More ephemeral services: short-lived jobs, autoscaled inference, dynamic namespaces, and constantly shifting service endpoints

The access layer has to keep up with that dynamism—without turning Kubernetes into a new flat network.

ZPA’s model: application access, not network access

ZPA was designed to remove the assumption that “being on the network” is a prerequisite for reaching private apps. Instead of inbound connectivity, ZPA uses an inside-out architecture: App Connectors initiate outbound TLS connections to the Zscaler Zero Trust Exchange, and users connect outbound through the Zscaler Client Connector—so private apps do not need to be exposed to the internet.

Just as important, ZPA enforces user-to-application segmentation powered by AI. Users are granted access to specific applications and ports based on identity and context rather than receiving broad network reachability. ZPA can also hide real server IPs using a synthetic addressing approach at the client, reducing DNS/IP-based reconnaissance and limiting lateral movement opportunities. 

For cloud-native AI, this is the shift that matters:

• from network access → to direct application access
• from implicit trust → to least privilege with continuous verification
• from static perimeters → to dynamic segmentation

Why CoreWeave is an ideal target for Zero Trust AI access

CoreWeave’s AI Cloud aligns well with how modern AI teams run: GPU-first infrastructure, Kubernetes-native operations, and performance-sensitive scheduling and data paths.

CoreWeave CKS is a managed Kubernetes foundation optimized for AI workloads, providing Kubernetes-native approaches to AI scheduling—such as Kueue for batch AI/ML workloads. CoreWeave also allows hybrid models that unify traditional HPC workflows with Kubernetes through Slurm on Kubernetes (SUNK), supporting batch and burst patterns at scale.

On the infrastructure side, CoreWeave highlights high-performance networking fabrics and DPU-based isolation approaches as part of designs intended for large-scale GPU workloads. This combination—Kubernetes-native AI operations plus high-value private services—creates an ideal environment for ZPA’s app-segmented, inside-out access.

The joint pattern: containerized ZPA App Connector running inside CKS

The solution pattern is a strong architectural fit:

1. Deploy the containerized ZPA App Connector into the customer’s CKS cluster (often into a dedicated security/egress namespace with appropriate Kubernetes NetworkPolicies).
    
2. The App Connector establishes outbound TLS connectivity to the Zscaler Zero Trust Exchange—no inbound listener and no public IP exposure required.
    
3. Users access specific CKS-hosted services via ZPA policies based on identity, device posture, and application segmentation.

In practice, ZPA brokers access without putting users “on” the Kubernetes network. Users authenticate through enterprise identity, ZPA evaluates policy, and traffic is carried through outbound TLS sessions to the Zscaler Zero Trust Exchange. Requests are then brokered to the appropriate App Connector running inside CKS, which connects to the intended private service inside the cluster and returns traffic through the same brokered path. This model keeps service IPs non-advertised and prevents broad network reachability, while still delivering user access to precisely defined applications and ports.

A key advantage is that ZPA App Connectors are available as containerized deployments (including Helm-based workflows for Kubernetes distributions).

What joint customers enable (without changing how AI teams build)

This pattern supports least-privileged access to:

• Inference endpoints (internal model gateways, gRPC services, protected REST APIs)
• Training orchestration services (job submission portals, internal schedulers, pipeline controllers)
• Developer tooling (Jupyter, internal UIs, experiment tracking endpoints)
• Data services adjacent to compute (vector databases, feature stores, internal storage gateways)

CoreWeave describes running vector databases and caching layers alongside GPU workloads on CKS to support production RAG and agentic pipelines—examples of services that are often intended to remain private.

Operational fit for Kubernetes-scale AI

AI platforms are elastic; access should be elastic too.

ZPA’s model supports:

• Horizontal scaling: adding App Connector capacity as demand grows rather than scaling a central VPN chokepoint
• Distributed placement: deploying connectors per region, per cluster, or per environment to align with organizational segmentation models
• Automation: leveraging API-driven workflows to integrate secure access into cluster lifecycle and provisioning pipelines

CoreWeave emphasizes platform-level visibility and operational controls through Mission Control, aligning with enterprise expectations for governance and auditability around sensitive AI environments.

What this enables for joint customers

From a Zscaler perspective, the outcome is straightforward: AI services remain private by default while collaboration remains fast.

This approach supports outcomes such as:

• Reduced exposure of AI infrastructure: fewer public endpoints, fewer inbound rules, fewer exceptions
• Cleaner least-privilege access: per-service segmentation mapping naturally to Kubernetes services and ports
• Lower blast radius: limiting broad network reachability reduces lateral movement paths
• Faster enablement for new services: new internal endpoints can be onboarded via policy rather than network redesign

Getting started

A practical rollout plan typically includes:

1. Identify private services in CKS that should remain non-internet-facing (model endpoints, admin tools, data services).
    
2. Define application segments aligned to those services (hostname + port) and map them to groups/roles.
    
3. Deploy the containerized App Connector into CKS with appropriate placement, egress allowances, and operational controls (replicas, upgrades, telemetry).
    
4. Integrate identity context (IdP groups, device posture, MFA signals) and validate workflows for both human and automation access.
    
5. Iterate segmentation as AI services evolve, treating access policy as governed configuration aligned to platform change management.

The collaboration between Zscaler and CoreWeave is detailed in a deployment guide, offering a simple starting point for implementing our joint solution.

Secure access as an AI platform primitive

When GPU workloads move to Kubernetes-native platforms like CKS, the access layer benefits from being equally cloud-native: identity-driven, application-segmented, and inside-out by design.

With ZPA’s containerized App Connector deployed into CoreWeave CKS, joint customers can enable secure, least-privileged access to GPU-hosted workloads, data services, and operational tooling—without reverting to a VPN-era network perimeter.