From 2e93520ade65be4ea2909cbb207a0a4b12107dd5 Mon Sep 17 00:00:00 2001 From: David Karlsson <35727626+dvdksn@users.noreply.github.com> Date: Thu, 4 Jun 2026 10:48:32 +0200 Subject: [PATCH 1/4] sbx: document sign-in enforcement for sandboxes 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) --- _vale/config/vocabularies/Docker/accept.txt | 3 + .../manuals/ai/sandboxes/governance/_index.md | 8 + .../governance/sign-in-enforcement.md | 297 ++++++++++++++++++ .../manuals/ai/sandboxes/security/_index.md | 15 +- 4 files changed, 316 insertions(+), 7 deletions(-) create mode 100644 content/manuals/ai/sandboxes/governance/sign-in-enforcement.md diff --git a/_vale/config/vocabularies/Docker/accept.txt b/_vale/config/vocabularies/Docker/accept.txt index 6a3bd9f76f5f..a3db8920f6f3 100644 --- a/_vale/config/vocabularies/Docker/accept.txt +++ b/_vale/config/vocabularies/Docker/accept.txt @@ -11,6 +11,7 @@ Aleksandrov Awaitility Amazon Anchore +Ansible Apple Artifactory armhf @@ -127,6 +128,7 @@ JavaScript JetBrains JFrog JUnit +Kandji Kata Keycloak Kerberos @@ -157,6 +159,7 @@ minikube misconfiguration [Mm]ixins? monorepos? +Mosyle musl MySQL nameserver diff --git a/content/manuals/ai/sandboxes/governance/_index.md b/content/manuals/ai/sandboxes/governance/_index.md index 599cba0d153b..f56277193c7e 100644 --- a/content/manuals/ai/sandboxes/governance/_index.md +++ b/content/manuals/ai/sandboxes/governance/_index.md @@ -19,6 +19,12 @@ uniformly across every sandbox in the organization. When organization governance is active, it replaces local policy entirely: local `sbx policy` rules are no longer evaluated. See [Organization policy](org.md). +Alongside this access-control policy, admins can require developers to sign in +as members of their organization before using sandboxes at all. +[Sign-in enforcement](sign-in-enforcement.md) is deployed through endpoint +management and ensures developers can't bypass organization policy by using a +personal account. + > [!NOTE] > Organization governance is available on a separate paid subscription. > [Contact Docker Sales](https://www.docker.com/products/ai-governance/#contact-sales) @@ -32,6 +38,8 @@ rules are no longer evaluated. See [Organization policy](org.md). machine with the `sbx policy` CLI - [Organization policy](org.md): centrally manage sandbox policies across your organization from the Admin Console +- [Sign-in enforcement](sign-in-enforcement.md): require developers to sign in + as organization members, enforced through endpoint management - [Monitoring](monitoring.md): inspect active rules and monitor sandbox network traffic with `sbx policy ls` and `sbx policy log` - [API reference](/reference/api/ai-governance/): manage org policies diff --git a/content/manuals/ai/sandboxes/governance/sign-in-enforcement.md b/content/manuals/ai/sandboxes/governance/sign-in-enforcement.md new file mode 100644 index 000000000000..0c0f348c04ca --- /dev/null +++ b/content/manuals/ai/sandboxes/governance/sign-in-enforcement.md @@ -0,0 +1,297 @@ +--- +title: Sign-in enforcement +linkTitle: Sign-in enforcement +weight: 35 +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 Hub 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] +> 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. + +## 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 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 + 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. If the revocation fails, for example due to a keychain error, + the user is instructed to run `sbx logout` manually. + +`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 applies at login time only. There's no per-command or per-request +check. A few key consequences follow from this: + +- **Fail-closed.** If the Docker Hub API is unreachable or returns an error, + login is denied. Users can't bypass enforcement by going offline. +- **Already signed-in users aren't affected immediately.** If a user was signed + in before the configuration was deployed, they keep their session until it + ends. To re-trigger the check, they run `sbx login` again. +- **Automatic sign-in is also checked.** If a user's Docker session expires + while they use the CLI from an interactive terminal, the CLI starts the + sign-in flow automatically, and the enforcement check runs against that + sign-in the same way it does for an explicit `sbx login`. + +> [!NOTE] +> A denied user is signed out, so they can't run `sbx ls` or `sbx rm` to clean +> up existing sandboxes until they sign 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 Hub 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, Mosyle, Kandji, Intune, or +Fleet, 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 + + + + + PayloadContent + + + PayloadType + com.apple.ManagedClient.preferences + PayloadVersion + 1 + PayloadIdentifier + com.docker.sbx.policy + PayloadUUID + + PayloadEnabled + + PayloadDisplayName + Docker Sandboxes Policy + PayloadContent + + com.docker.sbx + + Forced + + + mcx_preference_settings + + allowedOrgs + + acme-corp + + adminEmail + it-security@acme-corp.com + adminURL + https://acme-corp.atlassian.net/servicedesk/it + adminName + ACME IT Security + + + + + + + + + +``` + +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" >}} + +On Windows, the configuration is the registry key +`HKLM\SOFTWARE\Policies\Docker\SBX`. The `HKLM\SOFTWARE\Policies\` hive is +writable only by administrators. + +Deploy it through Group Policy, Intune, or any endpoint management tool that can +write registry values. + +| 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. + +> [!NOTE] +> Linux enforcement is weaker than macOS and Windows because users with sudo +> access can modify or delete the file. This is an industry-wide limitation for +> developer workstations. + +{{< /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/): + the equivalent control for Docker Desktop diff --git a/content/manuals/ai/sandboxes/security/_index.md b/content/manuals/ai/sandboxes/security/_index.md index 52f94bba1e51..50919e94faf4 100644 --- a/content/manuals/ai/sandboxes/security/_index.md +++ b/content/manuals/ai/sandboxes/security/_index.md @@ -88,13 +88,14 @@ see the full list of active rules, and remove entries you don't need. See ## 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 replace local rules, which are no longer evaluated. - -See [Organization policy](../governance/org.md) for details. +On a single developer's machine, security and policy are configured locally — +for example, network and filesystem rules set with `sbx policy`. Admins can +move these controls to the organization level so that security, policy, and +access apply consistently across every developer's sandboxes, rather than +depending on local configuration. + +See [Governance](../governance/) for the controls available to organization +admins. ## Learn more From 5e0fab7cc32ba00b7b007725b1780d27c2a74b84 Mon Sep 17 00:00:00 2001 From: David Karlsson <35727626+dvdksn@users.noreply.github.com> Date: Thu, 4 Jun 2026 10:53:56 +0200 Subject: [PATCH 2/4] Fix broken link to Docker Desktop enforce sign-in page 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) --- content/manuals/ai/sandboxes/governance/sign-in-enforcement.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/manuals/ai/sandboxes/governance/sign-in-enforcement.md b/content/manuals/ai/sandboxes/governance/sign-in-enforcement.md index 0c0f348c04ca..75cd3eb42ee5 100644 --- a/content/manuals/ai/sandboxes/governance/sign-in-enforcement.md +++ b/content/manuals/ai/sandboxes/governance/sign-in-enforcement.md @@ -293,5 +293,5 @@ For access, contact ACME IT Security: 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/): +- [Enforce sign-in for Docker Desktop](/manuals/enterprise/security/enforce-sign-in/_index.md): the equivalent control for Docker Desktop From c0144267db31ffec4534a869b2698187270cef11 Mon Sep 17 00:00:00 2001 From: David Karlsson <35727626+dvdksn@users.noreply.github.com> Date: Thu, 4 Jun 2026 13:04:22 +0200 Subject: [PATCH 3/4] sbx: address review feedback on sign-in enforcement - 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) --- .../governance/sign-in-enforcement.md | 24 +++++++++---------- 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/content/manuals/ai/sandboxes/governance/sign-in-enforcement.md b/content/manuals/ai/sandboxes/governance/sign-in-enforcement.md index 75cd3eb42ee5..e6f84c21fc4b 100644 --- a/content/manuals/ai/sandboxes/governance/sign-in-enforcement.md +++ b/content/manuals/ai/sandboxes/governance/sign-in-enforcement.md @@ -1,7 +1,7 @@ --- title: Sign-in enforcement linkTitle: Sign-in enforcement -weight: 35 +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 --- @@ -42,17 +42,17 @@ 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 -check. A few key consequences follow from this: - -- **Fail-closed.** If the Docker Hub API is unreachable or returns an error, - login is denied. Users can't bypass enforcement by going offline. -- **Already signed-in users aren't affected immediately.** If a user was signed - in before the configuration was deployed, they keep their session until it - ends. To re-trigger the check, they run `sbx login` again. -- **Automatic sign-in is also checked.** If a user's Docker session expires - while they use the CLI from an interactive terminal, the CLI starts the - sign-in flow automatically, and the enforcement check runs against that - sign-in the same way it does for an explicit `sbx login`. +check. This has a few key consequences: + +- Enforcement is fail-closed. If the Docker Hub API is unreachable or returns + an error, login is denied. Users can't bypass enforcement by going offline. +- Users who are already signed in aren't affected immediately. If a user was + signed in before the configuration was deployed, they keep their session + until it ends. To re-trigger the check, they run `sbx login` again. +- Automatic sign-in is also checked. If a user's Docker session expires while + they use the CLI from an interactive terminal, the CLI starts the sign-in + flow automatically, and the enforcement check runs against that sign-in the + same way it does for an explicit `sbx login`. > [!NOTE] > A denied user is signed out, so they can't run `sbx ls` or `sbx rm` to clean From 769e4cfac04e5004296e935bfb2ab6f9ad70b341 Mon Sep 17 00:00:00 2001 From: David Karlsson <35727626+dvdksn@users.noreply.github.com> Date: Thu, 4 Jun 2026 16:18:06 +0200 Subject: [PATCH 4/4] sbx: apply feature-owner review feedback on sign-in enforcement - 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) --- _vale/config/vocabularies/Docker/accept.txt | 2 - .../governance/sign-in-enforcement.md | 62 +++++-------------- 2 files changed, 17 insertions(+), 47 deletions(-) diff --git a/_vale/config/vocabularies/Docker/accept.txt b/_vale/config/vocabularies/Docker/accept.txt index a3db8920f6f3..86288dfcea54 100644 --- a/_vale/config/vocabularies/Docker/accept.txt +++ b/_vale/config/vocabularies/Docker/accept.txt @@ -128,7 +128,6 @@ JavaScript JetBrains JFrog JUnit -Kandji Kata Keycloak Kerberos @@ -159,7 +158,6 @@ minikube misconfiguration [Mm]ixins? monorepos? -Mosyle musl MySQL nameserver diff --git a/content/manuals/ai/sandboxes/governance/sign-in-enforcement.md b/content/manuals/ai/sandboxes/governance/sign-in-enforcement.md index e6f84c21fc4b..c783266f842c 100644 --- a/content/manuals/ai/sandboxes/governance/sign-in-enforcement.md +++ b/content/manuals/ai/sandboxes/governance/sign-in-enforcement.md @@ -7,7 +7,7 @@ keywords: docker sandboxes, sign-in enforcement, organization enforcement, sbx l --- Sign-in enforcement restricts Docker Sandboxes to users who are members of -specific Docker Hub organizations. An administrator deploys an enforcement +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. @@ -17,47 +17,28 @@ bypass organization [governance policies](org.md). Sign-in enforcement closes that gap at the endpoint, where users can't override it. > [!NOTE] -> Sandbox organization governance is available on a separate paid -> subscription. +> Sign-in enforcement is part of Docker's AI Governance offering. > [Contact Docker Sales](https://www.docker.com/products/ai-governance/#contact-sales) -> to request access. +> 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 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 + 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. If the revocation fails, for example due to a keychain error, - the user is instructed to run `sbx logout` manually. + 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 applies at login time only. There's no per-command or per-request -check. This has a few key consequences: - -- Enforcement is fail-closed. If the Docker Hub API is unreachable or returns - an error, login is denied. Users can't bypass enforcement by going offline. -- Users who are already signed in aren't affected immediately. If a user was - signed in before the configuration was deployed, they keep their session - until it ends. To re-trigger the check, they run `sbx login` again. -- Automatic sign-in is also checked. If a user's Docker session expires while - they use the CLI from an interactive terminal, the CLI starts the sign-in - flow automatically, and the enforcement check runs against that sign-in the - same way it does for an explicit `sbx login`. - -> [!NOTE] -> A denied user is signed out, so they can't run `sbx ls` or `sbx rm` to clean -> up existing sandboxes until they sign in with an allowed account. - ## Enforcement configuration All platforms express the same logical schema. The canonical JSON @@ -72,12 +53,12 @@ representation: } ``` -| Field | Type | Required | Description | -| ------------- | --------------- | -------- | ------------------------------------------------------------------------------------------------------- | -| `allowedOrgs` | list of strings | Yes | Docker Hub 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. | +| 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. @@ -96,10 +77,10 @@ platform reads it from a native location that ordinary users can't modify. 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 -Fleet, 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. +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: @@ -176,10 +157,6 @@ settings in the same domain are ignored. {{< /tab >}} {{< tab name="Windows" >}} -On Windows, the configuration is the registry key -`HKLM\SOFTWARE\Policies\Docker\SBX`. The `HKLM\SOFTWARE\Policies\` hive is -writable only by administrators. - Deploy it through Group Policy, Intune, or any endpoint management tool that can write registry values. @@ -249,11 +226,6 @@ 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. -> [!NOTE] -> Linux enforcement is weaker than macOS and Windows because users with sudo -> access can modify or delete the file. This is an industry-wide limitation for -> developer workstations. - {{< /tab >}} {{< /tabs >}}