Docker Enterprise 2.x Linux/UNIX Security Technical Implementation Guide

The UCP component of Docker Enterprise configures and leverages Swarm Mode for node-to-node cluster communication. Swarm Mode is built in to Docker Engine - Enterprise and uses TLS 1.2 at a minimum for encrypting communications. Under the hood, Swarm Mode includes an embedded public key infrastructure (PKI) system. When a UCP cluster is initialized, the first node in the cluster designates itself as a manager node. That node subsequently generates a new root Certificate Authority (CA) along with a key pair, which are used to secure communications with other UCP nodes that join the swarm. One can also specify his/her own externally-generated root CA upon initialization of a UCP cluster. The manager node also generates two tokens to use when joining additional nodes to the cluster: one worker token and one manager token. Each token includes the digest of the root CA’s certificate and a randomly generated secret. When a node joins the cluster, the joining node uses the digest to validate the root CA certificate from the remote manager. The remote manager uses the secret to ensure the joining node is an approved node. Each time a new node joins the cluster, the manager issues a certificate to the node. The certificate contains a randomly generated node ID to identify the node under the certificate common name (CN) and the role under the organizational unit (OU). The node ID serves as the cryptographically secure node identity for the lifetime of the node in the current swarm. In this mutual TLS architecture, all nodes encrypt communications using a minimum of TLS 1.2, thereby satisfying the requirements of this control. This information can also be referenced at https://docs.docker.com/engine/swarm/how-swarm-mode-works/pki/ and https://docs.docker.com/ee/ucp/ucp-architecture/. By itself, Docker Engine - Enterprise is configured by default to listen for API requests via a UNIX domain socket (or IPC socket) created at /var/run/docker.sock on supported Linux distributions and via a named pipe at npipe:////./pipe/docker_engine on Windows Server 2016 and newer. Docker Engine - Enterprise can also be configured to listen for API requests via additional socket types, including both TCP and FD (only on supported systemd-based Linux distributions). If configured to listen for API requests via the TCP socket type over TCP port 2376 and with the daemon flags and SSL certificates, then, at a minimum, TLS 1.2 is used for encryption; therefore this control is applicable and is inherently met in this configuration. If configured to listen for API requests via the TCP socket type, but without TLS verification and certifications, then the instance remains vulnerable and is not properly configured to meet the requirements of this control. If configured to listen for API requests via the FD socket type, then this control is not applicable. More information can be found at https://docs.docker.com/engine/reference/commandline/dockerd/#daemon-socket-option. The TCP socket binding should be disabled when running Engine as part of a UCP cluster. Satisfies: SRG-APP-000014, SRG-APP-000141, SRG-APP-000219, SRG-APP-000383, SRG-APP-000439, SRG-APP-000440, SRG-APP-000441, SRG-APP-000442, SRG-APP-000142

The UCP and Docker Trusted Registry (DTR) components of Docker Enterprise provide audit record generation capabilities. Audit logs capture all HTTP actions for the following endpoints: Kubernetes API, Swarm API and UCP API. The following UCP API endpoints are excluded from audit logging (where "*" designates a wildcard of exclusions): "/_ping", "/ca", "/auth", "/trustedregistryca", "/kubeauth", "/metrics", "/info", "/version*", "/debug", "/openid_keys", "/apidocs", "kubernetesdocs" and "/manage". Audit log verbosity can be set to one of the following levels: "none", "metadata", or "request". To meet the requirements of this control, the "request" verbosity level must be configured in UCP. The data captured at each level for UCP and the eNZI authentication and authorization backplane is described below: "none": audit logging is disabled "metadata": - method and API endpoint for the request - UCP user which made the request - response status (success/failure) - timestamp of the call - object ID of created/updated resource (for create/update calls) - license key - remote address "request": includes all fields from the "metadata" level, as well as the request payload DTR audits all events associated with repository activities. Events are considered as follows: create, get, delete, update, send, fail, and scan. The following types are associated with the defined audit events: repository, tag, blob, manifest, webhook, uri, promotion, push mirroring, poll mirroring, garbage collector, system. The Docker Engine - Enterprise component of Docker Enterprise relies on the underlying host operating system's auditing capabilities. By default, the host OS is not configured to audit Docker Engine - Enterprise. Satisfies: SRG-APP-000016, SRG-APP-000089, SRG-APP-000515, SRG-APP-000510, SRG-APP-000509, SRG-APP-000508, SRG-APP-000507, SRG-APP-000506, SRG-APP-000505, SRG-APP-000504, SRG-APP-000503, SRG-APP-000502, SRG-APP-000501, SRG-APP-000500, SRG-APP-000499, SRG-APP-000498, SRG-APP-000497, SRG-APP-000496, SRG-APP-000495, SRG-APP-000494, SRG-APP-000493, SRG-APP-000492, SRG-APP-000484, SRG-APP-000447, SRG-APP-000381, SRG-APP-000343, SRG-APP-000101, SRG-APP-000100, SRG-APP-000099, SRG-APP-000098, SRG-APP-000097, SRG-APP-000096, SRG-APP-000095, SRG-APP-000093, SRG-APP-000092, SRG-APP-000091

The Universal Control Plane (UCP) and Docker Trusted Registry (DTR) components of Docker Enterprise provide audit record generation capabilities. Audit logs capture all HTTP actions for the following endpoints: Kubernetes API, Swarm API and UCP API. The following UCP API endpoints are excluded from audit logging (where "*" designates a wildcard of exclusions): "/_ping", "/ca", "/auth", "/trustedregistryca", "/kubeauth", "/metrics", "/info", "/version*", "/debug", "/openid_keys", "/apidocs", "kubernetesdocs" and "/manage". Audit log verbosity can be set to one of the following levels: "none", "metadata", or "request". To meet the requirements of this control, the "request" verbosity level must be configured in UCP. The data captured at each level for UCP and the eNZI authentication and authorization backplane is described below: "none": audit logging is disabled "metadata": - method and API endpoint for the request - UCP user which made the request - response status (success/failure) - timestamp of the call - object ID of created/updated resource (for create/update calls) - license key - remote address "request": includes all fields from the "metadata" level, as well as the request payload DTR audits all events associated with repository activities. Events are considered as follows: create, get, delete, update, send, fail, and scan. The following types are associated with the defined audit events: repository, tag, blob, manifest, webhook, uri, promotion, push mirroring, poll mirroring, garbage collector, system. The Docker Engine - Enterprise component of Docker Enterprise relies on the underlying host operating system's auditing capabilities. By default, the host OS is not configured to audit Docker Engine - Enterprise. Satisfies: SRG-APP-000016, SRG-APP-000090, SRG-APP-000091, SRG-APP-000097, SRG-APP-000098, SRG-APP-000496, SRG-APP-000504, SRG-APP-000510, SRG-APP-000509, SRG-APP-000508, SRG-APP-000507, SRG-APP-000506, SRG-APP-000505, SRG-APP-000503, SRG-APP-000502, SRG-APP-000500, SRG-APP-000499, SRG-APP-000498, SRG-APP-000497, SRG-APP-000495, SRG-APP-000494, SRG-APP-000493, SRG-APP-000492, SRG-APP-000485, SRG-APP-000484, SRG-APP-000381, SRG-APP-000343, SRG-APP-000115, SRG-APP-000111, SRG-APP-000101, SRG-APP-000100, SRG-APP-000099, SRG-APP-000096, SRG-APP-000095, SRG-APP-000092, SRG-APP-000089, SRG-APP-000501, SRG-APP-000447

Both the Universal Control Plane (UCP) and Docker Trusted Registry (DTR) components of Docker Enterprise leverage the same authentication and authorization backplane known as eNZi. The eNZi backplane provides automated mechanisms for supporting account management functions and allows for LDAP integration in UCP and DTR. While eNZi includes its own managed user database, it is recommended that LDAP integration be configured to more completely satisfy the requirements of this control. Satisfies: SRG-APP-000023, SRG-APP-000405, SRG-APP-000404, SRG-APP-000403, SRG-APP-000401, SRG-APP-000397, SRG-APP-000392, SRG-APP-000148, SRG-APP-000141, SRG-APP-000391

