This content has been machine translated dynamically.
Dieser Inhalt ist eine maschinelle Übersetzung, die dynamisch erstellt wurde. (Haftungsausschluss)
Cet article a été traduit automatiquement de manière dynamique. (Clause de non responsabilité)
Este artículo lo ha traducido una máquina de forma dinámica. (Aviso legal)
此内容已经过机器动态翻译。 放弃
このコンテンツは動的に機械翻訳されています。免責事項
이 콘텐츠는 동적으로 기계 번역되었습니다. 책임 부인
Este texto foi traduzido automaticamente. (Aviso legal)
Questo contenuto è stato tradotto dinamicamente con traduzione automatica.(Esclusione di responsabilità))
This article has been machine translated.
Dieser Artikel wurde maschinell übersetzt. (Haftungsausschluss)
Ce article a été traduit automatiquement. (Clause de non responsabilité)
Este artículo ha sido traducido automáticamente. (Aviso legal)
この記事は機械翻訳されています.免責事項
이 기사는 기계 번역되었습니다.책임 부인
Este artigo foi traduzido automaticamente.(Aviso legal)
这篇文章已经过机器翻译.放弃
Questo articolo è stato tradotto automaticamente.(Esclusione di responsabilità))
Translation failed!
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. |
Related information
Share
Share
This Preview product documentation is Citrix Confidential.
You agree to hold this documentation confidential pursuant to the terms of your Citrix Beta/Tech Preview Agreement.
The development, release and timing of any features or functionality described in the Preview documentation remains at our sole discretion and are subject to change without notice or consultation.
The documentation is for informational purposes only and is not a commitment, promise or legal obligation to deliver any material, code or functionality and should not be relied upon in making Citrix product purchase decisions.
If you do not agree, select I DO NOT AGREE to exit.