Shulou(Shulou.com)06/03 Report--

This article is about the security management of Docker containers. The editor thought it was very practical, so I shared it with you to learn. The following information is about the steps of Docker container security management.

* * 1. Isolation and sharing * * Virtual machines have their own system kernel by adding Hypervisor layer to virtualize virtual hardware such as network card, memory, CPU and so on, and then set up virtual machines on them. Docker containers isolate file systems, processes, devices, networks and other resources through isolation, and then control permissions and CPU resources, so that containers do not affect each other, and containers cannot affect the host. The container and the host share resources such as kernel, file system, hardware, etc. # docker containers share the same kernel resources, while virtual machines are independent and use resources independently. * * 2. Performance and attrition * * Container resources are consumed less than virtual machines. Under the same host, more containers can be built than virtual machines. However, the security of the virtual machine is slightly better than the container, and it is extremely difficult to break the Hypervisor layer to break from the virtual machine to the host or other virtual machines. While docker containers share kernel, file system and other resources with hosts, it is more likely to have an impact on other containers and hosts. # Container consumes much less resources than a virtual machine, because a container with a shared kernel means that one container takes up more resources, while other containers take up less. If a container has problems, other containers will have problems, so virtual machine security is better than containers.

Security issues with Docker-

* * 1.Docker 's own vulnerability * * as an application, Docker has code defects in its own implementation. There are more than 20 vulnerabilities in the historical version of Docker officially documented by CVE. * the commonly used methods include code execution, permission enhancement, information disclosure, permission bypass, and so on. At present, Docker versions are changing very fast, and Docker users had better upgrade Docker to the latest version. * * 2. Docker source code problem * * Docker provides Docker hub, which allows users to upload created images for other users to download and quickly build the environment. But it also brings some security problems. For example, the following three ways: (1) * upload malicious images if * malicious software such as * and backdoors are implanted in the created images, the environment will not be secure from the very beginning, and there will be no security to speak of in the future. # Images may store Love * Software and viruses (2) Images that can be downloaded from the vulnerable software Docker Hub, 75% of the images are equipped with vulnerable software. Therefore, after downloading the image, you need to check the version information of the software, whether there are loopholes in the corresponding version, and update and patch it in time. # there is a problem with the environment in the old version of the image. (3) the middleman * * tampers with the image may be tampered with during transmission. The new version of Docker has provided a corresponding verification mechanism to prevent this problem. The image you uploaded is hijacked and tampered with by the middleman. At this time, you need a TLS security certificate, and the docker container goes to the docker server for security authentication.

-Docker architecture flaws and security mechanisms-

The architecture and mechanism of Docker may cause problems. For example, in a * scenario, * already controls some containers on the host, or obtains the way to create containers on the public cloud, and then initiates * * against the host or other containers. * * 1. The local area network between containers * Therefore, deploying multiple containers on a single host requires reasonable configuration of the network and setting iptable rules. * * 2. DDoS * * exhaustion of resources * * Cgroups security mechanism is to prevent this kind of *. Do not allocate too many resources to a single container to avoid such problems. * 3. An important difference between a vulnerable system call * * Docker and a virtual machine is that Docker shares an operating system kernel with the host. Once there is a loophole in the host kernel that can exceed authority or raise rights, although Docker is executed by ordinary users, when the container is * *, * * users can also take advantage of kernel vulnerabilities to jump to the host to do more things. * * 4. Shared root user rights * * if you run the container with the user permission of root, the root user in the container will have the root permission of the host.

-Docker Security baseline Standard-