Both the UCP and Docker Trusted Registry (DTR) components of Docker Enterprise leverage the same authentication and authorization backplane known as eNZi. eNZi provides UCP and DTR with role-based access control functionality to enforce approved authorizations for logical access to information and system resources in accordance with applicable access control policies. The eNZi backplane includes its own managed user database, and also allows for LDAP integration in UCP and DTR. While role-based access control mechanisms are provided regardless of whether or not LDAP integration is enabled, it is recommended to enable LDAP integration to better meet the requirements of this control. Satisfies: SRG-APP-000033, SRG-APP-000038, SRG-APP-000039, SRG-APP-000080, SRG-APP-000243, SRG-APP-000246, SRG-APP-000247, SRG-APP-000267, SRG-APP-000311, SRG-APP-000313, SRG-APP-000314, SRG-APP-000328, SRG-APP-000340, SRG-APP-000342, SRG-APP-000378, SRG-APP-000380, SRG-APP-000384

Both the Universal Control Plane (UCP) and DTR components of Docker Enterprise leverage the same authentication and authorization backplane known as eNZi. eNZi provides UCP and DTR with role-based access control functionality to enforce approved authorizations for logical access to information and system resources in accordance with applicable access control policies. These policies are defined in the System Security Plan along with organization information, application user roles, system resources and access requirements. The eNZi backplane includes its own managed user database, and also allows for LDAP integration in UCP and DTR. While role-based access control mechanisms are provided regardless of whether or not LDAP integration is enabled, it is recommended to enable LDAP integration to better meet the requirements of this control. Satisfies: SRG-APP-000033, SRG-APP-000243, SRG-APP-000246, SRG-APP-000247, SRG-APP-000267, SRG-APP-000328, SRG-APP-000340, SRG-APP-000342, SRG-APP-000378, SRG-APP-000380, SRG-APP-000384, SRG-APP-000038, SRG-APP-000039, SRG-APP-000080, SRG-APP-000311, SRG-APP-000313, SRG-APP-000314

Sensitive host system directories such as below should not be allowed to be mounted as container volumes especially in read-write mode. Linux: / /boot /dev /etc /lib /proc /sys /usr Windows: %windir% (C:\Windows) %windir%\system32 (C:\Windows\system32) %programdata% %programData%\docker C:\Program Files C:\Program Files (x86) C:\Users If sensitive directories are mounted in read-write mode, it would be possible to make changes to files within those sensitive directories. The changes might bring down security implications or unwarranted changes that could put the Docker host in compromised state. Docker defaults to a read-write volume but the user can also mount a directory read-only. By default, no sensitive host directories are mounted on containers.

Process ID (PID) namespaces isolate the PID number space, meaning that processes in different PID namespaces can have the same PID. This is process level isolation between containers and the host. PID namespace provides separation of processes. The PID Namespace removes the view of the system processes, and allows process IDs to be reused including PID 1. If the host's PID namespace is shared with the container, it would allow processes within the container to see all of the processes on the host system. This breaks the benefit of process level isolation between the host and the containers. Someone having access to the container can eventually know all the processes running on the host system and can even kill the host system processes from within the container. Hence, do not share the host's process namespace with the containers. Container processes cannot see the processes on the host system. In certain cases, the container should share the host's process namespace. For example, the user could build a container with debugging tools like strace or gdb, but want to use these tools when debugging processes within the container. If this is desired, then share only one (or needed) host process by using the -p switch. Example: docker run --pid=host rhel7 strace -p 1234 By default, all containers have the PID namespace enabled and the host's process namespace is not shared with the containers.

IPC (POSIX/SysV IPC) namespace provides separation of named shared memory segments, semaphores, and message queues. IPC namespace on the host thus should not be shared with the containers and should remain isolated. IPC namespace provides separation of IPC between the host and containers. If the host's IPC namespace is shared with the container, it would allow processes within the container to see all of the IPC on the host system. This breaks the benefit of IPC level isolation between the host and the containers. Someone having access to the container can eventually manipulate the host IPC. Hence, do not share the host's IPC namespace with the containers. Shared memory segments are used to accelerate inter-process communication. It is commonly used by high-performance applications. If such applications are containerized into multiple containers, the user might need to share the IPC namespace of the containers to achieve high performance. In such cases, the user should still be sharing container specific IPC namespaces only and not the host IPC namespace. The user may share the container's IPC namespace with another container as below: Example: docker run --interactive --tty --ipc=container:e3a7a1a97c58 centos /bin/bash By default, all containers have the IPC namespace enabled and host IPC namespace is not shared with any container.

The Universal Control Plane (UCP) and Docker Trusted Registry (DTR) components of Docker Enterprise provide audit record generation capabilities. Audit logs capture all HTTP actions for the following endpoints: Kubernetes API, Swarm API and UCP API. The following UCP API endpoints are excluded from audit logging (where "*" designates a wildcard of exclusions): "/_ping", "/ca", "/auth", "/trustedregistryca", "/kubeauth", "/metrics", "/info", "/version*", "/debug", "/openid_keys", "/apidocs", "kubernetesdocs" and "/manage". Audit log verbosity can be set to one of the following levels: "none", "metadata", or "request". To meet the requirements of this control, the "request" verbosity level must be configured in UCP. The data captured at each level for UCP and the eNZI authentication and authorization backplane is described below: "none": audit logging is disabled "metadata": - method and API endpoint for the request - UCP user which made the request - response status (success/failure) - timestamp of the call - object ID of created/updated resource (for create/update calls) - license key - remote address "request": includes all fields from the "metadata" level, as well as the request payload DTR audits all events associated with repository activities. Events are considered as follows: create, get, delete, update, send, fail, and scan. The following types are associated with the defined audit events: repository, tag, blob, manifest, webhook, uri, promotion, push mirroring, poll mirroring, garbage collector, system. All audit logs generated by UCP and DTR can be forwarded to a remote log aggregation system by configuring an appropriate log driver plugin on all Docker Engine - Enterprise nodes in a cluster. The Docker Engine - Enterprise component of Docker Enterprise relies on the underlying host operating system's auditing capabilities. By default, the host OS is not configured to audit Docker Engine - Enterprise.

Docker considers a private registry either secure or insecure. By default, registries are considered secure. Docker Enterprise includes the following capabilities that are considered non-essential: *NOTE: disabling these capabilities negatively affects the operation of Universal Control Plane (UCP) and Docker Trusted Registry (DTR) and should be disregarded when UCP and DTR are installed. The security capabilities provided by UCP and DTR offset any potential vulnerabilities associated with not disabling these essential capabilities the Engine provides. (Docker Engine - Enterprise: Standalone) - The majority of these items were originally identified as part of the CIS Docker Benchmark, which as of the CIS Docker Benchmark v1.2.0, are still applicable to Docker Engine - Enterprise 18.09 - inter-container communication (icc)* (CIS Docker Benchmark Recommendation 2.1) - insecure registry communication (CIS Docker Benchmark Recommendation 2.4) - AUFS storage driver (applicable on Linux only) (CIS Docker Benchmark Recommendation 2.5) - listening on the TCP Daemon socket - userland proxy for loopback traffic* (CIS Docker Benchmark Recommendation 2.15) - experimental features (CIS Docker Benchmark Recommendation 2.17) - Swarm Mode (CIS Docker Benchmark Recommendation 7.1) (Docker Engine - Enterprise: As part of a UCP cluster) - insecure registry communication (CIS Docker Benchmark Recommendation 2.4) - AUFS storage driver (applicable on Linux only) (CIS Docker Benchmark Recommendation 2.5) - listening on the TCP Daemon socket - experimental features (CIS Docker Benchmark Recommendation 2.17) (UCP) - Managed user database - self-signed certificates - periodic usage reporting and API tracking - allow users and administrators to schedule containers on all nodes, including UCP managers and DTR nodes (DTR) - periodic data usage/analytics reporting - create repository on push - self-signed certificates

The aufs storage driver is the oldest storage driver. It is based on a Linux kernel patch-set that is unlikely to be merged into the main Linux kernel. aufs driver is also known to cause some serious kernel crashes. aufs just has legacy support from Docker. Most importantly, aufs is not a supported driver in many Linux distributions using latest Linux kernels. Docker Enterprise includes the following capabilities that are considered non-essential: *NOTE: disabling these capabilities negatively affects the operation of Universal Control Plane (UCP) and Docker Trusted Registry (DTR) and should be disregarded when UCP and DTR are installed. The security capabilities provided by UCP and DTR offset any potential vulnerabilities associated with not disabling these essential capabilities the Engine provides. (Docker Engine - Enterprise: Standalone) - The majority of these items were originally identified as part of the CIS Docker Benchmark, which as of the CIS Docker Benchmark v1.2.0, are still applicable to Docker Engine - Enterprise 18.09 - inter-container communication (icc)* (CIS Docker Benchmark Recommendation 2.1) - insecure registry communication (CIS Docker Benchmark Recommendation 2.4) - AUFS storage driver (applicable on Linux only) (CIS Docker Benchmark Recommendation 2.5) - listening on the TCP Daemon socket - userland proxy for loopback traffic* (CIS Docker Benchmark Recommendation 2.15) - experimental features (CIS Docker Benchmark Recommendation 2.17) - Swarm Mode (CIS Docker Benchmark Recommendation 7.1) (Docker Engine - Enterprise: As part of a UCP cluster) - insecure registry communication (CIS Docker Benchmark Recommendation 2.4) - AUFS storage driver (applicable on Linux only) (CIS Docker Benchmark Recommendation 2.5) - listening on the TCP Daemon socket - experimental features (CIS Docker Benchmark Recommendation 2.17) (UCP) - Managed user database - self-signed certificates - periodic usage reporting and API tracking - allow users and administrators to schedule containers on all nodes, including UCP managers and DTR nodes (DTR) - periodic data usage/analytics reporting - create repository on push - self-signed certificates

