Shulou(Shulou.com)05/31 Report--

This article will explain in detail what are the security techniques for using Docker containers. The editor thinks it is very practical, so I share it for you as a reference. I hope you can get something after reading this article.

First, let's look at restricting access to containers.

Access Management-restrict permissions

When you start the container, Docker creates a set of namespaces. Namespaces prevent processes in containers from seeing or affecting processes in hosts, including other containers. Namespaces are the main way Docker blocks one container from another.

Docker also provides private container networks. This prevents containers from gaining privileged access to the network interfaces of other containers on the same host.

Therefore, the Docker environment is somewhat isolated, but it may not be isolated enough for your use case.

> Does not look safe

Good security means following the principle of least privilege. Your container should have the ability to perform the required functions, but no other capabilities. The tricky thing is that once you start to restrict the processes that can be run in the container, the container may not be able to perform what it legally needs to do.

There are several ways to adjust the permissions of a container. First, avoid running as root (remap if you must run as root). Second, use the-cap-drop and-cap-add tuning functions.

What most people need to do is to avoid root and adjust features to limit privileges. More advanced users may want to adjust the default AppArmor and seccomp profiles. I will discuss these in my upcoming book on Docker, but they have been excluded here to prevent this article from expanding as scheduled.

Avoid running as root

The default setting for Docker is to have the user in the image run as root. Many people don't realize how dangerous this is. This means that it is easier for attackers to access sensitive information and your kernel.

As a general best practice, do not let the container run as the root user.

> Roots

"the best way to prevent privilege escalation attacks from within the container is to configure the container's application to run as an unprivileged user." -Docker document.

You can specify a user name other than root at build time, as follows:

Docker run-u 1000 my_image

The-user or-u flag can specify the user name or user ID. If userid doesn't exist, that's good.

In the above example, 1000 is an arbitrary unprivileged user identity. In Linux, user ID is usually reserved between 0 and 499. Select an ID with more than 500 users to avoid running as the default system user.

It is best to change the user from the mirrored root user rather than setting up the user from the command line. In this way, people don't have to remember to make changes at build time. Include the Dockerfile instruction in the image only after the Dockerfile instruction with the functionality attached to the root is required.

In other words, first install the required software packages, and then switch users. For example:

FROM alpine:latest RUN apk update & & apk add-- no-cache git USER 1000...

If you must run the process in the container as a superuser, remap the superuser to a less privileged user on the Docker host. Refer to the Docker documentation.

You can grant users the privileges they need by changing the functionality.

Ability

The function is the allowed process package.

Use-cap-drop and-cap-add to adjust the function from the command line. The best strategy is to use-cap-drop all to remove all privileges from the container and-cap-add to re-add the required privileges.

> Stop or go

You can adjust the functionality of the container at run time. For example, to abandon the use of kill to stop the function of the container, you can remove the default feature, as follows:

Docker run-cap-drop=Kill my_image

Avoid giving SYS_ADMIN and SETUID privileges to processes because they have a wide range of powers. Adding this functionality to the user is similar to granting root permissions (avoiding this result is the whole purpose of not using root).

It is more secure to prohibit containers from using port numbers between 1 and 1023, as most network services run within this range. Unauthorized users can listen for content such as login and run unauthorized server applications. These lower numbered ports need to be run as root users or are explicitly given CAP_NET_BIND_SERVICE functionality.

To find information such as whether the container has privileged port access, you can use inspect. Using docker container inspect my_container_name will show you many details about the resources allocated by the container and the security profile.

This is the Docker reference for more information about privileges.

As with most things in Docker, it is best to configure the container in an automatic self-documentation file. Using Docker Compose, you can specify features in the service configuration, as follows:

Cap_drop: ALL

Alternatively, you can adjust it in the Kubernetes file as discussed here.

A complete list of Linux features is here.

For finer-grained control over container privileges, check out my discussion of AppArmor and seccomp in my upcoming book. Subscribe to my email newsletter to be notified when available.

> Closed road

Access Management-restrict Resources

It is best to restrict container access to system resources such as memory and CPU. There is no resource limit, and the container can use up all available memory. If this happens, the Linux host kernel throws an "out of memory" exception and kills the kernel process. This could cause the entire system to crash. You can imagine how attackers use this knowledge to try to shut down the application.

If you are running multiple containers on the same computer, you can wisely limit the memory and CPU that any one container can use. If your container runs out of memory, it will be closed. Closing the container can cause the application to crash, which is not fun. However, this isolation prevents the host from running out of memory and prevents all containers on the host from crashing. That's a good thing.

