Modernizing Cloud Workload Policies: Using Tags and Attributes with Zscaler Private Access

Intro and Some History

If you’re reading this, you’re probably familiar with Zscaler Private Access (ZPA) and the Zero Trust model. When we introduced ZPA around 2016, it was a key step in helping enterprises move from network-centric security to application-centric security. Rather than granting network access, ZPA provides application access. In other words, you never connect users into your network; each session is evaluated against policy so that no user can access an application unless explicitly allowed. Historically, these policies combined user attributes (username, group membership, department) and device attributes (e.g., CrowdStrike installation status, domain membership). This ensures that every application attempt—whether allowed or blocked—is tied to a user and device posture.

Fast forward to around 2020, when Zscaler began extending the Zero Trust Exchange to support non-human entities. What about servers, workloads, and devices that either cannot have a client installed or have no user attribution? This new challenge led us to introduce Cloud Connectors and Branch Connectors. Think of these as Zero Trust network gateways you can deploy at the edge in physical data centers or public clouds (AWS, Azure, GCP). These connectors handle both secure internet egress (via Zscaler Internet Access, ZIA) and provide brokered access to private applications using ZPA.

Consider your organization’s public cloud footprint. Many companies rely on expensive circuits or site-to-site VPNs to connect disparate environments for server-to-server communication. Just as we’ve replaced traditional VPNs for user access, Zscaler’s Zero Trust Networking portfolio does the same for non-human workloads. Each set of Cloud Connectors or Branch Connectors you register creates a Location object in Zscaler. This lets you segment policies, generate detailed reports, and exert granular control over the sources behind these connectors. For instance, you might have AWS regional hubs where Cloud Connectors reside, while workloads spread across many VPCs connect via a Transit Gateway. Azure environments might do something similar with VNET Peering or Virtual WAN Hubs.

Image 1: Zscaler Location Management:

This approach enables private application access through the same Zscaler fabric you trust for user access. Instead of user attribution, though, you now see Location and Sub-location attribution. Organizations are used to network-based rules like Security Groups and ACLs, and we’ve now adapted the Zero Trust model to these non-human entities as well. With that foundation set, let’s explore how Zscaler is modernizing cloud workload security.

Image 2: Zscaler Sub-locations based on VPC CIDRs:

Image 3: Zscaler Private Access Policy based on Locations:

Tag Discovery Service (TDS)

The first step is to discover user-defined tags and attributes for workloads in public clouds. These attributes aren’t found in the network packets themselves. Instead of relying on source IPs or ports, TDS allows Zscaler to integrate with your public cloud accounts using read-only permissions. This integration identifies attributes like environment, platform, or function—metadata already defined within your cloud environment. For more details, check out the “How to Enable User-Defined Tags” blog.

Once TDS discovers these tags, you can leverage them as additional criteria in Zscaler policies for both ZIA and ZPA. That’s essentially it: TDS provides the cloud context you need, and now you can use that context directly in your security policies.

Image 4: Zscaler Partner Integrations (AWS Accounts Example):

Image 5: AWS Workload Details - Attributes and Tags:

Using Workload Tags & Attributes in ZPA 

Tag Discovery Service is platform-agnostic, meaning you can create policies based on these tags and attributes no matter where your workloads run—AWS, Azure, or GCP. This is accomplished through Workload Groups.

A Workload Group is made up of one or more (up to eight) key:value pairs with Boolean logic to define a set of tags and attributes. For example, you might have a Workload Group named “Production K8S Servers” with: Environment=Production AND Type=K8S AND Platform=Linux/UNIX

Image 6: Creating a Zscaler Workload Group:

Defining Workload Groups allows you to reuse combinations of tags and attributes. Notice we’re not tying these attributes to specific platforms—this universal approach works across AWS, Azure, and GCP. Of course, you can narrow things down to platform-specific groups if you want, but the key advantage is flexibility and scalability.

After defining your Workload Groups, you can create ZPA Access Policies for workloads. As with user policies, ZPA Access Policies determine whether traffic is allowed or blocked based on selected criteria. If you’ve been using ZPA for user access and now want to extend it to workloads, you may need to create new policies. Existing policies might rely on user attributes that workloads don’t have, resulting in blocked traffic. But the learning curve is minimal. For workloads forwarded to ZPA via Cloud Connectors, it’s best practice to create new Access Policies using criteria such as:

• Applications

• Cloud Connector Groups

• Locations (and Sub-locations)

• Workload Groups

Whether the private applications are existing App Segments or brand-new additions, these workload-specific Access Policies can combine multiple criteria. For our “Production K8S Servers,” you might create a policy that includes the Applications AND the Workload Groups criteria. You can further refine access by adding a Location, ensuring only Cloud Connectors in a specific VPC or VNET match and allow traffic.

Image 7: Zscaler Private Access Policy using Workload Groups:

Why Does This Matter?

Public cloud environments are dynamic and often too complex for traditional network-based identification. You might have hundreds or thousands of VPCs or VNETs scattered across various regions, accounts, subscriptions, and projects. Enforcing granular, Zero Trust policies based on IP addresses and CIDRs just doesn’t scale. Using workload tags and attributes simplifies policy creation, maintenance, and enforcement.

Of course, this is a journey. Some organizations will continue using traditional network constructs for a while. But the future is in policies that align more closely with the logical identity of a workload rather than its place in the network.

Next Steps

Now that you know how Zscaler can discover and apply tags and attributes to policies, what should you do next? Here are five recommendations to get started:

1. Review and update your organization’s tagging strategy to ensure it supports future needs.

2. Implement controls in your cloud platforms to enforce consistent tagging.

3. Contact your Zscaler account team for a demo, deep dive, or test drive of these capabilities.

4. Schedule an architecture workshop with your Zscaler team to align with Zero Trust networking principles.

5. Identify initial workloads and policies where tags & attributes can provide immediate value.

By embracing tags and attributes in your policies, you’re taking another step toward a more scalable, flexible, and Zero Trust-aligned future—without getting bogged down in the complexity of ever-changing network constructs.