The docker daemon starts a userland proxy service for port forwarding whenever a port is exposed. Where hairpin NAT is available, this service is generally superfluous to requirements and can be disabled. Docker engine provides two mechanisms for forwarding ports from the host to containers, hairpin NAT, and a userland proxy. In most circumstances, the hairpin NAT mode is preferred as it improves performance and makes use of native Linux iptables functionality instead of an additional component. Where hairpin NAT is available, the userland proxy should be disabled on startup to reduce the attack surface of the installation. Docker Enterprise includes the following capabilities that are considered non-essential: *NOTE: disabling these capabilities negatively affects the operation of Universal Control Plane (UCP) and Docker Trusted Registry (DTR) and should be disregarded when UCP and DTR are installed. The security capabilities provided by UCP and DTR offset any potential vulnerabilities associated with not disabling these essential capabilities the Engine provides. (Docker Engine - Enterprise: Standalone) - The majority of these items were originally identified as part of the CIS Docker Benchmark, which as of the CIS Docker Benchmark v1.2.0, are still applicable to Docker Engine - Enterprise 18.09 - inter-container communication (icc)* (CIS Docker Benchmark Recommendation 2.1) - insecure registry communication (CIS Docker Benchmark Recommendation 2.4) - AUFS storage driver (applicable on Linux only) (CIS Docker Benchmark Recommendation 2.5) - listening on the TCP Daemon socket - userland proxy for loopback traffic* (CIS Docker Benchmark Recommendation 2.15) - experimental features (CIS Docker Benchmark Recommendation 2.17) - Swarm Mode (CIS Docker Benchmark Recommendation 7.1) (Docker Engine - Enterprise: As part of a UCP cluster) - insecure registry communication (CIS Docker Benchmark Recommendation 2.4) - AUFS storage driver (applicable on Linux only) (CIS Docker Benchmark Recommendation 2.5) - listening on the TCP Daemon socket - experimental features (CIS Docker Benchmark Recommendation 2.17) (UCP) - Managed user database - self-signed certificates - periodic usage reporting and API tracking - allow users and administrators to schedule containers on all nodes, including UCP managers and DTR nodes (DTR) - periodic data usage/analytics reporting - create repository on push - self-signed certificates

Avoid experimental features in production. Docker Enterprise includes the following capabilities that are considered non-essential: *NOTE: disabling these capabilities negatively affects the operation of Universal Control Plane (UCP) and Docker Trusted Registry (DTR) and should be disregarded when UCP and DTR are installed. The security capabilities provided by UCP and DTR offset any potential vulnerabilities associated with not disabling these essential capabilities the Engine provides. (Docker Engine - Enterprise: Standalone) - The majority of these items were originally identified as part of the CIS Docker Benchmark, which as of the CIS Docker Benchmark v1.2.0, are still applicable to Docker Engine - Enterprise 18.09 - inter-container communication (icc)* (CIS Docker Benchmark Recommendation 2.1) - insecure registry communication (CIS Docker Benchmark Recommendation 2.4) - AUFS storage driver (applicable on Linux only) (CIS Docker Benchmark Recommendation 2.5) - listening on the TCP Daemon socket - userland proxy for loopback traffic* (CIS Docker Benchmark Recommendation 2.15) - experimental features (CIS Docker Benchmark Recommendation 2.17) - Swarm Mode (CIS Docker Benchmark Recommendation 7.1) (Docker Engine - Enterprise: As part of a UCP cluster) - insecure registry communication (CIS Docker Benchmark Recommendation 2.4) - AUFS storage driver (applicable on Linux only) (CIS Docker Benchmark Recommendation 2.5) - listening on the TCP Daemon socket - experimental features (CIS Docker Benchmark Recommendation 2.17) (UCP) - Managed user database - self-signed certificates - periodic usage reporting and API tracking - allow users and administrators to schedule containers on all nodes, including UCP managers and DTR nodes (DTR) - periodic data usage/analytics reporting - create repository on push - self-signed certificates

Docker Enterprise includes the following capabilities that are considered non-essential: *NOTE: disabling these capabilities negatively affects the operation of Docker Trusted Registry (DTR) and should be disregarded when UCP and DTR are installed. The security capabilities provided by UCP and DTR offset any potential vulnerabilities associated with not disabling these essential capabilities the Engine provides. (Docker Engine - Enterprise: Standalone) - The majority of these items were originally identified as part of the CIS Docker Benchmark, which as of the CIS Docker Benchmark v1.2.0, are still applicable to Docker Engine - Enterprise 18.09 - inter-container communication (icc)* (CIS Docker Benchmark Recommendation 2.1) - insecure registry communication (CIS Docker Benchmark Recommendation 2.4) - AUFS storage driver (applicable on Linux only) (CIS Docker Benchmark Recommendation 2.5) - listening on the TCP Daemon socket - userland proxy for loopback traffic* (CIS Docker Benchmark Recommendation 2.15) - experimental features (CIS Docker Benchmark Recommendation 2.17) - Swarm Mode (CIS Docker Benchmark Recommendation 7.1) (Docker Engine - Enterprise: As part of a UCP cluster) - insecure registry communication (CIS Docker Benchmark Recommendation 2.4) - AUFS storage driver (applicable on Linux only) (CIS Docker Benchmark Recommendation 2.5) - listening on the TCP Daemon socket - experimental features (CIS Docker Benchmark Recommendation 2.17) (UCP) - Managed user database - self-signed certificates - periodic usage reporting and API tracking - allow users and administrators to schedule containers on all nodes, including UCP managers and DTR nodes (DTR) - periodic data usage/analytics reporting - create repository on push - self-signed certificates

Docker Enterprise includes the following capabilities that are considered non-essential: *NOTE: disabling these capabilities negatively affects the operation of Universal Control Plane (UCP) and DTR and should be disregarded when UCP and DTR are installed. The security capabilities provided by UCP and DTR offset any potential vulnerabilities associated with not disabling these essential capabilities the Engine provides. (Docker Engine - Enterprise: Standalone) - The majority of these items were originally identified as part of the CIS Docker Benchmark, which as of the CIS Docker Benchmark v1.2.0, are still applicable to Docker Engine - Enterprise 18.09 - inter-container communication (icc)* (CIS Docker Benchmark Recommendation 2.1) - insecure registry communication (CIS Docker Benchmark Recommendation 2.4) - AUFS storage driver (applicable on Linux only) (CIS Docker Benchmark Recommendation 2.5) - listening on the TCP Daemon socket - userland proxy for loopback traffic* (CIS Docker Benchmark Recommendation 2.15) - experimental features (CIS Docker Benchmark Recommendation 2.17) - Swarm Mode (CIS Docker Benchmark Recommendation 7.1) (Docker Engine - Enterprise: As part of a UCP cluster) - insecure registry communication (CIS Docker Benchmark Recommendation 2.4) - AUFS storage driver (applicable on Linux only) (CIS Docker Benchmark Recommendation 2.5) - listening on the TCP Daemon socket - experimental features (CIS Docker Benchmark Recommendation 2.17) (UCP) - Managed user database - self-signed certificates - periodic usage reporting and API tracking - allow users and administrators to schedule containers on all nodes, including UCP managers and DTR nodes (DTR) - periodic data usage/analytics reporting - create repository on push - self-signed certificates

