Citrix SecurSpaces™

Network policies

Network policies control the outbound 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 inspect its traffic — and see every one of those events in the Audit dashboard.

This page explains the model. For the tasks, see:

Policy behaviors

Every policy applies one of three behaviors to outgoing traffic.

Behavior What it does
Monitor TCP traffic is allowed and logged without restriction. Use this to see where a workspace connects without limiting it to an allow list.
Restrict Traffic is blocked by default. Only attached resources and the domains and IP addresses on the allow list can be reached. Blocked requests are logged.
Inspect TCP traffic content is inspected and reported. Use this when you need the deepest visibility into what a workspace sends.

Note:

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

What happens when a policy is attached

Attaching any policy changes how the workspace reaches the network, regardless of which behavior the policy applies.

A workspace with a policy attached is labeled as hardened, and a Kubernetes NetworkPolicy then permits it to send traffic only to SecurSpaces service pods. All outbound traffic therefore goes through the SecurSpaces proxy service. DNS continues to work because it is served by a SecurSpaces service.

Important:

The moment any network policy is attached to a workspace — even a monitor policy — the workspace’s outbound traffic is routed through the SecurSpaces proxy service, and non-DNS UDP traffic is dropped. 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 stop working once a policy is attached, whatever the policy’s behavior.

Before you use restrict or inspect

Note:

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

Under an inspect policy, an application that reads certificates from a custom location inside the container is likely to fail. Check with your platform administrator before applying Inspect Traffic (default, expert) to a workspace that depends on one.

Scopes

Network policies are defined at three scope levels. 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 cannot 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.

Applied and enforced

Two concepts govern how a policy reaches a workspace.

Term Meaning
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. Lower scopes and their workspaces inherit it and cannot replace it.

Who can manage network policies

Creating, editing, selecting, and enforcing network policies requires the Security permission set to Manage. The Security permission has three levels: No Access, Access, and Manage.

Manage belongs to:

  • Security officers
  • Organization owners
  • Project owners, and any custom role granted the Manage level

Developers and other project members cannot create, change, or assign network policies, even for their own workspaces. With the Access level they can see 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 does not choose them.

The default policies

When a project is created, Citrix SecurSpaces™ adds three ready-to-use policies at project scope.

Policy Behavior Use it when
Monitor Traffic (default) Monitor You want to log outgoing TCP traffic and generate audit events without restricting it to an allow list.
Restrict Traffic (default, expert) Restrict You want to block all outbound traffic except attached resources and an approved allow list.
Inspect Traffic (default, expert) Inspect You want to inspect TCP content and report it to the audit log. This behavior is available only as this built-in policy.

Restrict Traffic (default, expert) ships with a starter allow list covering common developer package sources, so standard tooling keeps working:

  • *.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

Use these defaults as they are, duplicate them as a starting point, or create your own policies.

Where policies are configured

Location What you do there
Platform settings > Security settings > Network policy overview Review which policy is applied at each scope and whether it is enforced, and download a report. Read-only.
Workspace settings > Network policy, at platform, organization, or project level Create, edit, select, enforce, and test the policy for that scope.
A workspace’s Security settings > Network security Select the policy for an individual workspace. Read-only without the Manage level.