Container Security Protection – Image Security
Image Security
Images are the basis of containers. Therefore, their security speaks a lot for that of the entire container ecosystem. Container images are a series of images stacked layer by layer. They are distributed and updated through image repositories. The following sections describe how to secure images from the aspects of image build security, repository security, and image distribution security.
-
Image Build Security
Generally, Docker builds images either based on containers or with Dockerfiles. The recommended practice is to create all image files with Dockerfiles because images built this way are completely transparent and all operation instructions are controllable and traceable.
Image build is exposed to the following risks:
(1) A base image pulled is not released by a trusted organization or person so as to possibly contain a backdoor or other types of risk.
(2) A Dockerfile contains sensitive information, such as fixed passwords or credentials in plaintext used in service configuration.
(3) Unnecessary software is installed, thus expanding the attack surface.
To avoid the preceding risks, image build security should be hardened from the following aspects:
(1) Verify the source of images.
To ensure that image contents are credible, users are advised to enable Docker’s content trust mechanism. This mechanism provides digital signatures for data transmitted and received by remote image repositories, allowing clients to verify the integrity and publisher of image tags. By default, content trust is disabled. Users can use the following instruction or edit the Docker configuration file to enable this mechanism:
# export DOCKER_CONTENT_TRUST=1
(2) Make images lightweight.
Installing only necessary software packages is not only of great help for enhancing container performance but, more importantly, is useful in reducing the attack surface.
(3) Properly use image instructions.
Appropriate instructions should be used to build an image. If an external file is required, COPY is preferred to ADD in a Dockerfile because the former only copies the files from the local host to the container file system, while the latter may download the file from a remote URL and perform such operations as decompression. This could bring in the risk of malicious files.
(4) Properly handle sensitive information.
Although Docker assigns read-only permissions to users, users should still exercise caution when handling data stored in containers. For example, a Dockerfile cannot store passwords, tokens, keys, and users’ privacy information, which are at risk of leakage even if being deleted immediately after the container is built. This is because such data can be retrieved from historical records of images.
A recommended practice is to use the encryption management function provided by Kubernetes and Docker Swarm to encrypt data for transmission and storage, and allow only authorized users to decrypt it at the time of search.
-
Image Repository Security
- Public Repository
Docker Hub is currently the largest platform for container image repositories. As mentioned in a previous section, over 30% of images on Docker Hub contain high-risk vulnerabilities. Therefore, while enjoying the convenience brought by Docker Hub, users should do as follows to ensure the security of images:
- Use the latest images officially released and update them regularly.
- Scan and assess images that are downloaded for vulnerabilities.
- Perform OS-level and application-level scanning for images that provide services.
- When public Dockerfiles are available, preferably create images with such a Dockerfile to avoid image backdoors and ensure the controllability of the image building process.
- Private Repository
(1) Docker Registry
Docker Registry[I] is an open-source tool officially provided by Docker to help developers build private image repositories rapidly. The security of Docker Registry should be considered from the following aspects:
Security of Docker Registry itself. For example, when using the Registry, users should configure it to use a security certificate.
Security of the interaction between Docker clients and Docker Registry. This requires exercise of user access control. Private repositories exposed on the Internet usually grant the access permission only to specific organizations. In this case, it is insufficient to only verify the certificate of the Registry. Configuring passwords or bidirectional SSL is also required to verify the identity of Docker clients that interact with repositories.
(2) VMware Harbor
Users should do as follows when deploying Harbor in their production environments:
- Enable HTTPS and do not use the default password provided in cfg.
- Modify source code by adding a brute-force cracking protection mechanism to prevent passwords from being cracked as Harbor does not include such a mechanism to secure user login.
- Strictly control mounted volume permissions, which can be rw (default) or ro (optional).
-
Image Scanning
Containers are started from locally stored images for fast execution. Therefore, the security of images is directly linked with that of containers. While images downloaded from public repositories are exposed to security risks, as mentioned before, locally built images are not impervious due to the possible use of third-party libraries. Therefore, it is especially important to scan both downloaded and locally created images for security issues.
Image scanning engines that are currently popular include Docker Security Scanning (non-open-source), Clair (open-source), and Anchore (open-source).
Nowadays, image checking still revolves around known CVE vulnerabilities in systems. After capturing an image, the scanner separates it into layers and obtains a software package from each layer. Then it compares these packages with those in the CVE databases in terms of the name and version to determine whether they are vulnerable.
There are other schemes that identify malicious images by scanning environment variables, operation commands, and open ports in images. However, they do not directly tell whether an image is malicious, but require users to make a judgment based on the scanning result.
Overall, current so-called mature detection schemes are still limited and have much room for further development and improvement.
-
Image Distribution Security
When downloading and uploading container images, we should ensure their integrity and confidentiality. For this purpose, these tips should be followed to help withstand security threats such as man-in-the-middle attacks:
(1) Digital signature
The uploader adds a signature in the image to be uploaded. The downloader, after obtaining the image, should first verify its signature before use for fear that the image may be tampered with by malevolent actors.
(2) User access control
Sensitive systems and deployment tools (registration center, orchestration tool, …) should have an effective mechanism to restrict and monitor users’ access.
(3) Wherever possible, use image repositories that support HTTPS.
To avoid bringing in suspicious images, users should try to avoid using the –insecure-registry option to connect to any HTTP image repositories from untrusted sources.
(To be continued)
[I] Docker Registry, https://docs.docker.com/registry/
