Product documentation
Citrix Secure Developer Spaces™
View PDF

Network policies

June 24, 2026
Contributed by: 
C T

Network policies let you control the outbound (egress) network traffic that workspaces are allowed to generate. With a network policy you can monitor where a workspace connects, restrict it to an approved set of domains and IP addresses, or deeply inspect its traffic — and surface every one of those events in the Audit dashboard.

This article walks through the full lifecycle of a network policy: understanding the policy types, creating a policy (in basic or expert mode), assigning and enforcing it across scopes, testing it, and monitoring its effect.

How network policies work

A network policy describes how a workspace is allowed to talk to the outside world. Every policy applies one of three behaviors to outgoing traffic:

  • Monitor — TCP traffic is allowed and logged without restriction. Use this when you want visibility into where a workspace connects without limiting it to an allow list. (As with every policy, non-DNS UDP traffic is still dropped — see the note below.)
  • Restrict — Traffic is blocked by default. Only the resources you allow — attached resources (such as repositories, SSH services, and HTTP services) plus the domains and IP addresses on the policy’s allow list — can be reached. The allow list is enforced on TCP traffic, which is routed through the egress proxy. UDP traffic (other than DNS, which is needed for name resolution) is dropped. Blocked requests are logged so you can see what was denied.
  • Inspect — TCP traffic content is inspected and reported, and UDP traffic is dropped. Use this when you need the deepest visibility into what a workspace sends.

Important:

The moment any network policy is attached to a workspace — even a monitor policy — the workspace’s outbound traffic is routed through the egress proxy, and all non-DNS UDP traffic is dropped. DNS (UDP/TCP port 53) keeps working because it is forwarded separately for name resolution. A workspace with no policy attached is not affected. Keep this in mind if your workloads rely on UDP (for example, some VPN, QUIC, or custom UDP-based protocols): those connections won’t work once a policy is attached, regardless of the policy’s behavior.

Note:

You configure monitor and restrict behavior when you create or edit a policy. Inspect is currently provided only through the built-in Inspect Traffic (default, expert) policy — you can apply it to workspaces, but you can’t author a new inspect policy in the policy editor.

Network policies are defined at three scope levels: platform, organization, and project. A policy defined at a higher scope can be applied — and optionally enforced — on every scope nested beneath it:

Scope Who manages it Typical use
Platform Platform administrators, Security Officers Baseline policy for the whole deployment
Organization Organization owners, Security Officers Policy for all projects in an organization
Project Project owners, Security Officers Policy for all workspaces in a project

You can’t define a policy at the workspace level. A workspace can only have an existing policy applied to it — selected from the policies defined at the platform, organization, or project scope.

Who can manage network policies

Creating, editing, selecting, and enforcing network policies — at any scope, including the workspace level — requires the Security::Manage permission. That permission belongs to:

  • Security Officers
  • Organization owners
  • Project owners (and any custom role granted Security::Manage access)

Standard developers and other project members can’t create, change, or assign network policies, even for their own workspaces. With the Security::Access permission they can view which policies apply (for example, through View summary), but the selection is read-only for them.

When a developer creates a personal workspace, its network policies are applied automatically from the project and platform settings: policies marked as required are enforced and locked, and other configured policies are applied as the workspace’s selected policies. The developer doesn’t choose them.

Two concepts govern how a policy reaches a workspace:

  • Applied — The policy is selected as the active policy for a scope or workspace.
  • Enforced — The policy is locked in for the current scope and every scope nested beneath it. When a parent scope enforces a policy, the lower scopes and their workspaces inherit it and can’t replace it.

Note: Restrict and inspect policies can cause some applications to stop working as expected, because they change what the workspace can reach. They are recommended for experienced administrators.

The default network policies

When a project is created, Secure Developer Spaces adds three ready-to-use policies so you don’t have to start from scratch.

Policy Behavior Blocks traffic? Use it when
Monitor Traffic (default) Monitor TCP allowed; non-DNS UDP dropped You want to log outgoing TCP traffic and generate audit events without restricting it to an allow list.
Restrict Traffic (default, expert) Restrict Yes You want to block all outbound traffic except attached resources and an approved allow list.
Inspect Traffic (default, expert) Inspect Partially You want to inspect TCP content and drop UDP traffic, reporting everything to the audit log. This behavior is available only as this built-in policy.

The Restrict Traffic default ships with a starter allow list that covers common developer package sources, so standard tooling keeps working. It includes domains such as:

  • *.ubuntu.com
  • *.nodesource.com, *.yarnpkg.com
  • *.npmjs.org, *.npm.im, *.npm.me, *.npm.red
  • python.org, *.pypi.org, *.pythonhosted.org
  • open-vsx.org
  • opensuse.org, sourceforge.net, virtualbox.org
  • *.windows.net

