mirror of https://github.com/docker/docs.git
ENGDOCS-2306 (#21398)
<!--Delete sections as needed --> ## Description Freshness on IAM, HDD index page and Air-gapped containers page. ## 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
This commit is contained in:
parent
524b00fa24
commit
cef62c197d
|
@ -60,6 +60,7 @@ exceptions:
|
|||
- LTS
|
||||
- MAC
|
||||
- MDM
|
||||
- MDN
|
||||
- NAT
|
||||
- NET
|
||||
- NFS
|
||||
|
@ -90,6 +91,7 @@ exceptions:
|
|||
- SDK
|
||||
- SLES
|
||||
- SLSA
|
||||
- SOCKS
|
||||
- SPDX
|
||||
- SQL
|
||||
- SSD
|
||||
|
|
|
@ -108,6 +108,7 @@ Zsh
|
|||
[Mm]oby
|
||||
[Oo]nboarding
|
||||
[Pp]aravirtualization
|
||||
[Pp]roxied
|
||||
[Pp]roxying
|
||||
[Rr]eal-time
|
||||
[Rr]untimes?
|
||||
|
@ -156,5 +157,6 @@ tmpfs
|
|||
ufw
|
||||
umask
|
||||
ungated
|
||||
untrusted
|
||||
vSphere
|
||||
vpnkit
|
||||
|
|
|
@ -37,9 +37,9 @@ weight: 60
|
|||
|
||||
Hardened Docker Desktop is a group of security features, designed to improve the security of developer environments with minimal impact on developer experience or productivity.
|
||||
|
||||
It lets administrators enforce strict security settings, preventing developers and their containers from bypassing these controls, either intentionally or unintentionally. Additionally, you can enhance container isolation, to mitigate potential security threats such as malicious payloads breaching the Docker Desktop Linux VM and the underlying host.
|
||||
It lets you enforce strict security settings, preventing developers and their containers from bypassing these controls, either intentionally or unintentionally. Additionally, you can enhance container isolation, to mitigate potential security threats such as malicious payloads breaching the Docker Desktop Linux VM and the underlying host.
|
||||
|
||||
Hardened Docker Desktop moves the ownership boundary for Docker Desktop configuration to the organization, meaning that any security controls administrators set cannot be altered by the user of Docker Desktop.
|
||||
Hardened Docker Desktop moves the ownership boundary for Docker Desktop configuration to the organization, meaning that any security controls you set cannot be altered by the user of Docker Desktop.
|
||||
|
||||
It is for security conscious organizations who:
|
||||
- Don’t give their users root or administrator access on their machines
|
||||
|
@ -50,8 +50,8 @@ It is for security conscious organizations who:
|
|||
|
||||
Hardened Desktop features work independently but collectively to create a defense-in-depth strategy, safeguarding developer workstations against potential attacks across various functional layers, such as configuring Docker Desktop, pulling container images, and running container images. This multi-layered defense approach ensures comprehensive security. It helps mitigate against threats such as:
|
||||
|
||||
- Malware and supply chain attacks: Registry Access Management and Image Access Management prevent developers from accessing certain container registries and image types, significantly lowering the risk of malicious payloads. Additionally, ECI restricts the impact of containers with malicious payloads by running them without root privileges inside a Linux user namespace.
|
||||
- Lateral movement: Air-Gapped Containers lets administrators configure network access restrictions for containers, thereby preventing malicious containers from performing lateral movement within the organization's network.
|
||||
- Insider threats: Settings Management configures and locks various Docker Desktop settings so administrators can enforce company policies and prevent developers from introducing insecure configurations, intentionally or unintentionally.
|
||||
- Malware and supply chain attacks: Registry Access Management and Image Access Management prevent developers from accessing certain container registries and image types, significantly lowering the risk of malicious payloads. Additionally, Enhanced Container Isolation (ECI) restricts the impact of containers with malicious payloads by running them without root privileges inside a Linux user namespace.
|
||||
- Lateral movement: Air-gapped containers lets you configure network access restrictions for containers, thereby preventing malicious containers from performing lateral movement within the organization's network.
|
||||
- Insider threats: Settings Management configures and locks various Docker Desktop settings so you can enforce company policies and prevent developers from introducing insecure configurations, intentionally or unintentionally.
|
||||
|
||||
{{< grid >}}
|
||||
|
|
|
@ -9,11 +9,11 @@ aliases:
|
|||
|
||||
{{< introduced desktop 4.29.0 "/manuals/desktop/release-notes.md#4290" >}}
|
||||
|
||||
Air-Gapped Containers allows administrators to restrict containers from accessing network resources, limiting where data can be uploaded to or downloaded from.
|
||||
Air-gapped containers let you restrict containers from accessing network resources, limiting where data can be uploaded to or downloaded from.
|
||||
|
||||
Docker Desktop can apply a custom set of proxy rules to network traffic from containers. The proxy can be configured to:
|
||||
|
||||
- Allow network connections
|
||||
- Accept network connections
|
||||
- Reject network connections
|
||||
- Tunnel through an HTTP or SOCKS proxy
|
||||
|
||||
|
@ -79,7 +79,7 @@ The `FindProxyForURL` can return the following values:
|
|||
|
||||
- `PROXY host_or_ip:port`: Tunnels this request through the HTTP proxy `host_or_ip:port`
|
||||
- `SOCKS5 host_or_ip:port`: Tunnels this request through the SOCKS proxy `host_or_ip:port`
|
||||
- `DIRECT`: Allows this request to go direct, without a proxy
|
||||
- `DIRECT`: Lets this request go direct, without a proxy
|
||||
- `PROXY reject.docker.internal:any_port`: Rejects this request
|
||||
|
||||
In this particular example, HTTP and HTTPS requests for `internal.corp` are sent via the HTTP proxy `10.0.0.1:3128`. Requests to connect to IPs on the subnet `192.168.0.0/24` connect directly. All other requests are blocked.
|
||||
|
|
|
@ -14,20 +14,15 @@ weight: 40
|
|||
>
|
||||
> Image Access Management is available to [Docker Business](/manuals/subscription/core-subscription/details.md#docker-business) customers only.
|
||||
|
||||
Image Access Management gives administrators control over which types of images, such as Docker Official Images, Docker Verified Publisher Images, or community images, their developers can pull from Docker Hub.
|
||||
Image Access Management gives you control over which types of images, such as Docker Official Images, Docker Verified Publisher Images, or community images, your developers can pull from Docker Hub.
|
||||
|
||||
For example, a developer, who is part of an organization, building a new containerized application could accidentally use an untrusted, community image as a component of their application. This image could be malicious and pose a security risk to the company. Using Image Access Management, the organization owner can ensure that the developer can only access trusted content like Docker Official Images, Docker Verified Publisher Images, or the organization’s own images, preventing such a risk.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
You need to [enforce sign-in](../enforce-sign-in/_index.md). For Image Access
|
||||
Management to take effect, Docker Desktop users must authenticate to your
|
||||
organization. Enforcing sign-in ensures that your Docker Desktop developers
|
||||
always authenticate to your organization, even though they can authenticate
|
||||
without it and the feature will take effect. Enforcing sign-in guarantees the
|
||||
feature always takes effect.
|
||||
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 Image Access 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.
|
||||
|
||||
## Configure Image Access Management permissions
|
||||
## Configure
|
||||
|
||||
{{< tabs >}}
|
||||
{{< tab name="Docker Hub" >}}
|
||||
|
|
|
@ -10,12 +10,12 @@
|
|||
2. {{ $iam_navigation }}
|
||||
3. Enable Image Access Management to set the permissions for the following categories of images you can manage:
|
||||
|
||||
- **Organization images**: Images from your organization are always allowed by default. These images can be public or private created by members within your organization.
|
||||
- **Organization Images**: Images from your organization are always allowed by default. These images can be public or private created by members within your organization.
|
||||
- **Docker Official Images**: A curated set of Docker repositories hosted on Hub. They provide OS repositories, best practices for Dockerfiles, drop-in solutions, and applies security updates on time.
|
||||
- **Docker Verified Publisher Images**: Images published by Docker partners that are part of the Verified Publisher program and are qualified to be included in the developer secure supply chain.
|
||||
- **Community images**: These images are disabled by default when Image Access Management is enabled because various users contribute them and they may pose security risks. This category includes Docker-Sponsored Open Source images.
|
||||
- **Community Images**: These images are disabled by default when Image Access Management is enabled because various users contribute them and they may pose security risks. This category includes Docker-Sponsored Open Source images.
|
||||
|
||||
> **Note**
|
||||
> [!NOTE]
|
||||
>
|
||||
> Image Access Management is turned off by default. However, owners in your organization have access to all images regardless of the settings.
|
||||
|
||||
|
|
Loading…
Reference in New Issue