Docker Enterprise includes the following capabilities that are considered non-essential: *NOTE: disabling these capabilities negatively affects the operation of UCP and DTR and should be disregarded when UCP and DTR are installed. The security capabilities provided by UCP and DTR offset any potential vulnerabilities associated with not disabling these essential capabilities the Engine provides. (Docker Engine - Enterprise: Standalone) - The majority of these items were originally identified as part of the CIS Docker Benchmark, which as of the CIS Docker Benchmark v1.2.0, are still applicable to Docker Engine - Enterprise 18.09 - inter-container communication (icc)* (CIS Docker Benchmark Recommendation 2.1) - insecure registry communication (CIS Docker Benchmark Recommendation 2.4) - AUFS storage driver (applicable on Linux only) (CIS Docker Benchmark Recommendation 2.5) - listening on the TCP Daemon socket - userland proxy for loopback traffic* (CIS Docker Benchmark Recommendation 2.15) - experimental features (CIS Docker Benchmark Recommendation 2.17) - Swarm Mode (CIS Docker Benchmark Recommendation 7.1) (Docker Engine - Enterprise: As part of a UCP cluster) - insecure registry communication (CIS Docker Benchmark Recommendation 2.4) - AUFS storage driver (applicable on Linux only) (CIS Docker Benchmark Recommendation 2.5) - listening on the TCP Daemon socket - experimental features (CIS Docker Benchmark Recommendation 2.17) (UCP) - Managed user database - self-signed certificates - periodic usage reporting and API tracking - allow users and administrators to schedule containers on all nodes, including UCP managers and DTR nodes (DTR) - periodic data usage/analytics reporting - create repository on push - self-signed certificates

Docker Enterprise includes the following capabilities that are considered non-essential: *NOTE: disabling these capabilities negatively affects the operation of Universal Control Plane (UCP) and DTR and should be disregarded when UCP and DTR are installed. The security capabilities provided by UCP and DTR offset any potential vulnerabilities associated with not disabling these essential capabilities the Engine provides. (Docker Engine - Enterprise: Standalone) - The majority of these items were originally identified as part of the CIS Docker Benchmark, which as of the CIS Docker Benchmark v1.2.0, are still applicable to Docker Engine - Enterprise 18.09 - inter-container communication (icc)* (CIS Docker Benchmark Recommendation 2.1) - insecure registry communication (CIS Docker Benchmark Recommendation 2.4) - AUFS storage driver (applicable on Linux only) (CIS Docker Benchmark Recommendation 2.5) - listening on the TCP Daemon socket - userland proxy for loopback traffic* (CIS Docker Benchmark Recommendation 2.15) - experimental features (CIS Docker Benchmark Recommendation 2.17) - Swarm Mode (CIS Docker Benchmark Recommendation 7.1) (Docker Engine - Enterprise: As part of a UCP cluster) - insecure registry communication (CIS Docker Benchmark Recommendation 2.4) - AUFS storage driver (applicable on Linux only) (CIS Docker Benchmark Recommendation 2.5) - listening on the TCP Daemon socket - experimental features (CIS Docker Benchmark Recommendation 2.17) (UCP) - Managed user database - self-signed certificates - periodic usage reporting and API tracking - allow users and administrators to schedule containers on all nodes, including UCP managers and DTR nodes (DTR) - periodic data usage/analytics reporting - create repository on push - self-signed certificates

Docker Enterprise includes the following capabilities that are considered non-essential: *NOTE: disabling these capabilities negatively affects the operation of UCP and Docker Trusted Registry (DTR) and should be disregarded when UCP and DTR are installed. The security capabilities provided by UCP and DTR offset any potential vulnerabilities associated with not disabling these essential capabilities the Engine provides. (Docker Engine - Enterprise: Standalone) - The majority of these items were originally identified as part of the CIS Docker Benchmark, which as of the CIS Docker Benchmark v1.2.0, are still applicable to Docker Engine - Enterprise 18.09 - inter-container communication (icc)* (CIS Docker Benchmark Recommendation 2.1) - insecure registry communication (CIS Docker Benchmark Recommendation 2.4) - AUFS storage driver (applicable on Linux only) (CIS Docker Benchmark Recommendation 2.5) - listening on the TCP Daemon socket - userland proxy for loopback traffic* (CIS Docker Benchmark Recommendation 2.15) - experimental features (CIS Docker Benchmark Recommendation 2.17) - Swarm Mode (CIS Docker Benchmark Recommendation 7.1) (Docker Engine - Enterprise: As part of a UCP cluster) - insecure registry communication (CIS Docker Benchmark Recommendation 2.4) - AUFS storage driver (applicable on Linux only) (CIS Docker Benchmark Recommendation 2.5) - listening on the TCP Daemon socket - experimental features (CIS Docker Benchmark Recommendation 2.17) (UCP) - Managed user database - self-signed certificates - periodic usage reporting and API tracking - allow users and administrators to schedule containers on all nodes, including UCP managers and DTR nodes (DTR) - periodic data usage/analytics reporting - create repository on push - self-signed certificates

Docker Enterprise includes the following capabilities that are considered non-essential: *NOTE: disabling these capabilities negatively affects the operation of Universal Control Plane (UCP) and DTR and should be disregarded when UCP and DTR are installed. The security capabilities provided by UCP and DTR offset any potential vulnerabilities associated with not disabling these essential capabilities the Engine provides. (Docker Engine - Enterprise: Standalone) - The majority of these items were originally identified as part of the CIS Docker Benchmark, which as of the CIS Docker Benchmark v1.2.0, are still applicable to Docker Engine - Enterprise 18.09 - inter-container communication (icc)* (CIS Docker Benchmark Recommendation 2.1) - insecure registry communication (CIS Docker Benchmark Recommendation 2.4) - AUFS storage driver (applicable on Linux only) (CIS Docker Benchmark Recommendation 2.5) - listening on the TCP Daemon socket - userland proxy for loopback traffic* (CIS Docker Benchmark Recommendation 2.15) - experimental features (CIS Docker Benchmark Recommendation 2.17) - Swarm Mode (CIS Docker Benchmark Recommendation 7.1) (Docker Engine - Enterprise: As part of a UCP cluster) - insecure registry communication (CIS Docker Benchmark Recommendation 2.4) - AUFS storage driver (applicable on Linux only) (CIS Docker Benchmark Recommendation 2.5) - listening on the TCP Daemon socket - experimental features (CIS Docker Benchmark Recommendation 2.17) (UCP) - Managed user database - self-signed certificates - periodic usage reporting and API tracking - allow users and administrators to schedule containers on all nodes, including UCP managers and DTR nodes (DTR) - periodic data usage/analytics reporting - create repository on push - self-signed certificates

AppArmor protects the Ubuntu OS and applications from various threats by enforcing security policy which is also known as AppArmor profile. The user can create their own AppArmor profile for containers or use the Docker's default AppArmor profile. This would enforce security policies on the containers as defined in the profile. By default, docker-default AppArmor profile is applied for running containers and this profile can be found at /etc/apparmor.d/docker.

SELinux provides a Mandatory Access Control (MAC) system on RHEL and CentOS that greatly augments the default Discretionary Access Control (DAC) model. The user can thus add an extra layer of safety by enabling SELinux on the RHEL or CentOS host. By default, no SELinux security options are applied on containers.

By default, Docker starts containers with a restricted set of Linux Kernel Capabilities. It means that any process may be granted the required capabilities instead of root access. Using Linux Kernel Capabilities, the processes do not have to run as root for almost all the specific areas where root privileges are usually needed. Docker supports the addition and removal of capabilities, allowing the use of a non-default profile. This may make Docker more secure through capability removal, or less secure through the addition of capabilities. It is thus recommended to remove all capabilities except those explicitly required for the user's container process. By default, below capabilities are available for Linux containers: AUDIT_WRITE CHOWN DAC_OVERRIDE FOWNER FSETID KILL MKNOD NET_BIND_SERVICE NET_RAW SETFCAP SETGID SETPCAP SETUID SYS_CHROOT

Using the --privileged flag gives all Linux Kernel Capabilities to the container thus overwriting the --cap-add and --cap-drop flags. Ensure that it is not used. The --privileged flag gives all capabilities to the container, and it also lifts all the limitations enforced by the device cgroup controller. In other words, the container can then do almost everything that the host can do. This flag exists to allow special use-cases, like running Docker within Docker.

SSH server should not be running within the container. The user should instead use Universal Control Plane (UCP) to console in to running containers. Running SSH within the container increases the complexity of security management by making it: - Difficult to manage access policies and security compliance for SSH server - Difficult to manage keys and passwords across various containers - Difficult to manage security upgrades for SSH server - It is possible to have shell access to a container without using SSH, the needlessly increasing the complexity of security management should be avoided By default, SSH server is not running inside the container. Only one process per container is allowed.

