Sync from docker/docs@c02a507 by PCIT

SUMMARY.md

@@ -913,7 +913,7 @@
         * [Identity Providers](content/faq/security/single-sign-on/idp-faqs.md)
         * [SAML](content/faq/security/single-sign-on/saml-faqs.md)
         * [Manage Users](content/faq/security/single-sign-on/users-faqs.md)
-      * [FA Qs](content/faq/security/eci-faq.md)
+      * [Enhanced Container Isolation ECI FA Qs](content/faq/security/eci-faq.md)
       * [General Security FA Qs](content/faq/security/general.md)
       * [Network And VM FA Qs](content/faq/security/networking-and-vms.md)
       * [Settings Management FA Qs](content/faq/security/settings-management.md)

content/compose/compose-file/11-extension.md

@@ -10,7 +10,7 @@ Use the prefix `x-` as a top-level element to modularize configurations that you
 Compose ignores any fields that start with `x-`, this is the sole exception where Compose silently ignores unrecognized fields.
 
 They also can be used within any structure in a Compose file where user-defined keys are not expected. 
-Compose use those to enable experimental features, the same way browsers add support for [custom CSS features](https://www.w3.org/TR/2011/REC-CSS2-20110607/syndata.html#vendor-keywords)
+Compose uses those to enable experimental features, the same way browsers add support for [custom CSS features](https://www.w3.org/TR/2011/REC-CSS2-20110607/syndata.html#vendor-keywords)
 
 ## Example 1
 
@@ -148,4 +148,4 @@ Values can combine multiple values without separator.
   40s
   1m30s
   1h5m30s20ms
-```
+```

content/compose/compose-file/build.md

@@ -54,7 +54,7 @@ services:
 When used to build service images from source, the Compose file creates three Docker images:
 
 * `example/webapp`: A Docker image is built using `webapp` sub-directory, within the Compose file's parent folder, as the Docker build context. Lack of a `Dockerfile` within this folder throws an error.
-* `example/database`: A Docker image is built using `backend` sub-directory within the Compose file parent folder. `backend.Dockerfile` file is used to define build steps, this file is searched relative to the context path, which means `..` resolves to the Compose file parent folder, so `backend.Dockerfile` is a sibling file.
+* `example/database`: A Docker image is built using `backend` sub-directory within the Compose file parent folder. `backend.Dockerfile` file is used to define build steps, this file is searched relative to the context path, which means `..` resolves to the Compose file's parent folder, so `backend.Dockerfile` is a sibling file.
 * A Docker image is built using the `custom` directory with the user's HOME as the Docker context. Compose displays a warning about the non-portable path used to build image.
 
 On push, both `example/webapp` and `example/database` Docker images are pushed to the default registry. The `custom` service image is skipped as no `image` attribute is set and Compose displays a warning about this missing attribute.

content/config/containers/resource_constraints.md

@@ -273,22 +273,9 @@ done so.
 
 Verify that your GPU is running and accessible.
 
-#### Install nvidia-container-runtime
+#### Install nvidia-container-toolkit
 
-Follow the instructions at (https://nvidia.github.io/nvidia-container-runtime/)
-and then run this command:
-
-```console
-$ apt-get install nvidia-container-runtime
-```
-
-Ensure the `nvidia-container-runtime-hook` is accessible from `$PATH`.
-
-```console
-$ which nvidia-container-runtime-hook
-```
-
-Restart the Docker daemon.
+Follow the official NVIDIA Container Toolkit [installation instructions](https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/install-guide.html).
 
 #### Expose GPUs for use
 
@@ -350,10 +337,10 @@ This enables the `utility` driver capability which adds the `nvidia-smi` tool to
 the container.
 
 Capabilities as well as other configurations can be set in images via
-environment variables. More information on valid variables can be found at the
-[nvidia-container-runtime](https://github.com/NVIDIA/nvidia-container-runtime)
-GitHub page. These variables can be set in a Dockerfile.
+environment variables. More information on valid variables can be found in the
+[nvidia-container-toolkit](https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/docker-specialized.html)
+documentation. These variables can be set in a Dockerfile.
 
 You can also use CUDA images which sets these variables automatically. See the
-[CUDA images](https://github.com/NVIDIA/nvidia-docker/wiki/CUDA) GitHub page
-for more information.
+official [CUDA images](https://catalog.ngc.nvidia.com/orgs/nvidia/containers/cuda)
+NGC catalog page.

content/desktop/hardened-desktop/enhanced-container-isolation/_index.md

@@ -57,8 +57,10 @@ For more information on how Enhanced Container Isolation work, see [How does it
 
 > **Important**
 >
-> Enhanced Container Isolation does not protect Kubernetes pods. For more information on known limitations and workarounds, see [FAQs](../../../faq/security/eci-faq.md).
-{ .important }
+> Enhanced Container Isolation does not yet fully protect Docker builds,
+> Kubernetes pods and Extension containers. For more information on known
+> limitations and workarounds, see [FAQs](../../../faq/security/eci-faq.md).
+{.important }
 
 ### What host OSes / platforms is Enhanced Container Isolation supported on?
 

content/faq/security/eci-faq.md

@@ -1,32 +1,33 @@
 ---
-title: FAQs
+title: Enhanced Container Isolation (ECI) FAQs
 description: Frequently asked questions for Enhanced Container Isolation
 keywords: enhanced container isolation, security, faq, sysbox, Docker Desktop
 toc_max: 2
 aliases:
 - /desktop/hardened-desktop/enhanced-container-isolation/faq/
 ---
 
-### Do I need to change the way I use Docker when Enhanced Container Isolation is switched on?
+### Do I need to change the way I use Docker when ECI is switched on?
 
-No, you can continue to use Docker as usual. 
+No, you can continue to use Docker as usual. ECI works under the covers by
+creating a more secure container.
 
-### Do all container workloads work well with Enhanced Container Isolation?
+### Do all container workloads work well with ECI?
 
-The great majority of container workloads run fine with ECI, but a few do not
-(yet). For the few workloads that don't yet work with Enhanced Container
+The great majority of container workloads run fine with ECI enabled, but a few
+do not (yet). For the few workloads that don't yet work with Enhanced Container
 Isolation, Docker is continuing to improve the feature to reduce this to a
 minimum.
 
-### Can I run privileged containers with Enhanced Container Isolation?
+### Can I run privileged containers with ECI?
 
 Yes, you can use the `--privileged` flag in containers but unlike privileged
-containers without Enhanced Container Isolation, the container can only use it's elevated privileges to
+containers without ECI, the container can only use it's elevated privileges to
 access resources assigned to the container. It can't access global kernel
 resources in the Docker Desktop Linux VM. This allows you to run privileged
 containers securely (including Docker-in-Docker). For more information, see [Key features and benefits](features-benefits.md#privileged-containers-are-also-secured).
 
-### Will all privileged container workloads run with Enhanced Container Isolation?
+### Will all privileged container workloads run with ECI?
 
 No. Privileged container workloads that wish to access global kernel resources
 inside the Docker Desktop Linux VM won't work. For example, you can't use a
@@ -39,49 +40,66 @@ containers, for example Docker-in-Docker or Kubernetes-in-Docker, to
 perform kernel operations such as loading modules, or to access hardware
 devices.
 
-Enhanced Container Isolation allows the running of advanced workloads, but denies the ability to perform
+ECI allows the running of 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 ECI restrict bind mounts inside the container?
 
 Yes, it restricts bind mounts of directories located in the Docker Desktop Linux
 VM into the container.
 
 It doesn't 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?
+### Can I mount the host's Docker Socket into a container when ECI is enabled?
 
-It protects all containers launched by users via `docker create` and `docker run`. It does not yet protect Docker Desktop Kubernetes pods, ExtensioncContainers, and Dev Environments.
+By default, ECI blocks bind-mounting the host's Docker socket into containers,
+for security reasons. However, there are legitimate use cases for this, such as
+when using [Testcontainers](https://testcontainers.com/) for local testing.
 
-### Does Enhanced Container Isolation protect containers launched prior to enabling ECI?
+To enable such use cases, it's possible to configure ECI to allow Docker socket
+mounts into containers, but only for your chosen (i.e,. trusted) container images, and
+even restrict what commands the container can send to the Docker engine via the socket.
+See [ECI Docker socket mount permissions](../../desktop/hardened-desktop/enhanced-container-isolation/config.md#docker-socket-mount-permissions).
+
+### Does ECI protect all containers launched with Docker Desktop?
+
+Not yet. It protects all containers launched by users via `docker create` and
+`docker run`. In addition, it protects containers implicitly used by `docker build`, when
+using the [docker-container build driver](../../build/drivers/_index.md).
+
+It does not yet protect containers implicitly used by `docker build` with the
+`docker` build driver, nor Docker Desktop Kubernetes pods, Extension containers,
+and [Dev Environments containers](../../desktop/dev-environments/_index.md).
+
+### Does ECI protect containers launched prior to enabling ECI?
 
 No. Containers created prior to switching on ECI are not protected. Therefore, we
-recommend removing all containers prior to switching on ECI. 
+recommend removing all containers prior to switching on ECI.
 
-### Does Enhanced Container Isolation affect the performance of containers?
+### Does ECI affect the performance of containers?
 
-Enhanced Container Isolation has very little impact on the performance of
+ECI has very little impact on the performance of
 containers. The exception is for containers that perform lots of `mount` and
 `umount` system calls, as these are trapped and vetted by the Sysbox container
 runtime to ensure they are not being used to breach the container's filesystem.
 
-### With Enhanced Container Isolation, can the user still override the `--runtime` flag from the CLI ?
+### With ECI, can the user still override the `--runtime` flag from the CLI ?
 
-No. With Enhanced Container Isolation enabled, Sysbox is set as the default (and only) runtime for
+No. With ECI enabled, Sysbox is set as the default (and only) runtime for
 containers deployed by Docker Desktop users. If a user attempts to override the
 runtime (e.g., `docker run --runtime=runc`), this request is ignored and the
 container is created through the Sysbox runtime.
 
-The reason `runc` is disallowed with Enhanced Container Isolation because it
-allows users to run as "true root" on the Docker Desktop Linux VM, thereby
-providing them with implicit control of the VM and the ability to modify the
-administrative configurations for Docker Desktop, for example.
+The reason `runc` is disallowed with ECI because it allows users to run as "true
+root" on the Docker Desktop Linux VM, thereby providing them with implicit
+control of the VM and the ability to modify the administrative configurations
+for Docker Desktop, for example.
 
 ### How is ECI different from Docker Engine's userns-remap mode?
 
 See [How does it work](how-eci-works.md#enhanced-container-isolation-vs-docker-userns-remap-mode).
 
 ### How is ECI different from Rootless Docker?
 
-See [How does it work](how-eci-works.md#enhanced-container-isolation-vs-rootless-docker)
+See [How does it work](how-eci-works.md#enhanced-container-isolation-vs-rootless-docker)

content/security/for-admins/scim.md

@@ -34,6 +34,11 @@ The following table lists the supported attributes. Note that your attribute map
 
 For additional details about supported attributes and SCIM, see [Docker Hub API SCIM reference](/docker-hub/api/latest/#tag/scim).
 
+> **Important**
+>
+>SSO uses Just-in-Time (JIT) provisioning by default. If you [enable SCIM](scim.md#set-up-scim), JIT values still overwrite the attribute values set by SCIM provisioning whenever users log in. To avoid conflicts, make sure your JIT values match your SCIM values. For more information, see [SSO attributes](../for-admins/single-sign-on/_index.md#sso-attributes).
+{.important}
+
 ## Set up SCIM
 
 You must make sure you have [configured SSO](single-sign-on/configure/_index.md) before you enable SCIM. Enforcing SSO isn't required.

content/security/for-admins/single-sign-on/_index.md

@@ -36,7 +36,12 @@ When a user signs in using SSO, Docker obtains the following attributes from the
 - **Full name** - name of the user
 - **Groups (optional)** - list of groups to which the user belongs
 
-If you use SAML for your SSO connection, Docker obtains these attributes from the SAML assertion message. Your IdP may use different naming for SAML attributes than those in the previous list. The following table lists the possible SAML attributes that can be present in order for your SSO connection to work. 
+If you use SAML for your SSO connection, Docker obtains these attributes from the SAML assertion message. Your IdP may use different naming for SAML attributes than those in the previous list. The following table lists the possible SAML attributes that can be present in order for your SSO connection to work.
+
+> **Important**
+>
+>SSO uses Just-in-Time (JIT) provisioning by default. If you [enable SCIM](../scim.md#set-up-scim), JIT values still overwrite the attribute values set by SCIM provisioning whenever users log in. To avoid conflicts, make sure your JIT values match your SCIM values. For example, to make sure that the full name of a user displays in your organization, you would set a `name` attribute in your SAML attributes and ensure the value includes their first name and last name. The exact method for setting these values (for example, constructing it with `user.firstName + " " + user.lastName`) varies depending on your IdP.
+{.important}
 
 You can also configure attributes to override default values, such as default team or organization. See [role mapping](../scim.md#set-up-role-mapping).
 
@@ -51,7 +56,7 @@ You can also configure attributes to override default values, such as default te
 
 > **Important**
 >
-> If none of the email address attributes listed in the previous table are found, SSO returns an error.
+> If none of the email address attributes listed in the previous table are found, SSO returns an error. Also, if the `Full name` attribute isn't set, then the name will be displayed as the value of the `Email address`.
 { .important}
 
 ## Prerequisites