zpa-create-access-policy-rule

What this skill does

# ZPA: Create Access Policy Rule

## Keywords

access policy, access rule, allow rule, deny rule, zpa policy, scim group policy, saml policy, platform restriction, country restriction, posture check, require approval, zero trust policy, conditional access

## Overview

Create ZPA access policy rules that control who can access private applications. Access policies use the v2 condition format and support a rich set of condition types: identity-based (SAML/SCIM), device-based (platform, posture, Chrome Enterprise), network-based (trusted networks, country codes), and risk-based (ZIA risk factors).

**Use this skill when:** An administrator asks to create an access policy rule, grant or deny application access based on user identity, device posture, location, or any combination of conditions.

---

## Condition Object Type Reference

Each condition block must contain a **single object type**. Multiple condition blocks are ANDed together. Within a condition block, multiple operands or entry_values are ORed.

### Value-Based Object Types (use `values`)

| Object Type | Description | Values |
|---|---|---|
| `APP` | Application segments | Application segment IDs |
| `APP_GROUP` | Segment groups | Segment group IDs |
| `CLIENT_TYPE` | Client connector type | `zpn_client_type_zapp`, `zpn_client_type_exporter`, `zpn_client_type_machine_tunnel`, `zpn_client_type_browser_isolation`, `zpn_client_type_ip_anchoring`, `zpn_client_type_edge_connector`, `zpn_client_type_branch_connector`, `zpn_client_type_zapp_partner` |
| `MACHINE_GRP` | Machine groups | Machine group IDs |
| `LOCATION` | Locations | Location IDs |
| `EDGE_CONNECTOR_GROUP` | Edge connector groups | Edge connector group IDs |
| `BRANCH_CONNECTOR_GROUP` | Branch connector groups | Branch connector group IDs |

### Entry-Values Object Types (use `entry_values` with `lhs`/`rhs`)

| Object Type | LHS | RHS |
|---|---|---|
| `SAML` | SAML attribute ID | Attribute value to match (email, group name, etc.) |
| `SCIM` | SCIM attribute header ID | Attribute value to match |
| `SCIM_GROUP` | Identity Provider ID | SCIM group ID |
| `PLATFORM` | `linux`, `android`, `ios`, `mac`, `windows` | `"true"` or `"false"` |
| `COUNTRY_CODE` | ISO 3166 Alpha-2 code (`US`, `CA`, `GB`) | `"true"` or `"false"` |
| `POSTURE` | Posture profile `posture_udid` | `"true"` or `"false"` |
| `TRUSTED_NETWORK` | Trusted network `network_id` | `"true"` or `"false"` |
| `RISK_FACTOR_TYPE` | `ZIA` | `UNKNOWN`, `LOW`, `MEDIUM`, `HIGH`, `CRITICAL` |
| `CHROME_ENTERPRISE` | `managed` | `"true"` or `"false"` |

### Action Types

| Action | Description |
|---|---|
| `ALLOW` | Permit access |
| `DENY` | Block access |
| `REQUIRE_APPROVAL` | Require explicit approval before access |

---

## Workflow

### Step 0: Identify the Rule Class (baseline alignment)

Reference: ZPA Baseline Recommendations v1.0 §Access Policy Construction (A–H). Before building conditions, identify which rule class this fits — that determines **where** the rule belongs in the policy order and **which** conditions are mandatory.

