ENGDOCS-2324 (#21475)

<!--Delete sections as needed -->

## Description

Light freshness for ECI content and removes references to DD versions
that users can no longer download

**Note** There is a lot of 'allow' violations. Am deliberately choosing
to ignore them this time.

## Related issues or tickets

<!-- Related issues, pull requests, or Jira tickets -->

## Reviews

<!-- Notes for reviewers here -->
<!-- List applicable reviews (optionally @tag reviewers) -->

- [ ] Technical review
- [ ] Editorial review
- [ ] Product review

Author: aevesdocker

_vale/Docker/Acronyms.yml

@@ -15,6 +15,7 @@ exceptions:
   - AUFS
   - AWS
   - BIOS
+  - BPF
   - CI
   - CISA
   - CLI
@@ -52,6 +53,7 @@ exceptions:
   - HTTP
   - HTTPS
   - IAM
+  - ID
   - IDE
   - IP
   - JAR
@@ -75,6 +77,7 @@ exceptions:
   - PATH
   - PDF
   - PEM
+  - PID
   - PHP
   - POSIX
   - POST

_vale/config/vocabularies/Docker/accept.txt

@@ -1,4 +1,4 @@
-(?-i)[A-Z]{2,}s
+(?-i)[A-Z]{2,}'?s
 Amazon
 Anchore
 Apple
@@ -21,6 +21,7 @@ Datadog
 Ddosify
 Debootstrap
 Dev Environments?
+Dev
 Django
 Docker Build Cloud
 Docker Business
@@ -71,6 +72,7 @@ Nuxeo
 OAuth
 OTel
 Okta
+Paketo
 PKG
 Postgres
 PowerShell
@@ -82,6 +84,7 @@ Snyk
 Solr
 SonarQube
 Syft
+Sysbox
 Sysdig
 Testcontainers
 Traefik
@@ -95,6 +98,7 @@ Zscaler
 Zsh
 [Aa]utobuild
 [Bb]uildx
+[Bb]uildpack(s)?
 [Cc]odenames?
 [Cc]ompose
 [Dd]istroless
@@ -109,13 +113,16 @@ Zsh
 [Nn]amespace
 [Oo]nboarding
 [Pp]aravirtualization
+[Pp]rocfs
 [Pp]roxied
 [Pp]roxying
 [Rr]eal-time
 [Rr]untimes?
 [Ss]andbox(ed)?
+[Ss]eccomp
 [Ss]wappable
 [Ss]warm
+[Ss]ysfs
 [Tt]oolchains?
 [Vv]irtiofs
 [Vv]irtualize
@@ -144,10 +151,13 @@ minikube
 monorepos?
 musl
 nameserver
+namespace
+namespacing
 npm
 osquery
 osxfs
 pgAdmin
+rootful
 runc
 snapshotters?
 stdin

content/manuals/security/for-admins/hardened-desktop/enhanced-container-isolation/_index.md

@@ -13,49 +13,41 @@ weight: 20
 >
 > Enhanced Container Isolation is available to Docker Business customers only.
 
-Enhanced Container Isolation provides an additional layer of security to prevent malicious workloads running in containers from compromising Docker Desktop or the host.
+Enhanced Container Isolation (ECI) provides an additional layer of security to prevent malicious workloads running in containers from compromising Docker Desktop or the host.
 
-It uses a variety of advanced techniques to harden container isolation, but without impacting developer productivity. It is available with [Docker Desktop 4.13.0 and later](/manuals/desktop/release-notes.md).
+It uses a variety of advanced techniques to harden container isolation, but without impacting developer productivity. 
 
-These techniques include:
-- Running all containers unprivileged through the Linux user-namespace, even those launched with the `--privileged` flag. This makes it harder for malicious container workloads to escape the container and infect the Docker Desktop VM and host.
-- Ensuring Docker Desktop VM immutability (e.g., its internal settings can't be modified by containers or users).
-- Vetting some critical system calls to prevent container escapes, and partially virtualizing portions of `/proc` and `/sys` inside the container for further isolation.
-- Preventing user console access to the Docker Desktop VM.
-
-When Enhanced Container Isolation is enabled, these mechanisms are applied automatically and with minimal functional or performance impact to developers. Developers continue to use Docker Desktop as usual, but the containers they launch are more strongly isolated.
-
-Enhanced Container Isolation ensures stronger container isolation and also locks in any security configurations that have been created by IT admins, for instance through [Registry Access Management policies](/manuals/security/for-admins/hardened-desktop/registry-access-management.md) or with [Settings Management](../settings-management/_index.md).
+Enhanced Container Isolation ensures stronger container isolation and also locks in any security configurations that have been created by administrators, for instance through [Registry Access Management policies](/manuals/security/for-admins/hardened-desktop/registry-access-management.md) or with [Settings Management](../settings-management/_index.md).
 
 > [!NOTE]
 >
-> Enhanced Container Isolation is in addition to other container security techniques used by Docker. For example, reduced Linux Capabilities, Seccomp, AppArmor.
+> ECI is in addition to other container security techniques used by Docker. For example, reduced Linux Capabilities, seccomp, and AppArmor.
 
-### Who is it for?
+## Who is it for?
 
 - For organizations and developers that want to prevent container attacks and reduce vulnerabilities in developer environments.
 - For organizations that want to ensure stronger container isolation that is easy and intuitive to implement on developers' machines.
 
-### What happens when Enhanced Container Isolation is turned on?
+## What happens when Enhanced Container Isolation is turned on?
 
-When Enhanced Container Isolation is turned on, the following features are enabled:
+When Enhanced Container Isolation is turned on, the following features and security techniques are enabled:
 
-- All user containers are automatically run in Linux User Namespaces which ensures stronger isolation. Each container runs in a dedicated Linux user-namespace.
+- All user containers are automatically run in Linux user namespaces which ensures stronger isolation. Each container runs in a dedicated Linux user-namespace.
 - The root user in the container maps to an unprivileged user inside the Docker Desktop Linux VM.
-- Containers become harder to breach. For example, sensitive system calls are vetted and portions of `/proc` and `/sys` are emulated.
+- Containers become harder to breach. For example, sensitive system calls are vetted and portions of `/proc` and `/sys` are emulated inside the container.
 - Users can continue using containers as usual, including bind mounting host directories, volumes, etc.
 - No change in the way developers run containers, and no special container images are required.
-- Privileged containers (e.g., `--privileged` flag) work, but they are only privileged within the container's Linux User Namespace, not in the Docker Desktop VM. Therefore they can't be used to breach the Docker Desktop VM.
+- Privileged containers (e.g., `--privileged` flag) work, but they are only privileged within the container's Linux user namespace, not in the Docker Desktop VM. Therefore they can't be used to breach the Docker Desktop VM.
 - Docker-in-Docker and even Kubernetes-in-Docker works, but run unprivileged inside the Docker Desktop Linux VM.
 
 In addition, the following restrictions are imposed:
 
 - Containers can no longer share namespaces with the Docker Desktop VM (e.g., `--network=host`, `--pid=host` are disallowed).
 - Containers can no longer modify configuration files inside the Docker Desktop VM (e.g., mounting any VM directory into the container is disallowed).
-- Containers can no longer access the Docker engine (e.g., mounting the Docker engine's socket into the container is restricted); this prevents malicious containers from gaining control of the Docker engine. Admins can relax this for [trusted container images](config.md).
+- Containers can no longer access the Docker Engine. For example, mounting the Docker Engine's socket into the container is restricted which prevents malicious containers from gaining control of the Docker Engine. Administrators can relax this for [trusted container images](config.md).
 - Console access to the Docker Desktop VM is forbidden for all users.
 
-These features and restrictions ensure that containers are better secured at runtime, with minimal impact to developer experience and productivity.
+These features and restrictions ensure that containers are better secured at runtime, with minimal impact to developer experience and productivity. Developers can continue to use Docker Desktop as usual, but the containers they launch are more strongly isolated.
 
 For more information on how Enhanced Container Isolation work, see [How does it work](how-eci-works.md).
 
@@ -65,20 +57,9 @@ For more information on how Enhanced Container Isolation work, see [How does it
 > Kubernetes pods and Extension containers. For more information on known
 > limitations and workarounds, see [FAQs](faq.md).
 
-### What host OSes / platforms is Enhanced Container Isolation supported on?
-
-Enhanced Container Isolation (ECI) was introduced in Docker Desktop 4.13, for all platforms (Windows, Mac, and Linux).
-
-For Windows hosts, ECI works with both the Docker Desktop Hyper-V and WSL 2 backends, as follows:
-
-- Docker Desktop 4.19 or prior: ECI only works with Hyper-V.
-- Docker Desktop 4.20 or later: ECI Works with both Hyper-V and WSL 2 (with WSL version 1.1.3.0 and above).
+## How do I enable Enhanced Container Isolation?
 
-See [ECI Support for WSL](limitations.md#eci-support-for-wsl) for further info as well as security caveats when using Enhanced Container Isolation on WSL 2.
-
-### How do I enable Enhanced Container Isolation?
-
-#### As a developer
+### As a developer
 
 To enable Enhanced Container Isolation as a developer:
 1. Ensure your organization has a Docker Business subscription.
@@ -92,19 +73,13 @@ To enable Enhanced Container Isolation as a developer:
 >
 > Enhanced Container Isolation does not protect containers created prior to enabling ECI. For more information on known limitations and workarounds, see [FAQs](faq.md).
 
-#### As an admin
-
-##### Prerequisite
+### As an administrator
 
-To enable Enhanced Container Isolation as an admin, you first need to [enforce
-sign-in](/manuals/security/for-admins/enforce-sign-in/_index.md). This is
-because the Enhanced Container Isolation feature requires a Docker Business
-subscription and therefore your Docker Desktop users must authenticate to your
-organization for this configuration to take effect. 
+#### Prerequisite
 
-Enforcing sign-in ensures that your Docker Desktop developers always authenticate to your organization.
+You first need to [enforce sign-in](/manuals/security/for-admins/enforce-sign-in/_index.md) to ensure that all Docker Desktop developers authenticate with your organization. Since Settings Management requires a Docker Business subscription, enforced sign-in guarantees that only authenticated users have access and that the feature consistently takes effect across all users, even though it may still work without enforced sign-in.
 
-##### Setup
+#### Setup
 
 [Create and configure the `admin-settings.json` file](/manuals/security/for-admins/hardened-desktop/settings-management/configure-json-file.md) and specify:
 
@@ -118,13 +93,13 @@ Enforcing sign-in ensures that your Docker Desktop developers always authenticat
 }
 ```
 
-By setting `"value": true`, the admin ensures ECI is enabled by default. By
-setting `"locked": true`, the admin ensures ECI can't be disabled by
-developers. If you wish to give developers the ability to disable the feature,
+Setting `"value": true` ensures ECI is enabled by default. By
+setting `"locked": true`, ECI can't be disabled by
+developers. If you want to give developers the ability to disable the feature,
 set `"locked": false`.
 
-In addition, starting with Docker Desktop 4.27, admins can also configure Docker
-socket mount permissions for containers, as described [here](config.md).
+In addition, you can also [configure Docker
+socket mount permissions for containers](config.md).
 
 For this to take effect:
 
@@ -135,12 +110,12 @@ For this to take effect:
 >
 > Selecting **Restart** from the Docker menu isn't enough as it only restarts some components of Docker Desktop.
 
+## What do users see when this setting is enforced by an administrator?
+
 > [!TIP]
 >
 > You can now also configure these settings in the [Docker Admin Console](/manuals/security/for-admins/hardened-desktop/settings-management/configure-admin-console.md).
 
-### What do users see when this setting is enforced by an admin?
-
 When Enhanced Container Isolation is enabled, users see:
 - **Use Enhanced Container Isolation** toggled on in **Settings** > **General**.
 - Containers run within a Linux user namespace.

content/manuals/security/for-admins/hardened-desktop/enhanced-container-isolation/config.md

@@ -8,25 +8,18 @@ aliases:
 weight: 30
 ---
 
-> [!NOTE]
->
-> This feature is available with Docker Desktop version 4.27 (and later) on Mac, Linux, and Windows (Hyper-V).
-> For Windows with WSL 2, this feature requires Docker Desktop 4.28 and later.
-
-This page describes optional, advanced configurations for ECI, once ECI is enabled.
-
 ## Docker socket mount permissions
 
-By default, when ECI is enabled, Docker Desktop does not allow bind-mounting the
+By default, when Enhanced Container Isolation (ECI) is enabled, Docker Desktop does not allow bind-mounting the
 Docker Engine socket into containers:
 
 ```console
 $ docker run -it --rm -v /var/run/docker.sock:/var/run/docker.sock docker:cli
 docker: Error response from daemon: enhanced container isolation: docker socket mount denied for container with image "docker.io/library/docker"; image is not in the allowed list; if you wish to allow it, configure the docker socket image list in the Docker Desktop settings.
 ```
 This prevents malicious containers from gaining access to the Docker Engine, as
-such access could allow them to perform supply chain attacks (e.g., build and
-push malicious images into the organization's repositories) or similar.
+such access could allow them to perform supply chain attacks. For example, build and
+push malicious images into the organization's repositories or similar.
 
 However, some legitimate use cases require containers to have access to the
 Docker Engine socket. For example, the popular [Testcontainers](https://testcontainers.com/)
@@ -35,11 +28,12 @@ manage them or perform post-test cleanup. Similarly, some Buildpack frameworks,
 for example [Paketo](https://paketo.io/), require Docker socket bind-mounts into
 containers.
 
-Starting with Docker Desktop 4.27, admins can optionally configure ECI to allow
+Administrators can optionally configure ECI to allow
 bind mounting the Docker Engine socket into containers, but in a controlled way.
 
 This can be done via the Docker Socket mount permissions section in the
-[admin-settings.json](../settings-management/_index.md) file. For example:
+[`admin-settings.json`](../settings-management/configure-json-file.md) file. For example:
+
 
 ```json
 {
@@ -75,8 +69,8 @@ described below.
 ### Image list
 
 The `imageList` is a list of container images that are allowed to bind-mount the
-Docker socket. By default the list is empty (i.e., no containers are allowed to
-bind-mount the Docker socket when ECI is enabled). However, an admin can add
+Docker socket. By default the list is empty, no containers are allowed to
+bind-mount the Docker socket when ECI is enabled. However, an administrator can add
 images to the list, using either of these formats:
 
 | Image Reference Format  | Description |
@@ -87,7 +81,7 @@ images to the list, using either of these formats:
 The image name follows the standard convention, so it can point to any registry
 and repository.
 
-In the example above, the image list was configured with three images:
+In the previous example, the image list was configured with three images:
 
 ```json
 "imageList": {
@@ -111,11 +105,10 @@ $ docker run -it -v /var/run/docker.sock:/var/run/docker.sock docker:cli sh
 
 > [!TIP]
 >
-> Be restrictive on the images you allow, as described in [Recommendations](#recommendations) below.
+> Be restrictive with the images you allow, as described in [Recommendations](#recommendations).
 
-In general, it's easier to specify the image using the tag wildcard format
-(e.g., `<image-name>:*`) because then `imageList` doesn't need to be updated whenever a new version of the
-image is used. Alternatively, you can use an immutable tag (e.g., `:latest`),
+In general, it's easier to specify the image using the tag wildcard format, for example `<image-name>:*`, because then `imageList` doesn't need to be updated whenever a new version of the
+image is used. Alternatively, you can use an immutable tag, for example `:latest`,
 but it does not always work as well as the wildcard because, for example,
 Testcontainers uses specific versions of the image, not necessarily the latest
 one.
@@ -126,8 +119,7 @@ memory. Then, when a container is started with a Docker socket bind-mount,
 Docker Desktop checks if the container's image digest matches one of the allowed
 digests. If so, the container is allowed to start, otherwise it's blocked.
 
-Note that due to the digest comparison mentioned in the prior paragraph, it's
-not possible to bypass the Docker socket mount permissions by retagging a
+Due to the digest comparison, it's not possible to bypass the Docker socket mount permissions by re-tagging a
 disallowed image to the name of an allowed one. In other words, if a user
 does:
 
@@ -143,11 +135,9 @@ ones in the repository.
 
 ### Docker Socket Mount Permissions for derived images
 
-> [!NOTE]
->
-> This feature is available with Docker Desktop version 4.34 and later.
+{{ introduced desktop 4.34.0 "../../../../desktop/release-notes.md#4340" }}
 
-As described in the prior section, admins can configure the list of container
+As described in the prior section, administrators can configure the list of container
 images that are allowed to mount the Docker socket via the `imageList`.
 
 This works for most scenarios, but not always, because it requires knowing upfront
@@ -164,7 +154,7 @@ also apply to any local images derived (i.e., built from) an image in the
 That is, if a local image called "myLocalImage" is built from "myBaseImage"
 (i.e., has a Dockerfile with a `FROM myBaseImage`), then if "myBaseImage" is in
 the `imageList`, both "myBaseImage" and "myLocalImage" are allowed to mount the
-Docker socket (i.e., ECI won't block the mount).
+Docker socket.
 
 For example, to enable Paketo buildpacks to work with Docker Desktop and ECI,
 simply add the following image to the `imageList`:
@@ -192,7 +182,7 @@ A couple of caveats:
 
 * The `allowDerivedImages` setting only applies to local-only images built from
   an allowed image. That is, the derived image must not be present in a remote
-  repository (because if it were, you would just list it's name in the `imageList`).
+  repository because if it were, you would just list its name in the `imageList`.
 
 * For derived image checking to work, the parent image (i.e., the image in the
   `imageList`) must be present locally (i.e., must have been explicitly pulled
@@ -339,17 +329,16 @@ Whether to configure the list as an allow or deny list depends on the use case.
 
 | Unsupported command  | Description |
 | :------------------- | :---------- |
-| compose              | Docker compose |
-| dev                  | Docker dev environments |
-| extension            | Manages Docker extensions |
-| feedback             | Send feedback to Docker |
-| init                 | Creates Docker-related starter files |
-| manifest             | Manages Docker image manifests |
-| plugins              | Manages plugins |
-| sbom                 | View Software Bill of Materials (SBOM) |
-| scan                 | Docker Scan |
-| scout                | Docker Scout |
-| trust                | Manage trust on Docker images |
+| `compose`              | Docker Compose |
+| `dev`                  | Dev environments |
+| `extension`            | Manages Docker Extensions |
+| `feedback`             | Send feedback to Docker |
+| `init`                 | Creates Docker-related starter files |
+| `manifest`             | Manages Docker image manifests |
+| `plugin`              | Manages plugins |
+| `sbom`                 | View Software Bill of Materials (SBOM) |
+| `scout`                | Docker Scout |
+| `trust`                | Manage trust on Docker images |
 
 > [!NOTE]
 >