Dockerfile for a container image defines the ports to be opened by default on a container instance. The list of ports may or may not be relevant to the application running within the container. A container can be run just with the ports defined in the Dockerfile for its image or can be arbitrarily passed run time parameters to open a list of ports. Additionally, over time, Dockerfile may undergo various changes and the list of exposed ports may or may not be relevant to the application running within the container. Opening unneeded ports increase the attack surface of the container and the containerized application. As a recommended practice, do not open unneeded ports. By default, all the ports that are listed in the Dockerfile under EXPOSE instruction for an image are opened when a container is run with -P or --publish-all flag.

By default, all containers on a Docker host share the resources equally. By using the resource management capabilities of Docker host, such as memory limit, the amount of memory that a container may consume can be controlled. By default, container can use all of the memory on the host. The user can use memory limit mechanism to prevent a denial of service arising from one container consuming all of the host’s resources such that other containers on the same host cannot perform their intended functions. Having no limit on memory can lead to issues where one container can easily make the whole system unstable, and as a result, unusable. By default, all containers on a Docker host share the resources equally. No memory limits are enforced.

Mount propagation mode allows mounting volumes in shared, slave or private mode on a container. Do not use shared mount propagation mode until needed. A shared mount is replicated at all mounts and the changes made at any mount point are propagated to all mounts. Mounting a volume in shared mode does not restrict any other container to mount and make changes to that volume. This unintended volume changes could potentially impact data hosted on the mounted volume. Do not set mount propagation mode to shared until needed. By default, the container mounts are private.

UTS namespaces provide isolation of two system identifiers: the hostname and the NIS domain name. It is used for setting the hostname and the domain that is visible to running processes in that namespace. Processes running within containers do not typically require to know hostname and domain name. Hence, the namespace should not be shared with the host. Sharing the UTS namespace with the host provides full permission to the container to change the hostname of the host. This must not be allowed. By default, all containers have the UTS namespace enabled and host UTS namespace is not shared with any container.

Do not docker exec with --user option. Using --user option in docker exec executes the command within the container as that user. Do not run docker exec with the --user option , especially when running containers with dropped capabilities or with enhanced restrictions. For example, suppose the container is running as tomcat user (or any other non-root user), it would be possible to run a command through docker exec as rootwith --user=root option. By default, docker exec command runs without --user option.

It is possible to attach to a particular cgroup on container run. Confirming cgroup usage would ensure that containers are running under defined cgroups. System administrators typically define cgroups under which containers are supposed to run. Even if cgroups are not explicitly defined by the system administrators, containers run under docker cgroup by default. At run-time, it is possible to attach to a different cgroup other than the one that was expected to be used. This usage should be monitored and confirmed. By attaching to a different cgroup than the one that is expected, excess permissions and resources might be granted to the container and thus, can prove to be unsafe. By default, containers run under docker cgroup.

By default, Docker containers can make connections to the outside world, but the outside world cannot connect to containers. Each outgoing connection will appear to originate from one of the host machine's own IP addresses. Only allow container services to be contacted through a specific external interface on the host machine. If there are multiple network interfaces on the host machine, the container can accept connections on the exposed ports on any network interface. This might not be desired and may not be secured. Many times, a particular interface is exposed externally and services such as intrusion detection, intrusion prevention, firewall, load balancing, etc. are run on those interfaces to screen incoming public traffic. Hence, do not accept incoming connections on any interface. Only allow incoming connections from a particular external interface. By default, Docker exposes the container ports on 0.0.0.0, the wildcard IP address that will match any possible incoming network interface on the host machine.

Both the Universal Control Plane (UCP) and Docker Trusted Registry (DTR) components of Docker Enterprise leverage the same authentication and authorization backplane known as eNZi. The eNZi backplane includes its own managed user database, and also allows for LDAP and SAML integration in UCP and DTR. To meet the requirements of this control, configure LDAP and SAML integration. Satisfies: SRG-APP-000149, SRG-APP-000150, SRG-APP-000151, SRG-APP-000152, SRG-APP-000153, SRG-APP-000391, SRG-APP-000392, SRG-APP-000402, SRG-APP-000403, SRG-APP-000404, SRG-APP-000405

Both the UCP and Docker Trusted Registry (DTR) components of Docker Enterprise leverage the same authentication and authorization backplane known as eNZi. UCP has the ability to use external certificates or internal self-signed. In the case of self-signed UCP includes a certificate authority which is used to sign client bundles and to authenticate users via the eNZi backplane. With an external certificate authority (CA) users will use their existing x509 certs. The external CA will be added in an administrative function and will dictate the root CA for the user's chain.

Use Docker's in-built secret management commands for managing sensitive data that which can be stored in key/value pairs. Examples include API tokens, database connection strings and credentials, SSL certificates, and the like.

The Universal Control Plane (UCP) component of Docker Enterprise includes a built-in access authorization mechanism called eNZi which can be integrated with an LDAP server and subsequently terminate all network connections associated with a communications session at the end of the session, or as follows: for in-band management sessions (privileged sessions), the session must be terminated after 10 minutes of inactivity; and for user sessions (non-privileged session), the session must be terminated after 15 minutes of inactivity, except to fulfill documented and validated mission requirements. The lifetime minutes login session control is configured with a default of 60 minutes (1 hour) and the renewal threshold minutes is configured with a default of 20 minutes. For reference, the lifetime login session control in UCP specifies the initial lifetime (in minutes) of a session from the moment it is generated. The renewal threshold setting indicates a period of time (in minutes) before the expiration of a session where, if used, a session will be extended by the current configured lifetime from then. This value cannot be greater than the configured lifetime. A value equal to the lifetime means that sessions will be extended with every use. A value of zero indicates that sessions should never be extended but this may result in unexpectedly being logged out if the session expires while performing a series of actions in the UI. This configuration only applies to both the UCP and Docker Trusted Registry (DTR) management consoles and not when connecting via the command line. When connecting via the command line, this control is not applicable. It's important to note that the notion of a session varies depending on how one is connecting to a UCP cluster or DTR. In all of these cases, there is no specific session termination capability. Either the session times out, the user's client bundle has expired, or a user explicitly logs out. This has been outlined as follows: (UCP and DTR UIs) When connecting to a UCP cluster or DTR via the web console, a user's session is active until any of the following conditions is met: - the session expires based on the values configured for "Lifetime Minutes" and "Renewal Threshold Minutes" in the UCP Admin Settings - the user explicitly clicks the "Sign Out" button (UCP and DTR CLIs) When connecting to a UCP cluster or DTR via the command line using a client bundle, a user's session is active until any of the following conditions is met: - the certificate contained within a user's client bundle hasn't expired - the public key in the certificate contained with a user's client bundle is no long associated with that user (i.e. a client bundle is revoked from within the UCP user management options) - the user's account is no longer active (either explicitly disabled from within the UCP user management options or at the LDAP server) - the user's password is changed Satisfies: SRG-APP-000190, SRG-APP-000002, SRG-APP-000003, SRG-APP-000295, SRG-APP-000389, SRG-APP-000400

By leveraging Docker Secrets or Kubernetes secrets to store configuration files and small amounts of user-generated data (up to 500 kb in size), the data is encrypted at rest by the Engine's FIPS-validated cryptography.

If the container image does not have an HEALTHCHECK instruction defined, use --health-cmd parameter at container runtime for checking container health. One of the important security triads is availability. If the container image being used does not have a pre-defined HEALTHCHECK instruction, use the --health-cmd parameter to check container health at runtime. Based on the reported health status, take necessary actions. By default, health checks are not done at container runtime.

Use --pids-limit flag at container runtime. Attackers could launch a fork bomb with a single command inside the container. This fork bomb can crash the entire system and requires a restart of the host to make the system functional again. PIDs cgroup --pids-limit will prevent this kind of attacks by restricting the number of forks that can happen inside a container at a given time. The Default value for --pids-limit is 0 which means there is no restriction on the number of forks. Also, note that PIDs cgroup limit works only for the kernel versions 4.3+.

Both the Universal Control Plane (UCP) and Docker Trusted Registry (DTR) components of Docker Enterprise leverage the same authentication and authorization backplane known as eNZi. The eNZi backplane includes its own managed user database, and also allows for LDAP integration in UCP and DTR. To meet the requirements of this control, configure LDAP integration. Apply an applicable set of role-based access control (RBAC) policies using the built-in capabilities provided by UCP in order to prevent organization-defined software from executing at higher privilege levels than users executing the software. By default, Docker images that are built without the USER instruction will be run as containers as root. Therefore, it is imperative that container images include the USER instruction and that the referenced UID/GID has been defined in the base image or previous instruction set.