The following is a summary of Docker security baseline standards from six aspects: kernel, host, network, image, container and so on. * * 1. Kernel level * * (1) update the kernel in time. (2) User NameSpace (the root permission in the container is not in a high permission state outside the container). (3) Cgroups (quota and measurement of resources). (4) SELiux/AppArmor/GRSEC (control file access). (5) Capability (authority division). (6) Seccomp (qualify system calls). (7) it is forbidden to share the container namespace with the host process namespace. * * 2. Host level * * (1) create a separate partition for the container. (2) run only the necessary services. (3) it is forbidden to map sensitive directories on the host to containers. (4) audit the Docker daemon, related files and directories. (5) set the appropriate default number of file descriptors. (file descriptor: the kernel (kernel) uses the file descriptor (file descriptor) to access files. The file descriptor is a nonnegative integer. When opening an existing file or creating a new file, the kernel returns a file descriptor. Read and write files also need to use file descriptors to specify the files to be read and written) (6) Docker-related files with user rights of root should have access rights of 644 or lower. (7) periodically check the container list of each host and clean up unnecessary containers. * 3. Network level * * (1) Network traffic between containers is prohibited or allowed through iptables setting rules. (2) allow Dokcer to modify iptables. (3) do not bind Docker to other IP/Port or Unix Socket. (4) it is forbidden to map privileged ports on containers. (5) only the required ports are open on the container. (6) the use of host network mode on the container is prohibited. (7) if the host has multiple network cards, bind the container inbound traffic to a specific host network card. * * 4. Image level * * (1) create a local image repository server. (2) the software in the image is the latest version. (3) use a trusted image file and download it through a secure channel. (4) rebuild the image instead of patching the container and image. (5) manage image tags reasonably and remove images that are no longer in use in time. (6) use mirror scanning. (7) use mirror signature. * * 5. Container level * (1) the container is minimized and the operating system image is minimized. (2) the container runs as a single main process. (3) prohibit privileged tags from using privileged containers. (4) prohibit running ssh service on the container. (5) Mount the container's root directory system in a read-only manner. (6) clearly define the data drive letter that belongs to the container. (7) by setting on-failure to limit the number of attempts to restart the container, it is easy to lose data when the container is restarted repeatedly. (8) restrict the process trees available in the container to prevent fork bomb. (fork, rapidly growing subprocesses, exhausting the number of system processes) * * 6. Other settings * (1) conduct security audits of host systems and containers on a regular basis. (2) run the container with the least resources and permissions. (3) avoid deploying a large number of containers on the same host and maintain a manageable number. (4) monitor the use, performance and other indicators of Docker containers. (5) add real-time unsafe detection and event response function. (6) use central and remote log collection services Docker security rules container minimization if only the necessary services are run in the container, services such as SSH cannot be easily opened to connect the container The remote call API interface of the container docker exec-it bashdocker api access control docker is usually entered in the following way. There is an unauthorized access vulnerability [root@localhost ~] # vim / usr/lib/systemd/system/docker.service binding unix reconnects through the docker,sock file,-H binds your tcp port And 14 lines of address ExecStart=/usr/bin/dockerd-H unix:///var/run/docker.sock-H tcp://192.168.136.186:2323 [root@localhost ~] # systemctl daemon-reload [root@localhost ~] # systemctl restart docker# permanent configuration, rich language rules, source address, specify tcp port 2323 [root@localhost ~] # firewall-cmd-- permanent-- add-rich-rule= "rule family=" ipv4 "source address=" 192.168.136.186 "port protocol=" tcp "port=" 2323 "accept" # restart the firewall [root@localhost ~] # firewall-cmd-- reload success restricts the flow of traffic to the firewall. External traffic will be controlled internally, but when the container accesses the outside, the firewall will give the request a serial number. When it comes back directly trusted by the firewall, there is a hidden danger of permanent configuration, specify the public area, control the address of the ipv4, write the address of the container, refuse [root@localhost ~] # firewall-cmd-- permanent-- zone=public-- add-rich-rule= "rule family=" ipv4 "source address=" 192.168.136.0, 24 "reject" success [root@localhost ~] # firewall-cmd-- reload success uses ordinary users to start the docker service.

Use user mapping to solve the problem that user 0 in a specific container is equal to root on the host system, and LXC allows user and group ID to be remapped

# create a virtual user for the root user using user mapping, which is equivalent to the root permission on the host system

File system limit

The mounted container root directory is absolutely read-only, and the file directory permissions corresponding to different containers are separated, which optimizes that each container has a separate partition on the host.

Su test01

Docker run-v dev:/home/mc_server/test01-it centos:latest / bin/bash

Su test02

Docker run-v dev:/home/mc_server/test02-it centos:latest / bin/bash

Image security in general, make sure you only get the image from the trusted library and do not use the-insecure-registry= [] parameter

