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

This article shows you how to carry out Docker data security hazard analysis, the content is concise and easy to understand, absolutely can make your eyes bright, through the detailed introduction of this article, I hope you can get something.

Docker containers bring real earth-shaking changes to the writing, distribution, and deployment of applications. The purpose of the container is to be flexible so that applications can be enabled on demand, anytime and anywhere. Of course, no matter where we use the application, we need data.

Manage data access

There are many techniques available for allocating storage to Docker containers. Temporary storage capacity, local to the host running the container, can be allocated to the container at run time. Storage volumes are stored in hosts that map to a specific subdirectory of the application. Volumes can be created when the container is instantiated, or in advance using the "docker volume" command.

In addition, local storage can be mapped to the container as an installation point. In this case, the "docker run" command specifies the local directory as the installation point within the container. The third option is to use storage plug-ins to directly associate external storage with containers.

Open access

In each approach, the Docker framework does not provide an inherent security model for data. For example, any host directory can be installed into a container, including sensitive system folders, such as / etc. This means that the container may modify these files because permissions are granted using standard and simple Unix permission settings. Another better approach to this is to use a non-root container, which involves running the container under a different Linux user ID (UID). This is easier to do, but it means building a way to protect each container, using the group ID (GID) or UID as a permission check.

Here we have another problem: using a non-root container, and the local volume does not work properly unless the UID used to run the container has access to the / var/lib/docker/volumes directory. If you do not, the data cannot be accessed or created. Opening this directory is a security risk; however, there is no inherent way to set individual permissions on a volume-by-volume basis.

If we look at how external storage is installed into the container, many solutions only need to show the block device (LUN) and format the file system to the host running the container. This is then shown to the container as an installation point. At this point, the security of directories and files can be set within the container, reducing the issues we have discussed. However, if the LUN/volume is reused elsewhere, there is no security control over how it is installed and used, because there is no security model built directly to the container / volume mapping relationship. It all depends on trusting the commands running on the host.

There is another problem: the lack of multi-tenancy. When we run the container, each container instance may run for a separate application. In traditional storage deployments, the storage allocated to the container should be separated to a certain extent to ensure that the data is not unintentionally or maliciously accessed. Currently, there is no easy way to do this at the host level, only trust orchestration tools to run containers and map to data.

Looking for a solution

Some of the problems here are specific to Linux/Unix. For example, the abstraction of the installation namespace provides a different entry point for our data, however, there is no abstraction of permissions-- I cannot map user 1000 to user 1001-- without a physical upgrade of the ACL (access control list) data associated with each file and directory. Large-scale ACL changes can affect performance. For local volumes, Docker can simply set permissions on the host directory, and the new volume matches the UID that is booting the container.

External volumes provide a good opportunity for us to move away from the permission structure in the host running the container. However, this means that we need a mechanism to map volume data to known trusted applications in specific container instances. Keep in mind that the container does not have an inherent "identity" and can start and stop as you wish. This makes it difficult to determine whether any single container is the owner of the data volume.

At present, the main solution is to rely on the orchestration platform to manage the operation of the container. We trust these systems to map volumes and containers, which in many ways is not like traditional SAN storage or virtual disk mapping to virtual machines. But containers differ in their portability and the need for security mechanisms to be extended to the public cloud.

We still have a lot of work to do. For Docker, the acquisition of storage startup Infinit may inspire them to protect persistent data. This should probably mean that the development interface allows all vendors to work on it.

The above content is how to analyze the security risks of Docker data. Have you learned any knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

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.