docker/docs
1
0
Fork 0
mirror of https://github.com/docker/docs.git synced 2026-10-25 06:09:46 +03:00
Code Activity

docs: document sbx organization governance

Browse Source 
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Signed-off-by: David Karlsson <35727626+dvdksn@users.noreply.github.com>
This commit is contained in:
David Karlsson
2026-05-11 15:28:40 +02:00
parent c0aa985ff8
commit 6f2dc86699
8 changed files with 226 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
content/manuals/ai/sandboxes/_index.md
View File

@@ -18,6 +18,11 @@ sandbox gets its own Docker daemon, filesystem, and network — the agent can
build containers, install packages, and modify files without touching your host
system.
Organization admins can
[centrally manage sandbox network and filesystem policies](security/governance.md)
from the Docker Admin Console, so the same rules apply uniformly across every
developer's machine. Available on a separate paid subscription.
## Get started
Install the `sbx` CLI and sign in:

20
content/manuals/ai/sandboxes/faq.md
View File

@@ -15,14 +15,28 @@ Signing in gives each sandbox a verified identity, which lets Docker:
- **Tie sandboxes to a real person.** Governance matters when agents can build
containers, install packages, and push code. Your Docker identity is the
anchor.
- **Enable team features down the road.** Shared environments, org-level
policies, audit logs. These all need a concept of "who," and building that in
later would be worse for everyone.
- **Enable team features.** Team-scale features like
[organization governance](security/governance.md), shared environments, and
audit logs need a concept of "who," and adding that later would be worse for
everyone.
- **Authenticate against Docker infrastructure.** Sandboxes pull images, run
daemons, and talk to Docker services. A Docker account makes that seamless.
Your Docker account email is only used for authentication, not marketing.
## Can I enforce sandbox policies across my organization?
Yes. Admins can centrally manage network and filesystem policies from the
Docker Admin Console. Rules defined there apply to every sandbox in the
organization and take precedence over local rules set with `sbx policy`.
Admins can optionally delegate specific rule types back to local control so
developers can add additional allow rules.
See [Organization governance](security/governance.md). This feature requires
a separate paid subscription —
[contact Docker Sales](https://www.docker.com/products/ai-governance/#contact-sales)
to get started.
## Does the CLI collect telemetry?
The `sbx` CLI collects basic usage data about CLI invocations:

14
content/manuals/ai/sandboxes/security/_index.md
View File

@@ -81,6 +81,18 @@ See [Workspace trust](workspace/).
see the full list of active rules, and remove entries you don't need. See
[Default security posture](defaults/).
## Organization-wide control
On a single developer's machine, network and filesystem policies are
configured locally with `sbx policy`. Admins can also centrally define those
policies in the Docker Admin Console. When organization governance is active,
the centrally defined rules apply uniformly across every sandbox in the
organization and take precedence over local rules. Admins can optionally
delegate specific rule types back to local control so developers can add
additional allow rules.
See [Organization governance](governance/) for details.
## Learn more
- [Isolation layers](isolation/): how hypervisor, network, Docker, and
@@ -89,4 +101,6 @@ see the full list of active rules, and remove entries you don't need. See
blocks
- [Credentials](credentials/): how to provide and manage API keys
- [Policies](policy/): how to customize network access rules
- [Organization governance](governance/): centrally manage policies across
an organization
- [Workspace trust](workspace/): what to review after an agent session

4
content/manuals/ai/sandboxes/security/defaults.md
View File

@@ -19,7 +19,9 @@ ICMP) are blocked at the network layer. Traffic to private IP ranges, loopback
addresses, and link-local addresses is also blocked.
Run `sbx policy ls` to see the active allow rules for your installation. To
customize network access, see [Policies](policy.md).
customize network access, see [Policies](policy.md). If your organization
manages sandbox policies centrally, those rules apply on top of the defaults
described here. See [Organization governance](governance.md).
## Workspace defaults

154
content/manuals/ai/sandboxes/security/governance.md Normal file
View File

