diff --git a/content/manuals/ai/sandboxes/security/policy.md b/content/manuals/ai/sandboxes/security/policy.md index 99132909e48..18d4d38d47e 100644 --- a/content/manuals/ai/sandboxes/security/policy.md +++ b/content/manuals/ai/sandboxes/security/policy.md @@ -1,75 +1,16 @@ --- title: Policies weight: 30 -description: Configure network access and filesystem rules for sandboxes. +description: Configure network access rules for sandboxes. --- {{< summary-bar feature_name="Docker Sandboxes sbx" >}} Sandboxes are [network-isolated](isolation.md) from your host and from each -other. A policy system controls what a sandbox can access — which external -hosts it can reach over the network, and which host paths it can mount as -workspaces. +other. A policy system controls what a sandbox can access over the network. -Policies can be set at two levels: - -- **Organization policies** {{< badge color=blue text="Limited Access" >}} — configured by admins in the - [Docker Admin Console](https://app.docker.com/admin) under AI governance - settings. These apply to all sandboxes across the organization. -- **Local policies** — configured by individual users with the `sbx policy` - command. These apply to all sandboxes on the local machine. - -If your organization has enabled governance, organization policies replace -local rules — local `sbx policy` rules are not evaluated unless an admin -also turns on the **User defined** setting. See [Precedence](#precedence) -for details. - -## Organization policies {tier="Limited Access"} - -> [!NOTE] -> Organization governance is a Limited Access feature. Contact your Docker -> account team to request access. - -Organization admins can centrally manage policies through the -[Docker Admin Console](https://app.docker.com/admin). Navigate to your -organization settings and enable **Manage AI governance**. - -Once enabled, the policies defined in the Admin Console apply to all -sandboxes across the organization. - -### Local extensions to organization policy - -When organization governance is active, local rules are ignored by default. -Admins can optionally let users extend the organization policy by turning on -the **User defined** setting in AI governance settings. When turned on, -local `sbx policy` rules are evaluated alongside organization rules, letting -users add hosts to the allowlist from their own machine using -`sbx policy allow network`. - -Local extensions 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 user-defined rules - -To prevent overly broad rules from undermining the organization's policy, -certain catch-all values are blocked in user-defined rules: - -- Domain patterns: `*`, `**`, `*.com`, `**.com`, `*.*`, `**.**` -- CIDR ranges: `0.0.0.0/0`, `::/0` - -Scoped wildcards like `*.example.com` are still allowed. If you attempt to -use a blocked value, `sbx policy` returns an error immediately. +Use the `sbx policy` command to configure network access rules. Rules apply +to all sandboxes on the machine. ## Network policies @@ -100,11 +41,6 @@ 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 AI governance policies, organization rules -> take precedence over the policy you select here. See -> [Organization policies](#organization-policies). - ### Non-interactive environments In non-interactive environments such as CI pipelines or headless servers, the @@ -126,10 +62,7 @@ allows it. The **Balanced** policy ships with a baseline allowlist covering AI p APIs, package managers, code hosts, container registries, and common cloud services. Run `sbx policy ls` to see the active rules for your installation. -Organization admins can modify or remove these defaults when configuring -[organization policies](#organization-policies). - -### Managing local rules +### Managing rules Use [`sbx policy allow`](/reference/cli/sbx/policy/allow/) and [`sbx policy deny`](/reference/cli/sbx/policy/deny/) to add network access @@ -194,16 +127,6 @@ $ sbx policy allow network "**" This lets agents install packages and call any external API without additional configuration. You can still deny specific hosts with `sbx policy deny`. -### Org-level rules {tier="Limited Access"} - -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. - -Organization-level rules use the same [wildcard syntax](#wildcard-syntax) as -local rules. - ### Wildcard syntax Rules support exact domains (`example.com`), wildcard subdomains @@ -263,50 +186,14 @@ $ sbx policy log my-sandbox Use `--limit N` to show only the last `N` entries, `--json` for machine-readable output, or `--type network` to filter by policy type. -## 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. - -### Org-level restrictions {tier="Limited Access"} - -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. - All outbound traffic is blocked by default unless an explicit rule allows it. -How rules are evaluated depends on whether organization governance is active. - -Without organization governance, local rules (`sbx policy`) are the only -rules evaluated against this default-deny baseline. - -With organization governance, local rules are not evaluated. Only -organization rules (Docker Admin Console) determine what is allowed or -denied. Organization-level denials can't be overridden locally. +If a domain matches both an allow and a deny rule, the deny rule wins +regardless of specificity. -If the admin turns on the **User defined** setting, local rules are also -evaluated alongside organization rules. 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, contact your -organization admin. +To unblock a domain, find the deny rule with `sbx policy ls` and remove it +with `sbx policy rm`. ## Troubleshooting @@ -314,11 +201,4 @@ organization admin. If policy changes aren't taking effect, run `sbx policy reset` to wipe the local policy store and restart the daemon. On next start, you are prompted to -choose a new network policy, and the latest organization policies are pulled if -governance is enabled. - -### Sandbox cannot mount workspace - -If a sandbox fails to mount with a `mount policy denied` error, verify that -the filesystem allow rule uses `**` rather than `*`. A single `*` doesn't -match across directory separators. +choose a new network policy.