The UCP and DTR components of Docker Enterprise provide audit record generation capabilities. Audit logs capture all HTTP actions for the following endpoints: Kubernetes API, Swarm API and UCP API. The following UCP API endpoints are excluded from audit logging (where "*" designates a wildcard of exclusions): "/_ping", "/ca", "/auth", "/trustedregistryca", "/kubeauth", "/metrics", "/info", "/version*", "/debug", "/openid_keys", "/apidocs", "kubernetesdocs" and "/manage". Audit log verbosity can be set to one of the following levels: "none", "metadata", or "request". To meet the requirements of this control, the "request" verbosity level must be configured in UCP. The data captured at each level for UCP and the eNZI authentication and authorization backplane is described below: "none": audit logging is disabled "metadata": - method and API endpoint for the request - UCP user which made the request - response status (success/failure) - timestamp of the call - object ID of created/updated resource (for create/update calls) - license key - remote address "request": includes all fields from the "metadata" level, as well as the request payload DTR audits all events associated with repository activities. Events are considered as follows: create, get, delete, update, send, fail, and scan. The following types are associated with the defined audit events: repository, tag, blob, manifest, webhook, uri, promotion, push mirroring, poll mirroring, garbage collector, system. All audit logs generated by UCP and DTR can be forwarded to a remote log aggregation system by configuring an appropriate log driver plugin on all Docker Engine - Enterprise nodes in a cluster. The Docker Engine - Enterprise component of Docker Enterprise relies on the underlying host operating system's auditing capabilities. By default, the host OS is not configured to audit Docker Engine - Enterprise. Satisfies: SRG-APP-000343, SRG-APP-000381, SRG-APP-000492, SRG-APP-000493, SRG-APP-000494, SRG-APP-000495, SRG-APP-000496, SRG-APP-000497, SRG-APP-000498, SRG-APP-000499, SRG-APP-000501, SRG-APP-000502, SRG-APP-000503, SRG-APP-000504, SRG-APP-000505, SRG-APP-000506, SRG-APP-000507, SRG-APP-000508, SRG-APP-000509, SRG-APP-000510, SRG-APP-000500

By default, the UCP and DTR components of Docker Enterprise leverage the "json-file" Engine logging driver. This driver has configurable "max-size" and "max-file" options which are applicable in the context of this control. The "max-size" option defines the maximum size of the log before it is rolled. By default it is set to "unlimited" and is never rolled. The "max-file" option defines the maximum number of log files that can be present whereby if rolling the logs creates excess files, the oldest file is removed. This setting is only effective when "max-size" is also set. By default, "max-file" is set to "1". The Docker Engine - Enterprise audit logs are stored in default locations according to the chart on this site https://docs.docker.com/config/daemon/#read-the-logs. For the Engine's daemon logs, allocate sufficient storage for the default log locations on the underlying host operating system per the requirements set forth by the SSP.

The Universal Control Plane (UCP) and Docker Trusted Registry (DTR) components of Docker Enterprise provide audit record generation capabilities. Audit logs capture all HTTP actions for the following endpoints: Kubernetes API, Swarm API and UCP API. The following UCP API endpoints are excluded from audit logging (where "*" designates a wildcard of exclusions): "/_ping", "/ca", "/auth", "/trustedregistryca", "/kubeauth", "/metrics", "/info", "/version*", "/debug", "/openid_keys", "/apidocs", "kubernetesdocs" and "/manage". Audit log verbosity can be set to one of the following levels: "none", "metadata", or "request". To meet the requirements of this control, the "request" verbosity level must be configured in UCP. The data captured at each level for UCP and the eNZI authentication and authorization backplane is described below: "none": audit logging is disabled "metadata": - method and API endpoint for the request - UCP user which made the request - response status (success/failure) - timestamp of the call - object ID of created/updated resource (for create/update calls) - license key - remote address "request": includes all fields from the "metadata" level, as well as the request payload DTR audits all events associated with repository activities. Events are considered as follows: create, get, delete, update, send, fail, and scan. The following types are associated with the defined audit events: repository, tag, blob, manifest, webhook, uri, promotion, push mirroring, poll mirroring, garbage collector, system. All audit logs generated by UCP and DTR can be forwarded to a remote log aggregation system by configuring an appropriate log driver plugin on all Docker Engine - Enterprise nodes in a cluster. The Docker Engine - Enterprise component of Docker Enterprise relies on the underlying host operating system's auditing capabilities. By default, the host OS is not configured to audit Docker Engine - Enterprise.

The Universal Control Plane (UCP) and Docker Trusted Registry (DTR) components of Docker Enterprise provide audit record generation capabilities. Audit logs capture all HTTP actions for the following endpoints: Kubernetes API, Swarm API and UCP API. The following UCP API endpoints are excluded from audit logging (where "*" designates a wildcard of exclusions): "/_ping", "/ca", "/auth", "/trustedregistryca", "/kubeauth", "/metrics", "/info", "/version*", "/debug", "/openid_keys", "/apidocs", "kubernetesdocs" and "/manage". Audit log verbosity can be set to one of the following levels: "none", "metadata", or "request". To meet the requirements of this control, the "request" verbosity level must be configured in UCP. The data captured at each level for UCP and the eNZI authentication and authorization backplane is described below: "none": audit logging is disabled "metadata": - method and API endpoint for the request - UCP user which made the request - response status (success/failure) - timestamp of the call - object ID of created/updated resource (for create/update calls) - license key - remote address "request": includes all fields from the "metadata" level, as well as the request payload DTR audits all events associated with repository activities. Events are considered as follows: create, get, delete, update, send, fail, and scan. The following types are associated with the defined audit events: repository, tag, blob, manifest, webhook, uri, promotion, push mirroring, poll mirroring, garbage collector, system. All audit logs generated by UCP and DTR can be forwarded to a remote log aggregation system by configuring an appropriate log driver plugin on all Docker Engine - Enterprise nodes in a cluster. The Docker Engine - Enterprise component of Docker Enterprise relies on the underlying host operating system's auditing capabilities. By default, the host OS is not configured to audit Docker Engine - Enterprise.

The Universal Control Plane (UCP) and Docker Trusted Registry (DTR) components of Docker Enterprise provide audit record generation capabilities. Audit logs capture all HTTP actions for the following endpoints: Kubernetes API, Swarm API and UCP API. The following UCP API endpoints are excluded from audit logging (where "*" designates a wildcard of exclusions): "/_ping", "/ca", "/auth", "/trustedregistryca", "/kubeauth", "/metrics", "/info", "/version*", "/debug", "/openid_keys", "/apidocs", "kubernetesdocs" and "/manage". Audit log verbosity can be set to one of the following levels: "none", "metadata", or "request". To meet the requirements of this control, the "request" verbosity level must be configured in UCP. The data captured at each level for UCP and the eNZI authentication and authorization backplane is described below: "none": audit logging is disabled "metadata": - method and API endpoint for the request - UCP user which made the request - response status (success/failure) - timestamp of the call - object ID of created/updated resource (for create/update calls) - license key - remote address "request": includes all fields from the "metadata" level, as well as the request payload DTR audits all events associated with repository activities. Events are considered as follows: create, get, delete, update, send, fail, and scan. The following types are associated with the defined audit events: repository, tag, blob, manifest, webhook, uri, promotion, push mirroring, poll mirroring, garbage collector, system. All audit logs generated by UCP and DTR can be forwarded to a remote log aggregation system by configuring an appropriate log driver plugin on all Docker Engine - Enterprise nodes in a cluster. The Docker Engine - Enterprise component of Docker Enterprise relies on the underlying host operating system's auditing capabilities. By default, the host OS is not configured to audit Docker Engine - Enterprise.

