sbx: document sign-in enforcement for sandboxes#25263
Conversation
Add an admin-facing guide for organization sign-in enforcement (G-6), deployed via endpoint management (macOS configuration profile, Windows registry, Linux config file). Cross-link from the governance overview and generalize the security page's organization-control section. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
✅ Deploy Preview for docsdocker ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Use the source-path form (_index.md) so Hugo resolves the internal link; the published-URL form left the /manuals prefix unstripped and failed the htmltest link check. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
| > [!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. |
There was a problem hiding this comment.
@smnovick assuming this is gated by the governance license - is that right?
There was a problem hiding this comment.
Technically is isn't - this feature will work regardless of whether a user has a license or not - that being said - I think we should just say this is part of the AI Governance offering.
There was a problem hiding this comment.
Done in 769e4cf — reworded the callout to "Sign-in enforcement is part of Docker's AI Governance offering" and dropped the "separate paid subscription / request access" framing.
- Remove bold "Term." lead-ins from the consequences list (STYLE.md reserves bold for UI elements) - Reorder the page before the API reference (weight 22, grouped with organization policy) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
| 1. An administrator deploys an enforcement configuration to managed endpoints | ||
| through MDM, Group Policy, or configuration management, specifying one or | ||
| more allowed Docker Hub organization slugs. | ||
| 2. When a user runs `sbx login`, they authenticate with Docker Hub. Credentials |
There was a problem hiding this comment.
Should we remove "Hub"? Might confuse people. Just say "authenticate with Docker"
There was a problem hiding this comment.
Done — changed to "authenticate with Docker". I also dropped "Hub" from the other organization references on the page (intro, step 1, and the allowedOrgs table row) so the terminology stays consistent.
| through MDM, Group Policy, or configuration management, specifying one or | ||
| more allowed Docker Hub organization slugs. | ||
| 2. When a user runs `sbx login`, they authenticate with Docker Hub. Credentials | ||
| are saved temporarily, then Docker Sandboxes calls the Docker Hub API to |
There was a problem hiding this comment.
Done — now "Docker API".
| the credentials are kept. | ||
| 4. If not, Docker Sandboxes immediately revokes the saved credentials and the | ||
| user receives an [error message](#error-messages) listing the required | ||
| organizations. If the revocation fails, for example due to a keychain error, |
There was a problem hiding this comment.
Remove the line about using logging out manually - I think this is something claude picked up on based on comments - not something we should document
There was a problem hiding this comment.
Removed in 769e4cf — dropped the "If the revocation fails... run sbx logout manually" sentence.
| Other commands require a valid signed-in session, so they fail after a denied | ||
| login until the user signs in with an allowed account. | ||
|
|
||
| Enforcement applies at login time only. There's no per-command or per-request |
There was a problem hiding this comment.
Removed — see the reply on the line-44 thread below.
| Other commands require a valid signed-in session, so they fail after a denied | ||
| login until the user signs in with an allowed account. | ||
|
|
||
| Enforcement applies at login time only. There's no per-command or per-request |
There was a problem hiding this comment.
Not sure we want to expose this. Actually we shoudl remove everything from line 44 through 60
There was a problem hiding this comment.
Done in 769e4cf — removed the entire block (login-time-only, fail-closed, the consequences bullets, and the sbx ls/sbx rm cleanup note).
|
|
||
| On macOS, the configuration is a managed preferences domain, `com.docker.sbx`. | ||
|
|
||
| Deploy it through any MDM solution, such as Jamf, Mosyle, Kandji, Intune, or |
There was a problem hiding this comment.
Some of these are pretty niche / odd - I would just say "Jamf or Intune"
There was a problem hiding this comment.
Done — trimmed to "such as Jamf or Intune" and removed the now-unused Mosyle/Kandji entries from the Vale vocabulary.
| {{< /tab >}} | ||
| {{< tab name="Windows" >}} | ||
|
|
||
| On Windows, the configuration is the registry key |
There was a problem hiding this comment.
Removed in 769e4cf — dropped the "On Windows, the configuration is the registry key..." intro sentence. Heads up: the path now appears only in the PowerShell commands here, while the macOS and Linux tabs still name their paths in prose. Happy to restore a one-line path mention for Windows, or trim mac/Linux too, for consistency — let me know which you prefer.
| {{< tab name="Windows" >}} | ||
|
|
||
| On Windows, the configuration is the registry key | ||
| `HKLM\SOFTWARE\Policies\Docker\SBX`. The `HKLM\SOFTWARE\Policies\` hive is |
There was a problem hiding this comment.
Removed together with line 179 (see reply there).
| as a configuration error and `sbx login` is denied with a descriptive message. | ||
| Deploying with the commands above passes these checks. | ||
|
|
||
| > [!NOTE] |
There was a problem hiding this comment.
Removed in 769e4cf — dropped the Linux weaker-enforcement note.
- Frame the feature as part of the AI Governance offering (not a separate paid subscription) - Drop "Hub" from organization/API references to avoid confusion - Remove the manual-logout fallback sentence - Remove the login-time-only / fail-closed / consequences section - Trim the MDM example list to Jamf and Intune (drop unused vocab terms) - Remove the Windows registry-path intro and the Linux weaker-enforcement note Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Summary
Adds an admin-facing guide for Docker Sandboxes organization sign-in enforcement: admins deploy an enforcement configuration via endpoint management (macOS configuration profile, Windows registry, Linux root-owned JSON file) specifying allowed Docker Hub org slugs, and
sbx loginverifies membership and revokes credentials on failure.New page
content/manuals/ai/sandboxes/governance/sign-in-enforcement.mdcovers how it works (login-time-only, fail-closed, auto-login behavior), the configuration schema, per-platform deployment, and error messages. Also cross-links from the governance overview and generalizes the security page's organization-control section so it makes a single point about admin-level controls rather than enumerating each feature.Learnings
sbxsign-in enforcement config is entirely endpoint/file-based (com.docker.sbxmanaged prefs,HKLM\SOFTWARE\Policies\Docker\SBX,/etc/docker-sbx/config.json) with no Admin Console UI — distinct from sandbox org policy (network/filesystem), which is Admin Console + API driven. Worth keeping these two admin mechanisms separate in the docs.Generated by Claude Code