[VIDEO] ZPA Workflow

Assuming that Cloud Connector has been instantiated and traffic directed through it, we can now add support for Zscaler Private Access. This use case is growing in popularity as organizations seek to depart from legacy VPN technologies to interconnect cloud and on-premise workloads. Cloud Connector integrates with ZPA by proxying workload traffic through synthetic IP addresses and forged DNS responses to workload queries. As traffic is directed through the Cloud Connector, it is proxied through the nearest ZPA Broker which, in turn, sends this traffic to the destination App Connector that will service this traffic.

In this video, we’ll explore:

[0:00 to 1:20] Overview of ZPA with Cloud Connector
[1:20 to 3:24] Prerequisites and Cloud Connector interaction with DNS
[3:24 to 5:13] Configuring ZPA Access Policy and Client Forwarding Policy
[5:13 to 6:21] Key Takeaways

Transcript

Hello, my name is Aaron and I’m one of the Principal Technical Product Specialists for Zscaler Cloud Workload Protection.

In this video, we’ll discuss how Zscaler Private Access can be leveraged to secure cloud workloads.

Assuming that Cloud Connector has been instantiated and you’ve adjusted routing to direct traffic through it, we can now add support for Zscaler Private Access. Be sure to check out the AWS and Azure provisioning videos for help in provisioning Cloud Connector, if necessary. This use case is growing in popularity as organizations seek to depart from legacy VPN technologies to interconnect cloud and on-premise workloads. An important consideration with Cloud Connector is that it is designed to facilitate outbound workload traffic towards a remote destination. When the destination is in a customer-controlled location (such as another Region of the same Cloud Service Provider, an entirely different Cloud Service Provider, or even an on-premise data center), we must consider how this traffic ingresses into the remote facility. We do this using the Zscaler App Connector appliance. More specifically, App Connector VMs will sit adjacent to the remote workloads they provide access to. In many cases, this means that Cloud Connector and App Connector will sit side-by-side to provide both inbound and outbound connectivity to the cloud.

In the interest of time, this video will not focus on the deployment of App Connector and will assume that these appliances have already been deployed. You can verify this in your ZPA Dashboard by browsing Administration > App Connectors and ensuring that your appliance is deployed and connected.

Likewise, when Cloud Connector is deployed, it is automatically added to your ZPA portal as well. You can verify this by navigating to Administration > Cloud Connector. Any deployed Cloud Connectors should appear in this output, along with their associated Cloud Connector Group.

As a next step, review the App Segments configured within your ZPA portal. You can do this from Administration > App Segments. This list of App Segments, and their associated criteria, is what Cloud Connector will download and use to identify outbound cloud traffic that requires redirection to the ZPA service. Creating new App Segments is not the focus of this video, so please check out the Zscaler Help Portal for more information, should this step not be completed already.

Finally, we need to ensure that Cloud Connector is properly set up to forward ZPA traffic. Remember, Cloud Connector focuses on outbound traffic from the cloud. To do this for ZPA traffic, Cloud Connector intercepts and proxies DNS requests. In essence, cloud workloads send their DNS request for ZPA-based App Segments to their configured DNS server, which presumably, crosses over the Cloud Connector. This DNS request is then validated against the downloaded list of App Segments that the Cloud Connector downloaded. If a match is found, the Cloud Connector responds back to the requesting workload with a synthetic IP address. The cloud workload then begins to send its traffic to this IP address, which is hosted on the Cloud Connector, and on into the ZPA fabric. You will need to ensure that the synthetic IP space used for this proxied traffic is routed to the Cloud Connector. As such, you may need to add a route in your AWS or Azure infrastructure if there is no Default Route that accomplishes this automatically. For more information on DNS interception, DNS policies, synthetic IP addressing, and the like, check out the accompanying videos on Gateway Configuration, Forwarding Policy, and AWS and Azure DNS Setup for ZPA.

It should also be noted here that IP-based App Segments obviously do not require DNS redirection, so these segments rely purely on routing through the Cloud Connector.

As mentioned in previous videos, for ZPA customers, Cloud Connector automatically builds Forwarding Policy for ZPA. You can review this pre-built policy from the Forwarding > Traffic Forwarding menu of the Cloud Connector portal.

Now that we’ve verified the basics, the final step is to return to the ZPA portal to review our Access Policies and Client Forwarding Policies.

Put simply, our Access Policies (if present) need to be adjusted to ensure that cloud workloads are allowed to send traffic into the ZPA fabric for certain App Segments. Navigating to Administration > Access Policy, you can review the existing policies. If existing Access Policies exist to define user access, they can be adjusted to incorporate cloud workloads. However, we recommend that new Access Policies be created to define cloud workload access to App Segments. This is because cloud workloads generally don’t have user attributes tied to their traffic and, as such, attributes like SCIM and SAML cannot be used to restrict access. Instead, we can use Client Type and Cloud Connector Group as our match criteria to permit or deny traffic towards the App Segment.

Likewise, Client Forwarding Policies can be manipulated to determine whether or not the Cloud Connector should even forward traffic into the ZPA fabric. By default, all traffic from all clients (whether cloud or user) that matches a ZPA App Segment and is permitted by Access Policy is forwarded into the ZPA fabric. Depending on the organizational policy, this may or may not be desired. For instance, in use-cases that invoke Source IP Anchoring, the Client Forwarding Policy may need to be adjusted to allow certain traffic types to bypass ZPA initially. Similarly, for hybrid-cloud environments where infrastructure like Active Directory spans across multiple cloud and on-premise destinations, you may decide to allow this traffic to bypass ZPA and be forwarded natively into the cloud. In most cases, the default Client Forwarding Policy will suffice for Cloud Connector deployments. But, it’s good to know that you can manipulate the logic here that Cloud Connector will use to either forward traffic into ZPA or allow the traffic to bypass.

– Cloud Connector appliances automatically register their cloud Locations (VPC and VNet) that they serve within the Cloud Connector and ZPA dashboards

– To facilitate ZPA traffic, Cloud Connector intercepts and proxies cloud workload traffic. This is primarily accomplished by manipulating DNS queries in the cloud

– Cloud Connector appliances automatically download ZPA App Segments and, by default, will have a pre-built policy to begin forwarding traffic towards these segments

– ZPA Access Policy can be used to permit or deny access to specific App Segments. Since cloud workloads generally don’t have user attributes attached to their traffic, Client Type and Cloud Connector Group is used as the match criteria for the policy

– Client Forwarding Policy can be used to influence whether or not the Cloud Connector allows cloud workload traffic to bypass ZPA, even if there’s an App Segment match. This is particularly useful in use-cases that require Source IP Anchoring (SIPA), where traffic bypasses ZPA initially

5 Likes