A Docker image is analogous to software in the context of this control. All components of Docker Enterprise can be configured to send logs to a remote syslog server in order to meet the requirements of this control. Universal Control Plane (UCP) remote syslog configuration is done via the UCP configuration settings. Docker Trusted Registry (DTR) remote syslog configuration is done via an appropriate Docker Engine - Enterprise logging driver. The UCP and DTR components of Docker Enterprise provide audit record generation capabilities. Audit logs capture all HTTP actions for the following endpoints: Kubernetes API, Swarm API and UCP API. The following UCP API endpoints are excluded from audit logging (where "*" designates a wildcard of exclusions): "/_ping", "/ca", "/auth", "/trustedregistryca", "/kubeauth", "/metrics", "/info", "/version*", "/debug", "/openid_keys", "/apidocs", "kubernetesdocs" and "/manage". Audit log verbosity can be set to one of the following levels: "none", "metadata", or "request". To meet the requirements of this control, the "request" verbosity level must be configured in UCP. The data captured at each level for UCP and the eNZI authentication and authorization backplane is described below: "none": audit logging is disabled "metadata": - method and API endpoint for the request - UCP user which made the request - response status (success/failure) - timestamp of the call - object ID of created/updated resource (for create/update calls) - license key - remote address "request": includes all fields from the "metadata" level, as well as the request payload DTR audits all events associated with repository activities. Events are considered as follows: create, get, delete, update, send, fail, and scan. The following types are associated with the defined audit events: repository, tag, blob, manifest, webhook, uri, promotion, push mirroring, poll mirroring, garbage collector, system.

By itself, Docker Engine - Enterprise is configured by default to listen for API requests via a UNIX domain socket (or IPC socket) created at /var/run/docker.sock on supported Linux distributions and via a named pipe at npipe:////./pipe/docker_engine on Windows Server 2016 and newer. In this configuration, this control is not applicable. Docker Engine - Enterprise can also be configured to listen for API requests via additional socket types, including both TCP and FD (only on supported systemd-based Linux distributions). If configured to listen for API requests via the TCP socket type over TCP port 2376 and with the daemon flags and SSL certificates, then, at a minimum, TLS 1.2 is used for encryption; therefore this control is applicable and is inherently met in this configuration. If configured to listen for API requests via the TCP socket type, but without TLS verification and certifications, then the instance remains vulnerable and is not properly configured to meet the requirements of this control. If configured to listen for API requests via the fd socket type, then this control is not applicable. More information can be found at https://docs.docker.com/engine/reference/commandline/dockerd/#daemon-socket-option. The TCP socket binding should be disabled when running Engine as part of a UCP cluster. A container can be run just with the ports defined in the Dockerfile for its image or can be arbitrarily passed run time parameters to open a list of ports. Additionally, over time, Dockerfiles may undergo various changes and the list of exposed ports may or may not be relevant to the application running within the container. Opening unneeded ports increase the attack surface of the container and the containerized application. Per the requirements set forth by the System Security Plan (SSP), ensure only needed ports are open on all running containers.

The UCP and Docker Trusted Registry (DTR) components of Docker Enterprise can be used in concert to perform an integrity check of organization-defined software at startup. In the context of Docker Enterprise, software would be analogous to Docker images that have been pulled from trusted or untrusted sources. Docker Hub is the most common upstream endpoint for retrieving Docker images. However, only "Docker Certified" images on Docker Hub are considered trusted and come with SLAs and trusted signatures from their respective vendors. All other images from Docker Hub or other external registries must be carefully inspected and triaged prior to use. Docker Content Trust (DCT) provides for content integrity checking mechanisms on Docker images. DCT can be combined with LDAP, Docker Trusted Registry (DTR) and Universal Control Plane (UCP) to enforce image signatures from users/accounts in LDAP. Therefore, to meet the requirements of this control, it is imperative that UCP has LDAP integration enabled and that content trust enforcement is enabled and properly configured. An operational requirement of this control is that of the required use of an established continuous integration and deployment workflow that effectively dictates exactly what software is allowed to run on UCP.

The UCP and Docker Trusted Registry (DTR) components of Docker Enterprise can be used in concert to perform an integrity check of organization-defined software at startup. In the context of Docker Enterprise, software would be analogous to Docker images that have been pulled from trusted or untrusted sources. Docker Hub is the most common upstream endpoint for retrieving Docker images. However, only "Docker Certified" images on Docker Hub are considered trusted and come with SLAs and trusted signatures from their respective vendors. All other images from Docker Hub or other external registries must be carefully inspected and triaged prior to use. Docker Content Trust (DCT) provides for content integrity checking mechanisms on Docker images. DCT can be combined with LDAP, DTR and UCP to enforce image signatures from users/accounts in LDAP. Therefore, to meet the requirements of this control, it is imperative that UCP has LDAP integration enabled and that content trust enforcement is enabled and properly configured. An operational requirement of this control is that of the required use of an established continuous integration and deployment workflow that effectively dictates exactly what software is allowed to run on UCP. Satisfies: SRG-APP-000386, SRG-APP-000480, SRG-APP-000484, SRG-APP-000485, SRG-APP-000475

DTR can scan Docker images for vulnerabilities and this capability should be enabled to meet the requirements of this control. When enabled, for every Docker image that is pushed to DTR, a scan of each of the image layers is conducted. An analysis of all packages and compiled binaries is done for each image layer and if a package or binary is associated with a known vulnerability as identified by the MITRE CVE or NIST NVD databases, then it is flagged in DTR.

Both the UCP and Docker Trusted Registry (DTR) components of Docker Enterprise leverage the same authentication and authorization backplane known as eNZi. The eNZi backplane includes its own managed user database, and also allows for LDAP integration in UCP and DTR. To meet the requirements of this control, configure LDAP integration. UCP also includes two certificate authorities for establishing root of trust. One CA is used to sign client bundles and the other is used for TLS communication between UCP components and nodes. Both of these CAs should be integrated with an external, trusted CA. DTR should be integrated with this same external, trusted CA as well.

Both the Universal Control Plane (UCP) and DTR components of Docker Enterprise leverage the same authentication and authorization backplane known as eNZi. The eNZi backplane includes its own managed user database, and also allows for LDAP integration in UCP and DTR. To meet the requirements of this control, configure LDAP integration. UCP also includes two certificate authorities for establishing root of trust. One CA is used to sign client bundles and the other is used for TLS communication between UCP components and nodes. Both of these CAs should be integrated with an external, trusted CA. DTR should be integrated with this same external, trusted CA as well.

Using the --restart flag in docker run command, specify a restart policy for how a container should or should not be restarted on exit. Choose the on-failure restart policy and limit the restart attempts to 5. If indefinitely trying to start the container, it could possibly lead to a denial of service on the host. It could be an easy way to do a distributed denial of service attack especially if there are many containers on the same host. Additionally, ignoring the exit status of the container and always attempting to restart the container leads to non-investigation of the root cause behind containers getting terminated. If a container gets terminated, investigate on the reason behind it instead of just attempting to restart it indefinitely. Thus, it is recommended to use on-failure restart policy and limit it to maximum of 5 restart attempts. The container would attempt to restart only for 5 times. By default, containers are not configured with restart policies. Hence, containers do not attempt to restart of their own.

The default ulimit is set at the Docker daemon level. However, override the default ulimit setting, if needed, during container runtime. ulimit provides control over the resources available to the shell and to processes started by it. Setting system resource limits judiciously prevents many disasters such as a fork bomb. Sometimes, even friendly users and legitimate processes can overuse system resources and in-turn can make the system unusable. The default ulimit set at the Docker daemon level should be honored. If the default ulimit settings are not appropriate for a particular container instance, override them as an exception. But, do not make this a practice. If most of the container instances are overriding default ulimit settings, consider changing the default ulimit settings to something that is appropriate for your needs. If the ulimits are not set properly, the desired resource control might not be achieved and might even make the system unusable. Container instances inherit the default ulimit settings set at the Docker daemon level.

When upgrading either the UCP or DTR components of Docker Enterprise, the newer images are pulled (or unpacked if offline) onto Engine nodes in a cluster. Once the upgrade is complete, one must manually remove all old image version from the cluster nodes to meet the requirements of this control. When upgrading the Docker Engine - Enterprise component of Docker Enterprise, the old package version is automatically replaced.

The Universal Control Plane (UCP) and DTR components of Docker Enterprise can be used in concert to perform an integrity check of organization-defined software at startup. In the context of Docker Enterprise, software would be analogous to Docker images that have been pulled from trusted or untrusted sources. Docker Hub is the most common upstream endpoint for retrieving Docker images. However, only "Docker Certified" images on Docker Hub are considered trusted and come with SLAs and trusted signatures from their respective vendors. All other images from Docker Hub or other external registries must be carefully inspected and triaged prior to use. Docker Content Trust (DCT) provides for content integrity checking mechanisms on Docker images. DCT can be combined with LDAP, DTR and UCP to enforce image signatures from users/accounts in LDAP. Therefore, to meet the requirements of this control, it is imperative that UCP has LDAP integration enabled and that content trust enforcement is enabled and properly configured. Satisfies: SRG-APP-000475, SRG-APP-000480, SRG-APP-000484, SRG-APP-000485, SRG-APP-000386

