final checks

Author: aevesdocker

desktop/hardened-desktop/enhanced-container-isolation/faq.md

@@ -45,12 +45,12 @@ devices.
 Enhanced Container Isolation allows running advanced workloads, but denies the ability to perform
 kernel operations or access hardware devices.
 
-#### Does Enhanced Container Isolation restrict bind-mounts inside the container?
+#### Does Enhanced Container Isolation restrict bind mounts inside the container?
 
-Yes, it restricts bind-mounts of directories located in the Docker Desktop Linux
+Yes, it restricts bind mounts of directories located in the Docker Desktop Linux
 VM into the container.
 
-It does not restrict bind-mounts of your host machine files into the container,
+It does not restrict bind mounts of your host machine files into the container,
 as configured via Docker Desktop's **Settings** > **Resources** > **File Sharing**.
 
 #### Does Enhanced Container Isolation protect all containers launched with Docker Desktop?

desktop/hardened-desktop/enhanced-container-isolation/features-benefits.md

@@ -134,18 +134,18 @@ Finally, Docker build `--network=host` and Docker buildx entitlements
 (`network.host`, `security.insecure`) are not allowed. Builds that require these
 won't work properly.
 
-### Bind-Mount restrictions
+### Bind mount restrictions
 
 When Enhanced Container Isolation is enabled, Docker Desktop users can continue
-to bind-mount host directories into containers as configured via **Settings** >
-**Resources** > **File sharing**, but they are no longer allowed to bind-mount
+to bind mount host directories into containers as configured via **Settings** >
+**Resources** > **File sharing**, but they are no longer allowed to bind mount
 arbitrary Linux VM directories into containers.
 
 This prevents containers from modifying sensitive files inside the Docker
 Desktop Linux VM, files that can hold configurations for registry access
 management, proxies, docker engine configurations, and more.
 
-For example, the following bind-mount of the Docker Engine's configuration file
+For example, the following bind mount of the Docker Engine's configuration file
 (`/etc/docker/daemon.json` inside the Linux VM) into a container is restricted
 and therefore fails:
 
@@ -157,9 +157,9 @@ docker: Error response from daemon: failed to create shim task: OCI runtime crea
 In contrast, without Enhanced Container Isolation this mount works and gives the
 container full read and write access to the Docker Engine's configuration.
 
-Of course, bind-mounts of host files continue to work as usual. For example,
+Of course, bind mounts of host files continue to work as usual. For example,
 assuming a user configures Docker Desktop to file share her $HOME directory,
-she can bind-mount it into the container:
+she can bind mount it into the container:
 
 ```
 $ docker run -it --rm -v $HOME:/mnt alpine
@@ -168,7 +168,7 @@ $ docker run -it --rm -v $HOME:/mnt alpine
 
 > Note
 >
-> Enhanced Container Isolation won't allow bind-mounting the Docker socket
+> Enhanced Container Isolation won't allow bind mounting the Docker socket
 > (/var/run/docker.sock) into a container, as doing so essentially grants the
 > container control of Docker, thus breaking container isolation. Containers
 > that rely on this will not work with Enhanced Container Isolation enabled.
@@ -181,7 +181,7 @@ few highly sensitive system calls inside containers, such as `mount` and
 system calls can't use them to breach the container.
 
 For example, a container that has `CAP_SYS_ADMIN` (required to execute the
-`mount` system call) can't use that capability to change a read-only bind-mount
+`mount` system call) can't use that capability to change a read-only bind mount
 into a read-write mount:
 
 ```

desktop/hardened-desktop/enhanced-container-isolation/how-eci-works.md

@@ -40,10 +40,10 @@ mode or Rootless Docker. This is explained further below.
 Sysbox enhances container isolation by using techniques such as:
 
 * Enabling the Linux user-namespace on all containers (root user in the container maps to an unprivileged user in the Linux VM).
-* Restricting the container from mounting sensitive VM directories
-* Vetting sensitive system-calls between the container and the Linux kernel
-* Mapping filesystem user/group IDs between the container's user-namespace and the Linux VM
-* Emulating portions of the procfs and sysfs filesystems inside the container
+* Restricting the container from mounting sensitive VM directories.
+* Vetting sensitive system-calls between the container and the Linux kernel.
+* Mapping filesystem user/group IDs between the container's user-namespace and the Linux VM.
+* Emulating portions of the procfs and sysfs filesystems inside the container.
 
 Some of these are made possible by recent advances in the Linux kernel which
 Docker Desktop now incorporates. Sysbox applies these techniques with minimal
@@ -58,7 +58,7 @@ For more information, see [Key features and benefits](features-benefits.md).
 
 ### Enhanced Container Isolation vs Docker Userns-Remap Mode
 
-The Docker Engine includes a feature called [userns-remap mode][/engine/security/userns-remap/]
+The Docker Engine includes a feature called [userns-remap mode](/engine/security/userns-remap/)
 that enables the user-namespace in all containers. However it suffers from a few
 [limitations](/engine/security/userns-remap/) and it's
 not supported within Docker Desktop.
@@ -73,7 +73,7 @@ Desktop in organizations with stringent security requirements.
 
 ### Enhanced Container Isolation vs Rootless Docker
 
-[Rootless Docker][/engine/security/rootless/] allows the Docker Engine, and by
+[Rootless Docker](/engine/security/rootless/) allows the Docker Engine, and by
 extension the containers, to run without root privileges natively a Linux host. This
 allows non-root users install and run Docker natively on Linux.
 

desktop/hardened-desktop/enhanced-container-isolation/index.md