This kind of certificate verification can only determine whether your identity is secure, but mirror security cannot guarantee the security of communication between Docker client and Docker Daemon. In order to place link hijacking, session persistence and other problems, Docker communication will be mediated. [root@localhost harbor] # docker-- tlsverify-- tlscacert=ca.pem-- tlscert=cert.pem-- tlskey=key.pem-Hang 0.0.0.0VERV 2376 Resource Control limits Container Resources, which not only reduces security risks, but also does not affect business docker run-tid-name ec2-cpuset-cpus 3-cpu-shares 2048-memory 2048m-rm-blkio-weight 100-pids--limit 512 host timely upgrade kernel vulnerabilities docker container supports hot migration However, pay attention to the migration and IP address, install security hardening, and use kernel patches to avoid leakage of docker container messages to check whether the image is made in dockerfile, such as whether ssh is enabled and whether there is any problem with the image log analysis to collect and archive Docker-related security logs to achieve the purpose of audit and monitoring. Use rsyslog or stdout+ELK for log collection, storage and analysis on the host using the following command to access the log file docker run-v / dev/log:/dev/log / bin/sh # outside the container Docker built-in command docker logs-fDocker Bench for Security is a script for checking dozens of common best practices environments for deploying Docker containers in a production environment after installing and downloading binaries Add it to the environment variable PATH [root@localhost] # git clone https://github.com/docker/docker-bench-security.git[root@localhost] # cd docker-bench-security [root@localhost] # sudo sh docker-bench-security.shulimit, including core dump file size, process data segment size, class creation file size, resident memory set size, number of open files, process stack size, CPU time, maximum number of threads for a single user, Resources such as the maximum virtual memory of the process play a limiting role in setting the CPU time docker daemon-- default-ulimit cpu=1200docker run-- rm-ti-- ulimit cpu=1200 ubuntu bash## after entering the container to view ulimit-tdocker-tls encrypted communication in order to prevent link hijacking Problems such as session persistence cause docker communications to be brokered. [root@localhost] # hostnamectl set-hostname master [root@localhost ~] # su [root@master ~] # vim / etc/hosts127.0.0.1 master [root@master ~] # mkdir / tls [root@master ~] # cd / tls/// to create ca secret key [root@master tls] # openssl genrsa-aes256-out ca-key.pem 4096mp / create ca certificate [root@master tls] # openssl req-new- X509-days 1000-key ca-key.pem-sha256-subj "/ CN=*"-out ca.pen// creates the server private key [root@master tls] # openssl genrsa-out server-key.pem 4096 / signature private key [root@master tls] # openssl req-subj "/ CN=*"-sha256-new-key server-key.pem-out server.csr// uses ca certificate and private key certificate to sign, Enter 123123 [root@master tls] # openssl x509-req-days 1000-sha256-in server.csr-CA ca.pen-CAkey ca-key.pem-CAcreateserial-out server-cert.pem// to generate the client key [root@master tls] # openssl genrsa-out key.pem 4096mp / signing client [root@master tls] # openssl req-subj "/ CN=client"-new-key key.pem-out client.csr// to create a configuration file [root@master tls] # echo extendedKeyUsage=clientAuth > extfile.cnf// signing Certificate Enter 123123 required (signing client, ca certificate, Ca key) [root@master tls] # openssl x509-req-days 1800-sha256-in client.csr-CA ca.pen-CAkey ca-key.pem-CAcreateserial-out cert.pem-extfile extfile.cnf// delete redundant files [root@master tls] # rm-rf ca.srl client.csr extfile.cnf server.csr// configuration docker [root@master tls] # vim / lib/systemd/system/docker.service ExecStart=/usr/bin/dockerd-- tlsverify-- tlscacert=/tls/ca. Pen-- tlscert=/tls/server-cert.pem-- tlskey=/tls/server-key.pem-H tcp://0.0.0.0:2376-H unix://var/run/docker.sock// restart process [root@master tls] # systemctl daemon-reload// restart service [root@master tls] # systemctl restart docker// copy / tls/ca.pen / tls/cert.pem / tls/key.pem three files to another host [root@ Master tls] # scp ca.pen root@192.168.45.128:/etc/docker [root@master tls] # scp cert.pem root@192.168.45.128:/etc/docker [root@master tls] # scp key.pem root@192.168.45.128:/etc/docker [root@localhost ~] # hostnamectl set-hostname client [root@localhost ~] # su [root@client ~] # vim / etc/hosts192.168.45.129 master#client Test [root@client Docker] # docker-tlsverify-tlscacert=ca.pen-tlscert=cert.pem-tlskey=key.pem-H tcp://master:2376 version

After reading the above, do you have any further understanding of the security management of Docker containers? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel. Thank you for reading.

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.