sbx: document sign-in enforcement for sandboxes #25263
+286
−7
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -11,6 +11,7 @@ Aleksandrov | |
| Awaitility | ||
| Amazon | ||
| Anchore | ||
| Ansible | ||
| Apple | ||
| Artifactory | ||
| armhf | ||
|
|
||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,269 @@ | ||
| --- | ||
| title: Sign-in enforcement | ||
| linkTitle: Sign-in enforcement | ||
| weight: 22 | ||
| description: Require Docker Sandboxes users to sign in as members of your organization, enforced through endpoint management. | ||
| keywords: docker sandboxes, sign-in enforcement, organization enforcement, sbx login, MDM, configuration profile, registry key, allowedOrgs | ||
| --- | ||
|
|
||
| Sign-in enforcement restricts Docker Sandboxes to users who are members of | ||
| specific Docker organizations. An administrator deploys an enforcement | ||
| configuration to managed endpoints, and `sbx login` verifies organization | ||
| membership after the user authenticates. If the check fails, credentials are | ||
| immediately revoked and the user can't run sandboxes. | ||
|
|
||
| Without this enforcement, a developer can sign in with a personal account and | ||
| bypass organization [governance policies](org.md). Sign-in enforcement closes | ||
| that gap at the endpoint, where users can't override it. | ||
|
|
||
| > [!NOTE] | ||
| > Sign-in enforcement is part of Docker's AI Governance offering. | ||
| > [Contact Docker Sales](https://www.docker.com/products/ai-governance/#contact-sales) | ||
| > to learn more. | ||
|
|
||
| ## How it works | ||
|
|
||
| 1. An administrator deploys an enforcement configuration to managed endpoints | ||
| through MDM, Group Policy, or configuration management, specifying one or | ||
| more allowed Docker organization slugs. | ||
| 2. When a user runs `sbx login`, they authenticate with Docker. Credentials | ||
| are saved temporarily, then Docker Sandboxes calls the Docker API to | ||
| verify organization membership. | ||
| 3. If the user belongs to at least one allowed organization, login succeeds and | ||
| 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. | ||
|
|
||
| `sbx login` and `sbx logout` always run regardless of organization membership. | ||
| 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 configuration | ||
|
|
||
| All platforms express the same logical schema. The canonical JSON | ||
| representation: | ||
|
|
||
| ```json | ||
| { | ||
| "allowedOrgs": ["docker", "acme-corp"], | ||
| "adminEmail": "it-security@acme-corp.com", | ||
| "adminURL": "https://acme-corp.atlassian.net/servicedesk/it", | ||
| "adminName": "ACME IT Security Team" | ||
| } | ||
| ``` | ||
|
|
||
| | Field | Type | Required | Description | | ||
| | ------------- | --------------- | -------- | --------------------------------------------------------------------------------------------------- | | ||
| | `allowedOrgs` | list of strings | Yes | Docker organization slugs. The user must be a member of at least one. Matching is case-insensitive. | | ||
| | `adminName` | string | No | Administrator or team display name shown in the denial message. | | ||
| | `adminEmail` | string | No | Contact email shown in the denial message. | | ||
| | `adminURL` | string | No | Help desk or access-request URL shown in the denial message. | | ||
|
|
||
| If `allowedOrgs` is empty or missing, enforcement is inactive and any | ||
| authenticated user can use Docker Sandboxes. | ||
|
|
||
| The optional `adminName`, `adminEmail`, and `adminURL` fields give denied users | ||
| a path to resolution. Include the contact details your organization uses for | ||
| access requests. | ||
|
|
||
| ## Deploy the configuration | ||
|
|
||
| Use your existing endpoint management tooling to deploy the configuration. Each | ||
| platform reads it from a native location that ordinary users can't modify. | ||
|
|
||
| {{< tabs >}} | ||
| {{< tab name="macOS" >}} | ||
|
|
||
| On macOS, the configuration is a managed preferences domain, `com.docker.sbx`. | ||
|
|
||
| Deploy it through any MDM solution, such as Jamf or Intune, as a custom | ||
| configuration profile. MDM-deployed profiles take precedence over user-level | ||
| preferences and can only be removed by removing the device from MDM management, | ||
| so users can't override them. | ||
|
|
||
| The following `.mobileconfig` payload sets the allowed organization and admin | ||
| contact details: | ||
|
|
||
| ```xml | ||
| <?xml version="1.0" encoding="UTF-8"?> | ||
| <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" | ||
| "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> | ||
| <plist version="1.0"> | ||
| <dict> | ||
| <key>PayloadContent</key> | ||
| <array> | ||
| <dict> | ||
| <key>PayloadType</key> | ||
| <string>com.apple.ManagedClient.preferences</string> | ||
| <key>PayloadVersion</key> | ||
| <integer>1</integer> | ||
| <key>PayloadIdentifier</key> | ||
| <string>com.docker.sbx.policy</string> | ||
| <key>PayloadUUID</key> | ||
| <string><!-- generate a UUID --></string> | ||
|
dvdksn marked this conversation as resolved.
|
||
| <key>PayloadEnabled</key> | ||
| <true/> | ||
| <key>PayloadDisplayName</key> | ||
| <string>Docker Sandboxes Policy</string> | ||
| <key>PayloadContent</key> | ||
| <dict> | ||
| <key>com.docker.sbx</key> | ||
| <dict> | ||
| <key>Forced</key> | ||
| <array> | ||
| <dict> | ||
| <key>mcx_preference_settings</key> | ||
| <dict> | ||
| <key>allowedOrgs</key> | ||
| <array> | ||
| <string>acme-corp</string> | ||
| </array> | ||
| <key>adminEmail</key> | ||
| <string>it-security@acme-corp.com</string> | ||
| <key>adminURL</key> | ||
| <string>https://acme-corp.atlassian.net/servicedesk/it</string> | ||
| <key>adminName</key> | ||
| <string>ACME IT Security</string> | ||
| </dict> | ||
| </dict> | ||
| </array> | ||
| </dict> | ||
| </dict> | ||
| </dict> | ||
| </array> | ||
| </dict> | ||
| </plist> | ||
| ``` | ||
|
|
||
| To test the configuration locally without MDM, write to the user preferences | ||
| domain: | ||
|
|
||
| ```console | ||
| $ defaults write com.docker.sbx allowedOrgs -array "acme-corp" | ||
| $ defaults write com.docker.sbx adminEmail "it@acme.com" | ||
| ``` | ||
|
|
||
| To remove the test configuration: | ||
|
|
||
| ```console | ||
| $ defaults delete com.docker.sbx | ||
| ``` | ||
|
|
||
| `defaults write` uses the user preferences domain, not the managed-preferences | ||
| domain. On a managed device, the MDM profile is authoritative and user-level | ||
| settings in the same domain are ignored. | ||
|
|
||
| {{< /tab >}} | ||
| {{< tab name="Windows" >}} | ||
|
|
||
| Deploy it through Group Policy, Intune, or any endpoint management tool that can | ||
| write registry values. | ||
|
There was a problem hiding this comment. [MEDIUM] Windows tab omits the registry key path from deployment prose The macOS and Linux tabs both state the configuration path upfront in prose before showing the config. The Windows tab says "Deploy it through Group Policy, Intune, or any endpoint management tool that can write registry values" but never names the registry key path ( An IT admin configuring enforcement via Group Policy or Intune would need the registry path to set up the GPO template or Intune registry policy. Since the PowerShell block is framed as a local test rather than the primary deployment instruction, the path is easy to miss. Consider adding a sentence like: "Write the values to |
||
|
|
||
| | Value name | Type | Description | | ||
| | ------------- | -------------- | --------------------------------------------------- | | ||
| | `allowedOrgs` | `REG_MULTI_SZ` | Multi-string list, one organization slug per string | | ||
| | `adminName` | `REG_SZ` | Administrator or team name (optional) | | ||
| | `adminEmail` | `REG_SZ` | Contact email (optional) | | ||
| | `adminURL` | `REG_SZ` | Help desk URL (optional) | | ||
|
|
||
| To test the configuration locally, run the following in an elevated PowerShell | ||
| session. Use `New-ItemProperty` to create values with an explicit type; | ||
| `Set-ItemProperty` doesn't create new values. | ||
|
|
||
| ```powershell | ||
| New-Item -Path "HKLM:\SOFTWARE\Policies\Docker\SBX" -Force | ||
|
|
||
| New-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Docker\SBX" ` | ||
| -Name "allowedOrgs" -Value @("acme-corp") -PropertyType MultiString -Force | ||
| New-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Docker\SBX" ` | ||
| -Name "adminEmail" -Value "it@acme.com" -PropertyType String -Force | ||
| ``` | ||
|
|
||
| To remove the configuration: | ||
|
|
||
| ```powershell | ||
| Remove-Item -Path "HKLM:\SOFTWARE\Policies\Docker\SBX" -Recurse -Force | ||
| ``` | ||
|
|
||
| {{< /tab >}} | ||
| {{< tab name="Linux" >}} | ||
|
|
||
| On Linux, the configuration is a root-owned JSON file at | ||
| `/etc/docker-sbx/config.json`. | ||
|
|
||
| Deploy it through configuration management such as Ansible, Puppet, Chef, or | ||
| Salt. The file must be owned by root with `644` permissions. | ||
|
|
||
| ```json | ||
| { | ||
| "allowedOrgs": ["acme-corp"], | ||
| "adminEmail": "it-security@acme-corp.com", | ||
| "adminURL": "https://acme-corp.atlassian.net/servicedesk/it", | ||
| "adminName": "ACME IT Security" | ||
| } | ||
| ``` | ||
|
|
||
| To deploy and set ownership: | ||
|
|
||
| ```console | ||
| $ sudo mkdir -p /etc/docker-sbx | ||
| $ sudo tee /etc/docker-sbx/config.json <<'EOF' | ||
| {"allowedOrgs": ["acme-corp"], "adminEmail": "it@acme.com"} | ||
| EOF | ||
| $ sudo chown root:root /etc/docker-sbx/config.json | ||
| $ sudo chmod 644 /etc/docker-sbx/config.json | ||
| ``` | ||
|
|
||
| To remove the configuration: | ||
|
|
||
| ```console | ||
| $ sudo rm -f /etc/docker-sbx/config.json | ||
| ``` | ||
|
|
||
| The Linux loader fails closed if the file is a symlink, isn't a regular file, | ||
| isn't owned by root, or is writable by group or other. Any deviation is treated | ||
| as a configuration error and `sbx login` is denied with a descriptive message. | ||
| Deploying with the commands above passes these checks. | ||
|
|
||
| {{< /tab >}} | ||
| {{< /tabs >}} | ||
|
|
||
| ## Error messages | ||
|
|
||
| When a user signs in with an account that isn't a member of an allowed | ||
| organization, they're signed out and shown a denial message. Only the contact | ||
| fields you configure appear: if only `adminEmail` is set, the URL line is | ||
| omitted. | ||
|
|
||
| When no admin contact details are configured: | ||
|
|
||
| ```text | ||
| Access denied: Your administrator requires you to be logged into an account | ||
| that is a member of one of the following Docker organizations: | ||
| - acme-corp | ||
|
|
||
| Sign in with an account that belongs to one of these organizations, or | ||
| contact your administrator for access. | ||
| ``` | ||
|
|
||
| When admin contact details are configured: | ||
|
|
||
| ```text | ||
| Access denied: Your administrator requires you to be logged into an account | ||
| that is a member of one of the following Docker organizations: | ||
| - acme-corp | ||
|
|
||
| For access, contact ACME IT Security: | ||
| Email: it-security@acme-corp.com | ||
| URL: https://acme-corp.atlassian.net/servicedesk/it | ||
| ``` | ||
|
|
||
| ## Related pages | ||
|
|
||
| - [Organization policy](org.md): centrally manage sandbox network and | ||
| filesystem rules from the Docker Admin Console | ||
| - [Governance overview](_index.md): how local and organization governance fit | ||
| together | ||
| - [Enforce sign-in for Docker Desktop](/manuals/enterprise/security/enforce-sign-in/_index.md): | ||
| the equivalent control for Docker Desktop | ||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.