@@ -35,7 +35,7 @@ When Enhanced Container Isolation is enabled using [Settings Management](../sett
 
 - All user containers are automatically run in Linux User Namespaces which ensures stronger isolation.
 - The root user in the container maps to an unprivileged user at VM level.
-- Users can continue using containers as usual, including bind-mounting host directories, volumes, networking configurations, etc.
+- Users can continue using containers as usual, including bind mounting host directories, volumes, networking configurations, etc.
 - Privileged containers work, but they are only privileged within the container's Linux User Namespace, not in the Docker Desktop VM.
 - Containers can no longer share namespaces with the Docker Desktop VM. For example, `--network=host`, `--pid=host`.
 - Containers can no longer modify configuration files in the Docker Desktop VM.
@@ -65,7 +65,10 @@ Next, you must [create and configure the `admin-settings.json` file](../settings
 }
 ```
 
-Once this is done, developers need to either quit, re-launch, and sign in to Docker Desktop, or launch and sign in to Docker Desktop for the first time.
+For this to take effect:
+
+- On a new install, developers need to launch Docker Desktop and authenticate to their organization.
+- On an existing install, developers need to quit Docker Desktop through the Docker menu, and then relaunch Docker Desktop. If they are already signed in, they don’t need to sign in again for the changes to take effect.
 
 >Important
   >
@@ -74,7 +77,7 @@ Once this is done, developers need to either quit, re-launch, and sign in to Doc
 
 ### What do users see when this setting is enforced?
 
-When Enhanced Container Isolation is enabled, users see that containers run within a Linux user-namespace. 
+When Enhanced Container Isolation is enabled, users see that containers run within a Linux user namespace. 
 
 To check, run:
 
@@ -90,7 +93,7 @@ The following output displays:
 
 This indicates that the container's root user (0) maps to unprivileged user (100000) in the Docker Desktop VM, and that the mapping extends for a range of 64K user-IDs.
 
-In contrast, without Enhanced Container Isolation the Linux user-namespace is not used, the following displays:
+In contrast, without Enhanced Container Isolation the Linux user namespace is not used, the following displays:
 
 ```
          0          0 4294967295

desktop/hardened-desktop/index.md

@@ -7,7 +7,7 @@ keywords: security, hardened desktop, enhanced container isolation, registry acc
 >
 >Hardened Desktop is available to Docker Business customers only.
 
-Hardened Desktop is a security model for Docker Desktop. It's designed to provide admins with a simple and powerful way to improve their organizations security posture for containerized development, without impacting the developer experience that Docker Desktop offers.
+Hardened Desktop is a security model for Docker Desktop. It's designed to provide admins with a simple and powerful way to improve their organization's security posture for containerized development, without impacting the developer experience that Docker Desktop offers.
 
 It is for security conscious organizations who don’t give their users root or admin access on their machines, and who would like Docker Desktop to be within their organization’s centralized control.
 

desktop/hardened-desktop/registry-access-management.md

@@ -29,7 +29,7 @@ You need to [configure a registry.json to enforce sign-in](../../docker-hub/conf
 To configure Registry Access Management permissions:
 
 1. Sign in to your [Docker Hub](https://hub.docker.com){: target="_blank" rel="noopener" class="_"} account as an organization owner.
-2. Select an organization and then navigate to the **Settings** tab on the **Organizations** page and click **Registry Access**.
+2. Select an organization and then navigate to the **Settings** tab on the **Organizations** page and select **Registry Access**.
 3. Toggle on Registry Access Management to set the permissions for your registry.
 
    > **Note**

desktop/hardened-desktop/settings-management/index.md

@@ -43,20 +43,16 @@ For more details on the syntax and options admins can set, see [Configure Settin
 
 As an administrator, you first need to [configure a registry.json to enforce sign-in](../../../docker-hub/configure-sign-in.md). This is because the Settings Management feature requires a Docker Business subscription and therefore your Docker Desktop users must authenticate to your organization for this configuration to take effect.
 
-Next, you must [create and configure the admin-settings.json file](configure.md). You can also use the `--admin-settings` installer flag on [macOS](../../install/mac-install.md#install-from-the-command-line) or [Windows](../../install/windows-install.md#install-from-the-command-line) to automatically create the `admin-settings.json` and save it in the correct location
+Next, you must either manually [create and configure the admin-settings.json file](configure.md), or use the `--admin-settings` installer flag on [macOS](../../install/mac-install.md#install-from-the-command-line) or [Windows](../../install/windows-install.md#install-from-the-command-line) to automatically create the `admin-settings.json` and save it in the correct location.
 
 Once this is done, Docker Desktop users receive the changed settings when they either:
 - Quit, re-launch, and sign in to Docker Desktop
 - Launch and sign in to Docker Desktop for the first time
 
 Docker doesn't automatically mandate that developers re-launch and re-authenticate once a change has been made, so as not to disrupt your developers' workflow. 
 
-
-
 ### What do users see when the settings are enforced?
 
-Docker Desktop users see a notification in **Settings**, or **Preferences** if using a macOS, which states **Some settings are managed by your Admin**. 
-
 Any settings that are enforced, are grayed out in Docker Desktop and the user is unable to edit them, either via the Docker Desktop UI, CLI, or the `settings.json` file. In addition, if Enhanced Container Isolation is enforced, users can't use privileged containers or similar techniques to modify enforced settings within the Docker Desktop Linux VM, for example, reconfigure proxy and networking of reconfigure Docker Engine.
 
 ![Proxy settings grayed out](/assets/images/grayed-setting.png){:width="750px"}