You can use these defaults as-is, duplicate them as a starting point, or create your own policies.

Where network policies are configured

Network policies appear in several places in the admin console, depending on the scope you manage:

  • Platform settings > Security settings > Network policy overview — A read-only summary of which policy is applied at each scope and whether it is enforced. Use it to audit your configuration and download a report.
  • Workspace settings > Network policy (at the platform, organization, or project level) — Where you create, edit, select, enforce, and test the policy for that scope.
  • A workspace’s Security settings > Network security (when you create or edit a workspace) — Where a project owner or Security Officer selects the policy for an individual workspace. The selection is read-only for users without the Security::Manage permission.

Create a network policy

You create and edit policies from a Workspace settings > Network policy page at the scope you manage (platform, organization, or project). You need the Security::Manage permission — see Who can manage network policies.

  1. Go to Workspace settings > Network policy for your scope.
  2. Select Create policy.
  3. Enter a Policy name and a Description. Both are required. Use a description that explains what the policy allows or blocks, so other administrators understand its intent.
  4. Choose how to configure the rest of the policy:
  5. (Optional) Select Test policy to validate the policy before you save it. See Test a policy.
  6. Save the policy.

The basic form and the expert YAML editor describe the same policy. You can switch between them with the Expert mode toggle while you work.

Configure a policy in basic mode

Basic mode gives you a guided form for the most common settings.

  1. Set Restrict traffic to selected resources:
    • Off — The policy monitors traffic. Everything is allowed and logged.
    • On — The policy blocks all outbound traffic except attached repositories and the resources on your allow list.
  2. If you turned restriction on, build the allow list:
    • Select Add domain to allow a domain. Optionally turn on Include subdomains to also allow every subdomain of that domain.
    • Select Add IP address to allow a single IPv4 address or a CIDR range (for example, 10.0.0.0/24).
  3. If your platform uses an external proxy, a custom endpoints via proxy section appears. Use it to list the domains and IP addresses that the workspace is allowed to reach through the proxy. This section is hidden when no external proxy is configured.
  4. Save the policy.

See Build the allow list for details on how domains and IP addresses are matched.

Configure a policy in expert mode

Expert mode replaces the form with a YAML editor, giving you full control over every field. Turn on the Expert mode toggle to use it.

Field reference

Field Type Required Description
name string Yes The policy name. Must not be empty.
description string Yes A human-readable description of what the policy does. Must not be empty.
restrictedTraffic boolean Yes true restricts outbound traffic to attached resources and the allow list. false monitors traffic without blocking.
whitelistedDomains list No Domains the workspace is allowed to reach. Each entry has a domain and an includeSubdomains flag.
whitelistedIps list No IPv4 addresses or CIDR ranges the workspace is allowed to reach.
customEndpointsEnabled boolean No Enables the custom-endpoints-via-proxy allow lists. Only relevant when the platform uses an external proxy.
customEndpointsViaProxyDomains list No Domains reachable through the external proxy. Used only when customEndpointsEnabled is true.
customEndpointsViaProxyIps list No IP addresses or CIDR ranges reachable through the external proxy. Used only when customEndpointsEnabled is true.

Each entry in whitelistedDomains and customEndpointsViaProxyDomains has this shape:

Field Type Description
domain string The domain to allow (for example, example.com).
includeSubdomains boolean When true, both the domain and all of its subdomains (*.domain) are allowed.

Example 

name: Backend services policy
description: Restrict workspaces to internal package mirrors and the corporate API.
restrictedTraffic: true
whitelistedDomains:
  - domain: pypi.internal.example.com
    includeSubdomains: false
  - domain: example.com
    includeSubdomains: true
whitelistedIps:
  - 10.0.0.0/24
  - 192.168.1.50
<!--NeedCopy-->

Note: When customEndpointsEnabled is false, the custom-endpoints lists are ignored and cleared. Only set those fields when an external proxy is in use.

Build the allow list

When a policy restricts traffic, the workspace can reach only:

  • Attached resources — Any resource attached to the workspace — repositories, SSH services, and HTTP services — is always reachable, so attached resources keep working without extra configuration.
  • Allowed domains — Every domain on the allow list.
  • Allowed IP addresses — Every IPv4 address or CIDR range on the allow list.

How domains are matched

  • A domain entry with Include subdomains turned off matches only that exact domain.
  • A domain entry with Include subdomains turned on matches both the domain itself and any subdomain. For example, example.com with subdomains enabled allows example.com and *.example.com (such as api.example.com).

How IP addresses are matched

