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

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.

Public link

Please use the above public link if you want to share this noodl on another website.