Zscaler Private Access (ZPA)
Connect Zscaler Private Access to RAD Security and query application segments, App Connectors and access policy rules.
RAD Security connects directly to the ZPA API with an API key and imports three objects into three data types: application segments (which private applications are exposed, and how), App Connectors (the brokers in your environment, their health and versions) and access policy rules (who may reach what).
Read-only integration. RAD only lists ZPA configuration. It never changes segments, connectors or policy.
Early access. This integration is enabled on request. Ask your RAD Security contact to turn it on for your workspace.
Prerequisites
- A ZPA tenant on the classic ZPA Admin Portal. Tenants on ZIdentity / OneAPI are not yet supported.
- Permission to create API keys in the ZPA Admin Portal
- A RAD Security workspace with integration permissions
What RAD stores
| Object | RAD data type | One row per | Refreshed |
|---|---|---|---|
| Application segments | zscaler_zpa_application_segments | segment | every 4 hours |
| App Connectors | zscaler_zpa_app_connectors | connector | every 4 hours |
| Access policy rules | zscaler_zpa_access_policy_rules | rule | every 4 hours |
- Application segments: domains, TCP and UDP port ranges (as
from-to), segment group, server groups, bypass type, health reporting, CNAME, IP anchoring, double encryption, ZIA inspection, microtenant, created and modified times - App Connectors: connector group, control-channel status, current vs expected version, upgrade status, platform and OS, private and public IP, location, last broker connect and disconnect, provisioning key, microtenant
- Access policy rules: action, rule order, priority, disabled flag, the rule operator, the conditions, the server and connector groups, who modified it and when
Reading a rule's conditions
A rule's conditions are stored flattened, one array entry per operand, with the arrays index-aligned: entry i of condition_object_types, condition_lhs, condition_rhs and condition_names is one operand, and condition_indexes[i] names the condition it belongs to (with that condition's operator and negation in condition_operators[i] and condition_negated[i]). That keeps every rule filterable — for example, every rule that names a given SCIM group — while still letting you rebuild its logic.
Step 1: Create an API key in ZPA
Open the API keys page
In the ZPA Admin Portal open Configuration & Control > Public API > API Keys. The page also shows your Customer ID (tenant ID).
Create a key with a read-only role
Select Add API Key, name it for example RAD Security, and give it a read-only role. RAD never changes ZPA configuration.
Copy the Client ID and Secret
ZPA shows the Client Secret only once, when the key is created. Copy it with the Client ID.
Step 2: Configure in RAD Security
Open Data Sources > Integrations > Secure Access, add Zscaler Private Access and fill in the fields.
| Field | Value |
|---|---|
| Cloud | PRODUCTION (config.private.zscaler.com), ZPATWO, BETA, GOV, GOVUS or PREVIEW |
| Customer ID | Your ZPA tenant ID, from the API Keys page |
| Client ID | The API key's Client ID |
| Client secret | The API key's secret |
RAD only calls the API host of the cloud you pick; the host is never built from free text.
Once the status shows Connected, the first pass reads all three lists.
Reading the data
Every pass re-reads all three lists in full every 4 hours, every row stamped with the time the pass started. A segment, connector or rule deleted in ZPA stops being rewritten and drops out of windowed reads; the default view shows the last 24 hours.
To find outdated connectors, filter zscaler_zpa_app_connectors where current_version differs from expected_version. For disconnected ones, filter on control_channel_status.