Enter a single IPv4 address (for example, 192.168.1.50) or a CIDR range (for example, 10.0.0.0/24). The policy editor validates the format before you can save.

Assign and enforce a policy

Creating a policy doesn’t change any workspace on its own. You assign it to a scope, and optionally enforce it down the hierarchy.

  1. Go to Workspace settings > Network policy for the scope you manage.
  2. Select the policy you want to apply from the list of available policies.
  3. To lock the policy in for this scope and everything nested beneath it, turn on Enforce network policy. When enforcement is on:
    • The policy applies to all current and future workspaces in the scope.
    • Nested scopes (and their workspaces) inherit the policy and can’t replace it.
  4. Save your changes.

If you don’t enforce the policy, lower scopes and individual workspaces can still choose a different policy. Enforcement is what guarantees consistent behavior across an organization or project.

Select a policy for a workspace

A project owner or Security Officer can set the network policy for an individual workspace under Security settings > Network security when creating or editing the workspace. If a parent scope enforces a policy, that policy is inherited and the selection is locked.

Note: This requires the Security::Manage permission. Standard developers can’t change a workspace’s policy. When a developer creates a personal workspace, its policies are applied automatically from the project and platform settings — required policies are enforced and other configured policies are applied.

  1. In the workspace creation or edit flow, open Security settings.
  2. Under Network security, choose a policy. By default a workspace starts with No policy selected.
  3. Select View summary to review exactly what the policy allows or blocks before you apply it.
  4. Save the workspace.

Test a policy

Before you rely on a policy, test it to confirm it allows what you expect and blocks what you don’t.

  1. Open the policy in Workspace settings > Network policy.
  2. Select Test policy.
  3. In the test dialog, provide the destinations you want to check.
  4. Review the result to confirm whether each destination is allowed or blocked under the policy.

Testing is especially useful for restrict and inspect policies, where an incomplete allow list can break tooling inside the workspace.

Review the network policy overview

To audit your configuration across the whole deployment, go to Platform settings > Security settings > Network policy overview.

The overview shows, for the platform and each organization:

  • The applied policy at that scope.
  • The status — whether the policy is Enforced or Not enforced.

Select Download report to export the overview for record-keeping or review.

Monitor and troubleshoot

Every network policy behavior feeds the Audit dashboard, which is your primary tool for understanding and fixing policy effects.

  • Monitored traffic generates log events for all outgoing connections.
  • Restricted traffic logs every blocked request, so you can see exactly which destination was denied.
  • Inspected traffic reports inspected TCP content and dropped UDP traffic.

Find the traffic logs

Network events appear in the Audit dashboard for the project, in the Live system event log:

  1. Open Audit for the project. You need the Security::Access permission.
  2. Find the network events — for example, DNS requests showing the domain a workspace tried to reach.
  3. Select Filter to narrow the log by event type, severity, workspace, user, or date, or use the search bar to find a specific destination.
  4. Expand a row to see the event’s full details, including the description of what triggered it.

Use a monitor policy to build an allow list

A monitor-only policy is the recommended way to discover exactly what a workspace needs before you lock it down:

  1. Apply the Monitor Traffic policy (or any policy with restriction turned off) to the workspace.
  2. Use the workspace normally so its tools generate their usual network calls.
  3. In the audit log, review the network events to see which domains and IP addresses the workspace actually reached.
  4. Create a restrict policy and add those destinations to the allow list. See Build the allow list.
  5. Switch the workspace to the restrict policy. Any destination you missed now appears as a blocked request in the same audit log, so you can refine the allow list and repeat.

Tip: Attached resources (repositories, SSH services, and HTTP services) are always reachable under a restrict policy, so you don’t need to add them to the allow list.

Common issues

  • An application can’t reach a service it needs. The destination is probably missing from the allow list. Check the Audit dashboard for the blocked request, then add the domain or IP address to the policy. If the service uses subdomains, turn on Include subdomains.
  • A tool that uses UDP stops working after a policy is applied. Any attached network policy — monitor, restrict, or inspect — drops non-DNS UDP traffic by design. DNS still works, but other UDP-based protocols don’t. If a workload depends on UDP, it can’t run in a workspace that has a network policy attached.
  • A workspace ignores the policy you selected. A parent scope is likely enforcing a different policy, or the policy was applied automatically from project settings. Check the network policy overview to see which scope enforces the inherited policy. Only Security Officers, organization owners, and project owners can change a workspace’s policy.
Network policies
June 24, 2026
Contributed by: 
C T
June 24, 2026
Contributed by: 
C T

In this article

Site feedback | Your privacy choices footer linkYour Privacy Choices | Privacy and legal terms | Cookie preferences | Consent settings | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.