@@ -0,0 +1,154 @@
---
title: Organization governance
linkTitle: Org governance
weight: 35
description: Centrally manage sandbox network and filesystem policies for your organization.
keywords: docker sandboxes, governance, organization policy, AI governance, admin console, network access, filesystem access
---
> [!NOTE]
> Sandbox organization governance is available on a separate paid
> subscription.
> [Contact Docker Sales](https://www.docker.com/products/ai-governance/#contact-sales)
> to request access.
{{< summary-bar feature_name="Docker Sandboxes sbx" >}}
This page covers how to configure organization policies in the Docker Admin
Console under AI governance settings. For local sandbox policies that
individual users configure on their own machine, see [Policies](policy.md).
Sandbox network and filesystem policies defined in the
[Docker Admin Console](https://app.docker.com/admin) apply uniformly to every
sandbox in the organization. Rules are enforced across all developers'
machines, take precedence over local `sbx policy` rules, and can't be
overridden by individual users. Admins can optionally
[delegate](#delegate-rules-to-local-policy) specific rule types back to local
control so developers can add additional allow rules.
## Network policies
### Configuring org-level network rules
Define network allow and deny rules in the Admin Console under
**AI governance > Network access**. Each rule takes a network target (domain,
wildcard, or CIDR range) and an action (allow or deny). You can add multiple
entries at once, one per line.
Rules support exact domains (`example.com`), wildcard subdomains
(`*.example.com`), and optional port suffixes (`example.com:443`).
`example.com` doesn't match subdomains, and `*.example.com` doesn't match
the root domain. Specify both to cover both.
### Delegate rules to local policy
When organization governance is active, local rules are ignored by default —
only the organization policy is in effect. Admins can delegate a rule type
back to local policy by turning on the **User defined** setting for that
rule type in AI governance settings. Turning the setting on delegates the
rule type: local `sbx policy` rules of that type are evaluated alongside
organization rules, letting users add hosts to the allowlist from their own
machine.
If a rule type isn't delegated, local rules of that type still appear in
`sbx policy ls` but with an `inactive` status and a note that the
organization hasn't delegated the rule type to local policy:
```console
$ sbx policy ls
NAME TYPE ORIGIN DECISION STATUS RESOURCES
balanced-dev network local allow inactive — corporate policy takes precedence and does api.anthropic.com
not delegate this rule type to local policy.
allow AI services network remote allow active api.anthropic.com
api.openai.com
allow Docker services network remote allow active *.docker.com
*.docker.io
```
Organization rules show up with `remote` in the `ORIGIN` column.
Delegated local rules can expand access for domains the organization hasn't
explicitly denied, but can't override organization-level deny rules. This
applies to exact matches and wildcard matches alike; if the organization denies
`*.example.com`, a local allow for `api.example.com` has no effect because the
org-level wildcard deny covers it.
For example, given an organization policy that allows `api.anthropic.com`
and denies `*.corp.internal`:
- `sbx policy allow network api.example.com` — works, because the
organization hasn't denied `api.example.com`
- `sbx policy allow network build.corp.internal` — no effect, because the
organization denies `*.corp.internal`
#### Blocked values in delegated rules
To prevent overly broad rules from undermining the organization's policy,
certain catch-all values are blocked in delegated local rules:
- Domain patterns: `*`, `**`, `*.com`, `**.com`, `*.*`, `**.**`
- CIDR ranges: `0.0.0.0/0`, `::/0`
Scoped wildcards like `*.example.com` are still allowed. If a user attempts
to use a blocked value, `sbx policy` returns an error immediately.
## Filesystem policies
Filesystem policies control which host paths a sandbox can mount as
workspaces. By default, sandboxes can mount any directory the user has
access to.
Admins can restrict which paths are mountable by defining filesystem allow
and deny rules in the Admin Console under **AI governance > Filesystem
access**. Each rule takes a path pattern and an action (allow or deny).
> [!CAUTION]
> Use `**` (double wildcard) rather than `*` (single wildcard) when writing
> path patterns to match path segments recursively. A single `*` only matches
> within a single path segment. For example, `~/**` matches all paths under
> the user's home directory, whereas `~/*` matches only paths directly
> under `~`.
## Precedence
Within any layer, deny rules beat allow rules. If a domain matches both, it's
blocked regardless of specificity. Outbound traffic is blocked unless a rule
allows it.
When organization governance is active, local rules are not evaluated. Only
organization rules set in the Admin Console determine what is allowed or
denied. Organization-level denials can't be overridden locally.
If the admin [delegates](#delegate-rules-to-local-policy) a rule type to
local policy by turning on the **User defined** setting, local rules of
that type are also evaluated alongside organization rules. Delegated local
rules can expand access for domains the organization hasn't explicitly
denied, but can't override organization-level denials.
The same model applies to filesystem policies: organization-level rules take
precedence over local behavior.
To unblock a domain, identify where the deny rule comes from. For local
rules, remove it with `sbx policy rm`. For organization-level rules, update
the rule in the Admin Console.
## Troubleshooting
### Policy changes not taking effect
After updating organization policies in the Admin Console, changes take up
to 5 minutes to propagate to developer machines. To apply changes
immediately, users can run `sbx policy reset`, which stops the daemon and
forces it to pull the latest organization policies on the next `sbx`
command.
> [!WARNING]
> `sbx policy reset` deletes all locally configured policy rules. The command
> prompts for confirmation before proceeding.
### Sandbox cannot mount workspace
If a sandbox fails to mount with a `mount policy denied` error, verify that
the filesystem allow rule in the Admin Console uses `**` rather than `*`. A
single `*` doesn't match across directory separators.

13
content/manuals/ai/sandboxes/security/policy.md
View File

@@ -13,6 +13,10 @@ other. A policy system controls what a sandbox can access over the network.
Use the `sbx policy` command to configure network access rules. Rules apply
to all sandboxes on the machine.
If your organization manages sandbox policies centrally, organization rules
take precedence over the local rules described on this page. See
[Organization governance](governance.md).
## Network policies
The only way traffic can leave a sandbox is through an HTTP/HTTPS proxy on
@@ -47,6 +51,11 @@ Choose a default network policy:
You can change your effective policy at any time using `sbx policy allow` and
`sbx policy deny`, or start over by running `sbx policy reset`.
> [!NOTE]
> If your organization manages sandbox policies centrally, organization rules
> take precedence over the policy you select here. See
> [Organization governance](governance.md).
### Non-interactive environments
In non-interactive environments such as CI pipelines or headless servers, the
@@ -207,6 +216,10 @@ regardless of specificity.
To unblock a domain, find the deny rule with `sbx policy ls` and remove it
with `sbx policy rm`.
If your organization manages sandbox policies centrally, organization rules
take precedence and local rules are not evaluated unless the admin delegates
that rule type. See [Organization governance](governance.md).
## Troubleshooting
### Policy changes not taking effect

4
content/manuals/ai/sandboxes/troubleshooting.md
View File

@@ -52,6 +52,10 @@ To allow all outbound traffic instead:
$ sbx policy allow network "**"
```
If `sbx policy allow` doesn't unblock the request, your organization may
manage sandbox policies centrally and take precedence over local rules. See
[Organization governance](security/governance.md).
## SSH and other non-HTTP connections fail
Non-HTTP TCP connections like SSH can be allowed by adding a policy rule for

16
content/manuals/ai/sandboxes/usage.md
View File

@@ -371,6 +371,22 @@ the host service. For example, to verify connectivity from a sandbox shell:
$ curl http://host.docker.internal:11434
```
## Rolling out to a team
When rolling sandboxes out across a team, two features handle different
needs:
- [Custom templates and kits](customize/) let you package reusable agent
configurations, MCP servers, base images, and per-project policies. Every
developer pulls them down with their workspace.
- [Organization governance](security/governance.md) lets admins define
network and filesystem rules in the Docker Admin Console. The rules apply
across every developer's sandboxes and take precedence over local policy.
Available on a separate paid subscription.
Customization gives developers shared starting points. Governance gives
admins centralized enforcement.
## What persists
While a sandbox exists, installed packages, Docker images, configuration