| Order | Class | Action | Mandatory criteria | Notes |
|---|---|---|---|---|
| 1 | **A. Deception** (if licensed) | `ALLOW` | Predefined criteria | Tenant feature — auto-provisioned. Do **not** modify the default rule. |
| 2 | **B. Machine Tunnel allow** | `ALLOW` | `CLIENT_TYPE = zpn_client_type_machine_tunnel` + `APP` (specific) + minimum `POSTURE` | For AD DCs, SCCM, patch services. |
| 3 | **B'. Machine Tunnel block-rest** | `DENY` | `CLIENT_TYPE = zpn_client_type_machine_tunnel` | Stops machine traffic from inheriting user rules. |
| 4 | **C. Contractor allow** | `ALLOW` | `SCIM_GROUP` (Contractors) + `APP` + `CLIENT_TYPE` + `POSTURE` | Tightly scoped to approved apps only. |
| 5 | **C'. Contractor block-rest** | `DENY` | `SCIM_GROUP` (Contractors) | Prevents contractor inheritance of employee rules. |
| 6 | **D. Posture remediation allow** | `ALLOW` | `APP` (remediation segment) + `CLIENT_TYPE` | Lets non-compliant devices reach the remediation app only. |
| 7 + N | **D'. Posture block per-OS** | `DENY` | `POSTURE` (failed) + `PLATFORM` (Windows / macOS / iOS / Android / Linux) | **One rule per OS** — see "Per-OS posture gotcha" below. |
| Mid | **E. Critical app allow** | `ALLOW` | `SCIM_GROUP` + `APP` (crown-jewel) + `CLIENT_TYPE` (ZCC only) + `POSTURE` | Apply optional extra posture checks (cert, registry). |
| Mid | **E'. Critical app block-rest** | `DENY` | `APP` (crown-jewel) only | Defense-in-depth even though E only allows approved users. |
| After E | **F. Standard internal apps** | `ALLOW` | `SCIM_GROUP` (employees) + `APP` + `CLIENT_TYPE` | Baseline access for non-sensitive apps. |
| Near bottom | **G. Discovery wildcard catch-all** | `ALLOW` | `APP` (wildcard discovery segment) + `SCIM_GROUP` | Discovery only — never above critical apps. |
| **Bottom** | **H. Block-All explicit** | `DENY` | None — match all | Improves logging and audit clarity beyond ZPA's implicit deny. |

#### Per-OS posture gotcha

Defining a posture-block rule for only Windows leaves macOS, iOS, Android, and Linux **implicitly allowed** even when their device posture has failed. The doc is explicit about this on page 30: create one block rule per OS in use, each with its own `POSTURE` and `PLATFORM` criteria. This is the #1 posture-enforcement mistake.

#### When NOT to use this skill

- Building a baseline policy from scratch (multiple classes at once) — defer to a future bulk-build skill, or chain calls to this skill once per class.
- Auditing policy alignment — use the `audit-baseline-compliance` skill.

---

### Step 1: Gather Requirements

Ask the administrator:

**Required:**

- Rule name
- Action: `ALLOW`, `DENY`, or `REQUIRE_APPROVAL`
- What conditions determine access (identity, platform, location, etc.)

**Optional:**

- Description
- Which application segments or segment groups to scope to
- App connector group IDs or server group IDs

---

### Step 2: Look Up Identity Attributes

If the rule uses identity-based conditions (SAML, SCIM, SCIM_GROUP), look up the required IDs first.

**For SCIM groups:**

```text
get_zpa_scim_group(search="<group_name>")
```text

Note both the SCIM group ID (used as `rhs`) and the Identity Provider ID (used as `lhs`).

**For SAML attributes:**

```text
get_zpa_saml_attribute(search="<attribute_name>")
```text

Note the SAML attribute ID (used as `lhs`). The `rhs` is the value to match (e.g., an email address or group name string).

**For SCIM attributes:**

```text
get_zpa_scim_attribute(search="<attribute_name>")
```text

**For segment groups (APP_GROUP):**

```text
zpa_list_segment_groups()
```text

**For posture profiles:**

```text
get_zpa_posture_profile(search="<profile_name>")
```text

Note the `posture_udid` value (used as `lhs`).

**For trusted networks:**

```text
get_zpa_trusted_network(search="<network_name>")
```text

Note the `network_id` value (used as `lhs`).

---

### Step 3: Build the Conditions Payload

Conditions use a list of dictionaries. Each dictionary represents one condition block with an `operator` and `operands`. **Separate condition blocks for each object type.**

**Format:**

```json
[
  {
    "operator": "OR",
    "operands": [
      {
        "object_type": "<OBJECT_TYPE>",
        "values": ["<id1>", "<id2>"]
      }
    ]
  },
  {
    "operator": "OR",
    "operands": [
      {
        "object_type": "<OBJECT_TYPE>",
        "entry_values": [
          {"lhs": "<lhs_value>", "rhs": "<rhs_value>"}
        ]
      }
    ]
  }
]
```text

**Rules:**

- Each condition block contains **one object type only**
- Multiple condition blocks are **ANDed** together (all must match)
- Within a block, multiple `entry_values` or multiple `values` are **ORed** (any can match)
- Value-based types (`APP`, `APP_GROUP`, `CLIENT_TYPE`, etc.) use `values`
- Entry-based types (`SAML`, `SCIM_GROUP`, `PLATFORM`, etc.) use `entry_values`

---

### Step 4: Create the Rule

```text
zpa_create_access_policy_