zscaler v1.0.0

The pack names a reference, never a secret. Installing a pack registers capabilities and makes them governable; registration is not connectivity. The credential is created at the provider and held in the client's own secret manager under the reference the pack names, and deployment testing is still required to show the credential path works and cannot be bypassed.

Reference

secret-ref-zscaler-zia-session

Custody

customer_vault

Injection

header (Cookie)

A ZIA API session cookie, held in the client's own secret manager. The stored material must be the complete Cookie header value: 'JSESSIONID=' followed by the session id returned by the ZIA authenticatedSession call. Stated honestly, ZIA's legacy authentication is a derived session, not a static token: an external deployment process POSTs a JSON body containing an API-enabled admin's username, password and the tenant API key — obfuscated with Zscaler's documented timestamp-based obfuscation, which is obfuscation, not encryption — to /api/v1/authenticatedSession on the customer's ZIA cloud host, and stores the resulting session cookie under this reference. The three source values (username, password, API key) are separate secrets under their own vault references; the executor injects the stored cookie verbatim and performs no session lifecycle itself, so renewal ownership sits entirely with that external process. Sessions expire after inactivity and are invalidated by an explicit logout (DELETE /authenticatedSession); an expired or logged-out session fails closed. Rotating the API key or disabling the admin stops NEW session issuance, but an already-established session should be treated as valid until it expires or is logged out — stopping issuance is not session invalidation, so on suspicion the custody job must explicitly log out the session, not only rotate the key. Least privilege: use a dedicated API-only admin whose role permits exactly the registered scope (read-only administration for the reads; URL filtering configuration only where rule creation and activation are enabled), and never a full admin. The ZPA capabilities in this pack override this credential block with their own bearer-token reference (see their inject fields). ZPA legacy authentication per the retrieved vendor SDK documentation (2026-09-21) is OAuth2 client credentials: client_id and client_secret are issued in the ZPA console (Configuration & Control > Public API > API Keys), the customer id identifies the tenant (Administration > Company menu), and the ZPA cloud value selects the API gateway; the external custody job exchanges the client credentials for an access token at the tenant's ZPA gateway and stores the complete 'Bearer <token>' Authorization header value. The retrieved pages do not state the ZPA token's exact lifetime or whether deleting the API key invalidates already-issued tokens — confirm both against the ZPA console documentation before enabling and treat any captured token as live until expiry. Least privilege: a dedicated API key whose console role permits exactly the registered application-segment read/create scope, never a full admin. Executor hygiene: the cookie and the bearer value must live only in executor memory for the lifetime of a call, must never be written to logs, traces or diagnostics, and must not appear in crash dumps; a deployment that cannot meet that bar must not enable the pack.

• zscaler-zia-tenant (api, internal): https://zscaler-zia.invalid/api/v1
• zscaler-zpa-tenant (api, internal): https://zscaler-zpa.invalid/mgmtconfig/v1/admin/customers/CUSTOMER_ID

The endpoint hosts 'zscaler-zia.invalid' and 'zscaler-zpa.invalid' are reserved non-production placeholders (an RFC 2606 reserved TLD): substitute the customer's own ZIA cloud API host (zsapi.<cloud name> for the tenant's cloud) and ZPA gateway host before enabling, in every endpoint, in the resource locators and in every egress allowlist entry — the allowlist matches exactly, so all three must be substituted together, and substitution is a required deployment step. This pack registers the legacy ZIA session model honestly: ZIA API authentication is a session-cookie flow in which the client POSTs an admin username, password and the tenant's obfuscated API key to /api/v1/authenticatedSession and receives a session cookie; the stored credential is the resulting cookie value, minted and refreshed by an external custody job — see the credential note. ZIA configuration changes are staged per session and only take enforcement effect when activated: zia.config.activate applies ALL staged changes tenant-wide — including changes staged by other sessions and by console users — and is registered with the deploy action at the R3 floor. The ZPA capabilities override the pack credential: ZPA's API uses OAuth2 client-credentials bearer tokens, not the ZIA session cookie, so the ZPA capabilities name a separate reference and the Authorization header. Zscaler's newer Zidentity OneAPI framework (a single OAuth2 client across ZIA/ZPA) exists and is preferred by the vendor for migrated tenants; the retrieved vendor SDK documentation shows OneAPI is NOT only a credential change: it moves authentication to the Zidentity token endpoint (https://<vanity_domain>.zslogin.net/oauth2/v1/token) and serves the products from a different API base authority (api.<cloud_name>.zsapi.net) with its own path contract, so a migrated tenant must re-review authority, paths and credential wiring together rather than swapping only the credential reference. Documentation caveat: Zscaler's help site (help.zscaler.com) is JavaScript-gated and returned no readable content in this review; the pack was reviewed against the vendor-maintained official Zscaler Python SDK documentation listed in sources, which describes both the legacy session framework (username, password, obfuscated API key per cloud product) and the OneAPI OAuth2 framework. A completing review should re-check endpoint paths against help.zscaler.com for the tenant's product versions before this pack leaves draft. Documented exclusions — this pack does not register: any DELETE endpoint (URL filtering rule, firewall rule, URL category or application segment deletion — removing an enforcement rule can silently reopen blocked traffic, and deletion is not part of this pack), admin user, role and API-key management, PAC file management, ZPA connector provisioning or deletion, sandbox file submission (which sends customer files for analysis), sublocation and location VPN credential management, and ZIA DLP dictionary/policy management.

Draft review record dated 2026-09-21 · Reviewer: aaes-eng (an opaque id that resolves internally to the responsible reviewer)

• https://zscaler-sdk-python.readthedocs.io/en/latest/ (retrieved 2026-09-21)
• https://zscaler-sdk-python.readthedocs.io/en/latest/zs/zia/activate.html (retrieved 2026-09-21)
• https://zscaler-sdk-python.readthedocs.io/en/latest/zs/zpa/app_segments.html (retrieved 2026-09-21)

A pack review is not a vendor or examiner attestation. A retrieval date says when a source page was read; it does not by itself establish what the page said then. No pack is vendor-endorsed, and none has been connectivity-tested against a live vendor tenant.