> Wind resource

Docker Desktop CE for Mac v2.1.0 has default resource limits. You can access them under the Docker icon-> preferences. Then click the Resources tab. You can use the slider to adjust resource limits.

> Resource settings on Mac

In addition, you can restrict resources on the command line by specifying the-memory flag or the abbreviation of-m, followed by a number and a unit of measure.

4m represents 4 megabytes, which is the smallest container memory allocation. Megabytes (MiB) are slightly larger than megabytes (1 MiB = 1.048576 MB). This document is currently incorrect, but I hope the maintenance staff has accepted my PR to make changes as you read this article.

To see which resources your container is using, enter the command docker stats in a new terminal window. You will see the container statistics that are refreshed periodically.

> Stats

In the background, Docker is using the Linux control group (cgroup) to implement resource restrictions. The technology has been tested in the field.

Learn more about resource limitations on Docker here.

Image security

Grabbing an image from Docker Hub is like inviting someone into your home. You may want to know something about this.

> Someone's home

Use a trusted mirror

One of the rules for mirror security is to use only those images you trust. How do you know which images are reliable?

To be sure, popular official images are relatively safe. Such mirrors include alpine,ubuntu,python,golang,redis,busybox and node. Each has more than 10 million downloads, and a lot of people follow them.

Docker explained:

Docker sponsors a dedicated team that reviews and publishes everything in the official image. The team works with upstream software maintainers, security experts, and the wider Docker community to ensure the security of these images.

Reduce the attack surface

In relation to using a formal base image, you can use a minimum base image.

Due to less internal code, security vulnerabilities are less likely. Smaller, less complex basic images are more transparent.

It's much easier to see what's going on in an Alpine mirror than your friend's image, which depends on another basic image. The short term is easier to untie.

> Tangled

Again, install only the packages you actually need. This reduces the attack surface and speeds up image downloads and image builds.

Image mirroring that requires signature

You can use Docker content trust to ensure that the image is signed.

Docker content trust prevents users from using tagged images unless they contain signatures. Trusted sources include Official Docker Images from Docker Hub and signature images from user trusted sources.

> Signed

Content trust is disabled by default. To enable it, set the DOCKER_CONTENT_TRUST environment variable to 1. From the command line, run the following command:

Export DOCKER_CONTENT_TRUST=1

Now, when I try to pull my own unsigned image from Docker Hub, it has been blocked.

Error: remote trust data does not exist for docker.io/discdiver/frames: notary.docker.io does not have trust data for docker.io/discdiver/frames

Content trust is one way to prevent riff theft. Learn more about content trust here.

Docker stores and accesses images through an encrypted checksum of its content. This prevents attackers from creating image conflicts. This is a cool built-in security feature.

Administrative password

Your access is restricted, the image is secure, and now it's time to manage your password. "

Rule 1 for managing sensitive information: do not add it to your mirror. It is not difficult to find unencrypted sensitive information in code repositories, logs, and other places.

Rule 2: do not use environment variables for sensitive information either. Anyone who can run docker inspect or exec in the container can find your password. Anyone running as root can. Hopefully we've done some configuration so that users don't run as root, but redundancy is part of good security. Typically, the log also dumps the value of the environment variable. You don't want your sensitive information to be leaked only to anyone.

Docker volumes are better. It is recommended that you use them to access your sensitive information in Docker documents. You can use volumes as temporary file systems that are kept in memory. Volumes eliminate docker inspect and logging risks. However, root users can still see the secret, and anyone who can execute into the container can see the secret. Overall, volume is a good solution.

Better than volume, please use Docker Secret. Secret is encrypted.

> Secrets

Some Docker documents indicate that you can only use secrets in Docker Swarm. However, you can use secrets in Docker without Swarm.

If you only need the secrets in the image, you can use BuildKit. BuildKit is a better backend than the current build tools for building Docker images. It greatly reduces build time and has other good features, including support for build-time secrets.

BuildKit is relatively new-Docker Engine 18.09 is the first version that comes with BuildKit support. There are three ways to specify the BuildKit backend, so you can use its functionality immediately. In the future, it will be the default backend.

Use export DOCKER_BUILDKIT = 1 to set it as an environment variable.

Use DOCKER_BUILDKIT = 1 to start the build or run the command.

BuildKit is enabled by default. Use the following command to set the configuration in / etc/docker/daemon.json to true: {"features": {"buildkit": true}}. Then restart Docker.

