Access policies
An access policy links one or more sources to one or more destinations within a single provider. An access policy is many-to-many: every source endpoint can reach every destination
endpoint on the access policy. This lets you express a single policy like "these four regional gateways can reach any connector in these two locations and any connector attached to
the edge-device model" without having to create one access policy per pair.
Access policies are scoped to a provider, not to a specific location or customer, so they can cut across a provider's internal topology.
A destination can also be a single application — the finest-grained target. Where a connector, location, or connector model destination reaches every application hosted under it, an application destination reaches exactly that one application's services. Applications are a destination-only target; sources are always connectors, locations, or connector models.
:::note Targeting an application directly as a destination (the applicationId endpoint field and the destinationApplicationId
filter, below) is an API capability. The console's access policy builder does not yet surface it — in the UI, destinations are built from connectors, locations, and connector
models.
:::
Fields
| Field | Description | Example |
|---|---|---|
id | Unique access policy identifier assigned at create time. Stable for the life of the access policy | a1b2c3d4-e5f6-4789-9abc-def012345678 |
providerId | Parent provider — set on create, immutable. Every endpoint on the access policy must belong to this provider | 8b14d4f9-3a52-4b91-8e7c-d3e44b5c1f2a |
name | Display name, unique within the provider | east-to-west |
zitiName | Computed Ziti service-policy name, formatted <providerId>|<name>|dial. Response-only; never accepted as input | 8b14d4f9-3a52-4b91-8e7c-d3e44b5c1f2a|east-to-west|dial |
description | Optional free-form text describing the access policy | Replication path between regional gateways |
sources | Source endpoints (at least one). Each entry sets exactly one of connectorId, locationId, or connectorModelId — see Endpoint shape | |
destinations | Destination endpoints (at least one). Same shape as sources, and may additionally set applicationId | |
enabled | Runtime state, response-only boolean: true when the access policy is projected onto the network, false when a location or customer it touches is disabled | true |
createdBy, createdAt, updatedAt, deletedAt, deletedBy | Standard lifecycle fields |
Endpoint shape
Each entry in sources and destinations is a single endpoint. Each endpoint must specify exactly one of:
| Endpoint field | Meaning | Sides | Example |
|---|---|---|---|
connectorId | Exactly this connector | source, destination | f1e2d3c4-b5a6-4789-9012-3456789abcde |
locationId | Any connector at this location | source, destination | 2c4d6e8f-1a3b-4c5d-9e0f-1a2b3c4d5e6f |
connectorModelId | Any connector currently attached to this connector model | source, destination | 9a8b7c6d-5e4f-4321-9876-543210fedcba |
applicationId | Exactly this application's services | destination only | 7c6d5e4f-3a2b-4c1d-8e9f-0a1b2c3d4e5f |
Setting zero or more than one of these on a single endpoint is rejected as 400 Bad Request. applicationId is only valid on a destination — a source endpoint that sets it is
rejected. Duplicate endpoints within the same sources or destinations list are de-duplicated server-side, so listing the same application (or connector/location/model) twice,
or listing an application and a connector that hosts it, is accepted and collapsed rather than rejected.
A connectorModelId endpoint is a live, rule-based membership: if another connector is later attached to or detached from the model — whether by being created and deleted, or by
having its model attachment changed — the access policy's effective reach updates accordingly. You don't need to edit the access
policy. A connector switched onto a different model leaves the old model's reach and joins the new one's in the same operation.
An applicationId endpoint targets one application directly. It reaches the network only while that application is enabled and the connector hosting it is reachable — disabling
the application, or disabling the location or customer of its connector, prunes just that target from the policy (the same live behavior described in
Enabled state and pausing); deleting the application removes it from the policy entirely. Note that changing a connector's model attachment clears
every application on it (see Attaching a model), so an applicationId endpoint pointed at any of them loses its target. Target the
connector or the model itself when you want the policy to follow whatever is hosted there rather than one specific application.
What gets provisioned
Creating an access policy provisions the underlying network link that lets every source reach every destination. Deleting the access policy tears that link down. Editing the
sources or destinations lists on an access policy reshapes the provisioned link to match.
Enabled state and pausing
An access policy is stored durably and is always returned by the API, but it's only projected onto the network while every location and customer it touches is enabled. This is
reflected in the response-only enabled boolean:
enabled: true: The underlying network policies are in place and traffic can flow.enabled: false: A location or customer referenced by one of the access policy's endpoints is currently disabled, so the network policies have been removed. The access policy definition is retained and keeps appearing in lists and lookups; it isn't deleted.
Disabling a location or customer pauses every access policy that touches it, on either the source or the destination side, and tears down that access policy's network policies.
Re-enabling restores them, but only once all the locations and customers an access policy touches are enabled again. An access policy spanning two disabled locations stays
enabled: false until both are re-enabled.
A destination that targets an application follows the same rule through the connector that hosts it: disabling that application, or disabling the location or customer of its
connector, prunes the application's target from every policy that references it, and re-enabling restores it. A policy whose only live destination was that application becomes
enabled: false until the application is reachable again.
Creating an access policy that already touches a disabled location or customer is allowed: it's created with enabled: false and is projected onto the network automatically once everything it touches is enabled.
Scope is always a provider
Access policies are top-level resources at /access-policies. The owning provider is set with the providerId field in the request body on create, and is available as a query
filter when listing. Every endpoint (connector, location, connector model, or application) referenced by a source or destination must belong to that same provider; cross-provider
references are rejected.
Endpoints can sit anywhere in the provider's tree. A Connector or location attached directly to the provider (see Locations on the provider) is a valid source or destination, and it can be combined freely with connectors and locations under any of the provider's customers on the same access policy. A single access policy can, for example, originate from a provider-owned gateway and fan out to every customer location, or vice versa.
Filtering
The list endpoint accepts id, name, and providerId, plus deleted and deletedAt. deleted defaults to false, so deleted access policies are left out unless you ask for
them with deleted=true; deletedAt takes a range and matches on when the deletion happened. Unlike the other resources, there is no createdAt/updatedAt filtering here, and
name matches exactly rather than by wildcard.
On top of those, the find endpoint supports filtering by any endpoint that participates on either side. An access policy matches if its source (or destination) list intersects the given ids:
sourceConnectorId,sourceLocationId,sourceConnectorModelIddestinationConnectorId,destinationLocationId,destinationConnectorModelId,destinationApplicationId
destinationApplicationId has no source counterpart, because applications are a destination-only target. Each parameter accepts multiple values. Use these to answer questions like
"what does this connector originate?", "what reaches this location?", "which access policies fan out to the edge-device model?", or "which access policies grant access to this
application?".