The UCP and Docker Trusted Registry (DTR) components of Docker Enterprise can be used in concert with built-in audit logging capabilities to audit detected potential integrity violations per the requirements set forth by the System Security Plan (SSP). In the context of Docker Enterprise, software would be analogous to Docker images that have been pulled from trusted or untrusted sources. Docker Hub is the most common upstream endpoint for retrieving Docker images. However, only "Docker Certified" images on Docker Hub are considered trusted and come with SLAs and trusted signatures from their respective vendors. All other images from Docker Hub or other external registries must be carefully inspected and triaged prior to use. Docker Content Trust (DCT) provides for content integrity checking mechanisms on Docker images. DCT can be combined with LDAP, DTR and UCP to enforce image signatures from users/accounts in LDAP. Therefore, to meet the requirements of this control, it is imperative that UCP has LDAP integration enabled and that content trust enforcement is enabled and properly configured. The UCP and DTR components of Docker Enterprise provide audit record generation capabilities. Audit logs capture all HTTP actions for the following endpoints: Kubernetes API, Swarm API and UCP API. The following UCP API endpoints are excluded from audit logging (where "*" designates a wildcard of exclusions): "/_ping", "/ca", "/auth", "/trustedregistryca", "/kubeauth", "/metrics", "/info", "/version*", "/debug", "/openid_keys", "/apidocs", "kubernetesdocs" and "/manage". Audit log verbosity can be set to one of the following levels: "none", "metadata", or "request". To meet the requirements of this control, the "request" verbosity level must be configured in UCP. The data captured at each level for UCP and the eNZI authentication and authorization backplane is described below: "none": audit logging is disabled "metadata": - method and API endpoint for the request - UCP user which made the request - response status (success/failure) - timestamp of the call - object ID of created/updated resource (for create/update calls) - license key - remote address "request": includes all fields from the "metadata" level, as well as the request payload DTR audits all events associated with repository activities. Events are considered as follows: create, get, delete, update, send, fail, and scan. The following types are associated with the defined audit events: repository, tag, blob, manifest, webhook, uri, promotion, push mirroring, poll mirroring, garbage collector, system. The Docker Engine - Enterprise component of Docker Enterprise relies on the underlying host operating system's auditing capabilities. By default, the host OS is not configured to audit Docker Engine - Enterprise.

Ensure that the minimum number of required manager nodes is created in a swarm. Manager nodes within a swarm have control over the swarm and change its configuration modifying security parameters. Having excessive manager nodes could render the swarm more susceptible to compromise. If fault tolerance is not required in the manager nodes, a single node should be elected as a manger. If fault tolerance is required then the smallest practical odd number to achieve the appropriate level of tolerance should be configured.

Rotate swarm manager auto-lock key periodically. Swarm manager auto-lock key is not automatically rotated. Rotate them periodically as a best practice. By default, keys are not rotated automatically.

Rotate swarm node certificates as appropriate. Docker Swarm uses mutual TLS for clustering operations amongst its nodes. Certificate rotation ensures that in an event such as compromised node or key, it is difficult to impersonate a node. By default, node certificates are rotated every 90 days. The user should rotate it more often or as appropriate in their environment. By default, node certificates are rotated automatically every 90 days.

Verify that the docker.service file permissions are correctly set to 644 or more restrictive. docker.service file contains sensitive parameters that may alter the behavior of Docker daemon. Hence, it should not be writable by any other user other than root to maintain the integrity of the file. This file may not be present on the system. In that case, this recommendation is not applicable. By default, if the file is present, the file permissions are correctly set to 644.

Verify that the docker.socket file permissions are correctly set to 644 or more restrictive. docker.socket file contains sensitive parameters that may alter the behavior of Docker remote API. Hence, it should be writable only by root to maintain the integrity of the file. This file may not be present on the system. In that case, this recommendation is not applicable. By default, if the file is present, the file permissions for this file are correctly set to 644.

Verify that the /etc/docker directory permissions are correctly set to 755 or more restrictive. /etc/docker directory contains certificates and keys in addition to various sensitive files. Hence, it should only be writable by root to maintain the integrity of the directory. By default, the permissions for this directory are correctly set to 755.

Verify that all the registry certificate files (usually found under /etc/docker/certs.d/ directory) have permissions of 444 or more restrictive. /etc/docker/certs.d/ directory contains Docker registry certificates. These certificate files must have permissions of 444 to maintain the integrity of the certificates. By default, the permissions for registry certificate files might not be 444. The default file permissions are governed by the system or user specific umaskvalues.

Verify that the TLS CA certificate file (the file that is passed along with --TLScacert parameter) has permissions of 444 or more restrictive. The TLS CA certificate file should be protected from any tampering. It is used to authenticate Docker server based on given CA certificate. Hence, it must have permissions of 444 to maintain the integrity of the CA certificate. By default, the permissions for TLS CA certificate file might not be 444. The default file permissions are governed by the system or user specific umask values.

Verify that the Docker server certificate file (the file that is passed along with --TLScert parameter) has permissions of 444 or more restrictive. The Docker server certificate file should be protected from any tampering. It is used to authenticate Docker server based on the given server certificate. Hence, it must have permissions of 444 to maintain the integrity of the certificate. By default, the permissions for Docker server certificate file might not be 444. The default file permissions are governed by the system or user specific umask values.

Verify that the Docker server certificate key file (the file that is passed along with --TLSkey parameter) is owned and group-owned by root. The Docker server certificate key file should be protected from any tampering or unneeded reads. It holds the private key for the Docker server certificate. Hence, it must be owned and group-owned by root to maintain the integrity of the Docker server certificate. By default, the ownership and group-ownership for Docker server certificate key file is correctly set to root.

When integrating the UCP and Docker Trusted Registry (DTR) management consoles with an external, trusted certificate authority (CA), both UCP and DTR will validate these certificate chains per the requirements set forth by the System Security Plan (SSP). UCP establishes mutual TLS authentication for all Engine - Enterprise nodes in a cluster using a built-in certificate authority which inherently meets the requirements of this control. This is described below. The UCP component of Docker Enterprise includes a built-in public key infrastructure (PKI) system. When a UCP cluster is initialized, the first node designates itself as a manager node. That node subsequently generates a new root CA along with a key pair, which are used to secure communications with other UCP manager and worker nodes that are joined to the cluster. One can also specify his/her own externally-generated root CA upon initialization of a UCP cluster. The manager node also generates two tokens to use when joining additional nodes to the cluster: one worker token and one manager token. Each token includes the digest of the root CA’s certificate and a randomly generated secret. When a node joins the cluster, the joining node uses the digest to validate the root CA certificate from the remote manager. The remote manager uses the secret to ensure the joining node is an approved node. Each time a new node joins the cluster, the manager issues a certificate to the node. The certificate contains a randomly generated node ID to identify the node under the certificate common name (CN) and the role under the organizational unit (OU). The node ID serves as the cryptographically secure node identity for the lifetime of the node in the current UCP cluster. In this mutual TLS architecture, all nodes encrypt communications using a minimum of TLS 1.2. This information can also be referenced at https://docs.docker.com/engine/swarm/how-swarm-mode-works/pki/.

Encrypt data exchanged between containers on different nodes on the overlay network. By default, data exchanged between containers on different nodes on the overlay network is not encrypted. This could potentially expose traffic between the container nodes.

By default, the docker swarm services will listen to all interfaces on the host, which may not be necessary for the operation of the swarm where the host has multiple network interfaces. When a swarm is initialized the default value for the --listen-addr flag is 0.0.0.0:2377 which means that the swarm services will listen on all interfaces on the host. If a host has multiple network interfaces this may be undesirable as it may expose the docker swarm services to networks which are not involved in the operation of the swarm. By passing a specific IP address to the --listen-addr, a specific network interface can be specified limiting this exposure.

By default docker UCP is configured to use TLS v1.2, if this setting is misconfigured, older protocols containing security weaknesses could be utilized. TLS requires a handshake between client and server which is where the TLS version utilized in the connection is negotiated. For DoD use cases, all TLS must be at version 1.2.

Run Docker swarm manager in auto-lock mode. When Docker restarts, both the TLS key used to encrypt communication among swarm nodes, and the key used to encrypt and decrypt Raft logs on disk, are loaded into each manager node's memory. Protect the mutual TLS encryption key and the key used to encrypt and decrypt Raft logs at rest. This protection could be enabled by initializing swarm with --autolock flag. With --autolock enabled, when Docker restarts, unlock the swarm first, using a key encryption key generated by Docker when the swarm was initialized.