You can then use secrets at build time with the-secret flag, as follows:

Docker build-secret my_key = my_value,src = path / to / my_secret_file.

The file specifies your Secret as the location of the key-value pair.

These Secret are not stored in the final image. They are also excluded from the image build cache. Safety first!

If you need to run Secret in the container, not just when building the image, use Docker Compose or Kubernetes.

Using Docker Compose, add the secrets key-value pair to the service and specify the secret file. Tips for rewriting the following example's Stack Exchange answer about Docker Compose's secret.

Example docker-compose.yml with Secret:

Version: "3.7" services: my_service: image: centos:7 entrypoint: "cat / run/secrets/my_secret" secrets:-my_secretsecrets: my_secret: file:. / my_secret_file.txt

Then start Compose using docker-compose up-build my_service as usual.

If you are using Kubernetes, it supports secrets. Helm-Secrets can help simplify secret management in K8. In addition, K8, like Docker Enterprise, has role-based access control (RBAC). RBAC makes team access secret management easier to manage and more secure.

The best practice for Secret is to use a secret management service, such as Vault. Vault is a service of HashiCorp that manages access to secrets. It also limits the Secret of time. You can find more information about the Docker image of Vault here.

Similar products from AWS Secrets Manager and other cloud providers can also help you manage secrets in the cloud.

> Keys

Remember, the key to managing secrets is to keep them. Never add them to your image or turn them into environment variables.

Update

As with any code, keep the languages and libraries in the mirror up to date to benefit from the latest security fixes.

> Hopefully your security is more up to date than this lock

If you reference a specific version of the underlying image in the mirror, be sure to keep it up to date as well.

Alternatively, you should keep the Docker version up-to-date for bug fixes and enhancements to allow you to implement new security features.

Finally, keep the host server software up to date. If you are using a managed service, you should do this for you.

Better security means keeping up to date.

Consider Docker Enterprise

If your organization has a bunch of people and a bunch of Docker containers, you can benefit from Docker Enterprise. Administrators can set policy restrictions for all users. The RBAC, monitoring, and logging capabilities provided may make it easier for your team to manage security.

With Enterprise, you can also host your own images privately in Docker Trusted Registry. Docker provides built-in security scanning to ensure that there are no known vulnerabilities in your image.

Kubernetes provides some of these features for free, but Docker Enterprise has additional security features for containers and images. Best of all, Docker Enterprise 3.0 will be released in July 2019. It includes Docker Kubernetes services with "sensible security defaults".

Other hints

Never run the container as privileged unless you have special needs, such as running Docker in a Docker container, and you know what you are doing.

In Dockerfile, it is recommended to use COPY instead of ADD. ADD automatically extracts compressed files and can copy files from URL. COPY does not have these features. Avoid using ADD as much as possible so that you are not subject to attacks from remote URL and Zip files.

If you are running any other processes on the same server, run them in the Docker container.

If you use a network server and API to create a container, check the parameters carefully to avoid creating a new container that you don't want.

If you expose REST API, use HTTPS or SSH to protect API endpoints.

Consider using Docker Bench for Security to check to see the extent to which your container follows its security guidelines.

Only sensitive data is stored in the volume, not in the container.

If you are using a single-host application with a network, do not use the default bridged network. It has technical defects and is not recommended for production. If you publish the port, you can access all containers on the bridged network.

Use Lets Encrypt for HTTPS certificate services. See an example of NGINX here.

Mount the volume as read-only only when you need to read it. See several methods here.

Abstract

You have learned a number of ways to make Docker containers more secure. Security is not immutable. It needs to be vigilant to ensure the security of images and containers.

> Keys

When considering security, keep in mind that AIM:

(1) access Management

Avoid running as a superuser. If you must use root, remap.

Remove all features and then re-add the required features.

If you need fine-grained permission adjustment, go to AppArmor.

Limit resources.

(2) Image security

Use the official, popular, smallest basic image.

Don't install things you don't need.

Requires that the mirror be signed.

Keep Docker,Docker images and other Docker-related software up to date.

(3) Secret Secret management

Use Secret or volume.

Consider a secret manager, such as vault.

> Bullseye!

Keeping the Docker container secure means achieving the goal of security.

Don't forget to keep Docker, your language and libraries, your images and your host software up to date. Finally, if you are running Docker as part of a team, consider using Docker Enterprise.

This is the end of this article on "what are the security techniques for using Docker containers". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, please share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.