Docker (eight) some primary security deployment

First, the security problems of Docker

1. Docker 's own vulnerabilities
As an application, Docker itself will have code flaws in its implementation. There are more than 20 vulnerabilities in the CVE official record of Docker's historical version, which can be found on the Docker official website.
Commonly used attack methods by hackers mainly include code execution, privilege escalation, information leakage, and privilege bypass. At present, Docker version changes very fast, and Docker users can 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 issues.
For example, the following three methods:
(1) Hackers upload malicious images
If a hacker implants malware such as Trojan horses and backdoors in the created images, the environment will be insecure from the beginning, and there will be no security in the future.

(2) Mirrors use vulnerable software
Among the images that can be downloaded on DockerHub, 75% of the mirrors have vulnerable software installed. Therefore, after downloading the image, you need to check the version information of the software in it, whether the corresponding version has vulnerabilities, and update and patch it in time.

(3) Man-in-the-middle attack tampering with the image
The image may be tampered with during the transmission process. Currently, the new version of Docker has provided a corresponding verification mechanism to prevent this problem.

2. Docker Architecture Defects and Security Mechanisms

The architecture and mechanism of Docker itself may cause problems. For example, in such an attack scenario, the hacker has already controlled some containers on the host, or obtained a way to establish containers on the public cloud, and then launch attacks on the host or other containers. attack.

1. Local area network attacks between containers Containers on
   the host can form a local area network, so ARP spoofing, port scanning, and broadcast storm attacks against the local area network can be used.
   Therefore, deploying multiple containers on a host requires reasonable network security configuration, such as setting iptables rules.

2. DDoS attacks exhaust resources
   Cgroups security mechanism is designed to prevent such attacks. Do not allocate too many resources to a single container to avoid such problems.

3. Vulnerable system calls
   An important difference between Docker and virtual machines is that Docker shares the same operating system kernel as the host.
   Once the host kernel has an overriding or privilege escalation vulnerability, although Docker uses a normal user to execute, when the container is compromised, an attacker can use the kernel vulnerability to jump to the host to do more things.

4. Shared root privileges
   If you run a container with root privileges (docker run --privileged), the root user inside the container also has root privileges on the host.

3. Docker Security Baseline Standard

The following summarizes the Docker security baseline standards from six aspects: kernel, host, network, image, container, and others.

1. Kernel level
   (1) Update the kernel in time.
   (2) User NameSpace (root privileges in the container are in a non-high-privileged state outside the container).
   (3) Cgroups (quota and measurement of resources), set resource limits such as CPU, memory, and disk IO.
   (4) Add extra security by enabling SELinux/AppArmor/GRSEC (Controlling File Access Permissions) appropriate hardening systems.
   (5) Capability (permission division), such as dividing the specified CPU to the container.
   (6) Seccomp (limited system calls), limit unnecessary system calls.
   (7) It is forbidden to share the namespace of the container with the namespace of the host process, such as the host network mode.

2. The host level
   (1) creates separate partitions for containers, such as on a distributed file system.
   (2) Only run the necessary services, and try to avoid running the ssh service in the container.
   (3) It is forbidden to map sensitive directories on the host to the container, and you need to pay attention to -v when creating data volumes.
   (4) Audit the Docker daemon process, related files and directories to prevent virus or Trojan horse files from being generated.
   (5) Set an appropriate default number of file descriptors. (File descriptor: fd for short, when the application requests the kernel to open/create a new file, the kernel will return a file descriptor corresponding to the open/new file. The file descriptor is essentially a non-negative integer, read and write. The file also needs to use this file descriptor to specify the file to be read and written. The file descriptor is an important system resource. In theory, as many file descriptors as the system memory should be opened, but the actual situation is that the kernel will have System-level restrictions, as well as user-level restrictions, do not allow an application process to consume all file resources, you can use ulimit -n to view)
   (6) The access rights of Docker-related files with user rights as root should be 644 or lower permissions.
   (7) Periodically check the container list of each host and clean up unnecessary containers.

3. Network level
   (1) Set rules through iptables to prohibit or allow network traffic between containers.
   (2) Allow Docker to modify iptables.
   (3) It is forbidden to bind Docker to other used IP/Port or Unix Socket.
   (4) Mapping privileged ports on containers is prohibited.
   (5) Only the required ports are opened on the container.
   (6) It is forbidden to use the host network mode on the container.
   (7) If the host has multiple network cards, bind the incoming traffic of the container to a specific host network card.
   docker network create --subnet=172.18.0.0/16 --opt "com.docker.network.bridge.name"="docker1"
   mynetwork docker run -itd --net mynetwork --ip 172.18.0.100 centos:7 /bin /bash
   iptables -t nat -A POSTROUTING -s 172.18.0.100 -o ens36 -j SNAT --to-source 192.168.80.10

4. Image level
   (1) Create a local private image repository server.
   (2) The software in the image is the latest version. It is recommended to use the corresponding version according to the actual situation, and business stability is the priority.
   (3) Use a trusted image file and download it through a secure channel.
   (4) Rebuild the image instead of patching the container and image, destroy the abnormal container and rebuild it.
   (5) Manage image labels reasonably and remove images that are no longer in use in a timely manner.
   (6) Use mirror scan.
   (7) Use the image signature.

5. Container level
   (1) Minimal container, minimal set of operating system images.
   (2) The container runs as a single main process.
   (3) The --privileged flag is prohibited from using privileged containers.
   (4) It is forbidden to run the ssh service on the container, and try to use docker exec to enter the container.
   (5) Mount the root directory system of the container in a read-only manner, -v host directory: container directory: ro.
   (6) Clearly define the data drive letter belonging to the container.
   (7) By setting on-failure to limit the number of times the container tries to restart, it is easy to lose data when the container restarts repeatedly, –restart=on-failure:3.
   (8) Limit the number of processes available in the container, docker run -m limits memory usage to prevent fork bombs. (fork bomb, rapidly growing child processes, exhausting the number of system processes).(){.|.&};.

6. Other settings
   (1) Regularly conduct security audits on the host system and containers.
   (2) Run the container with the least resources and the least privilege, which is the core idea of ​​Docker container security.
   (3) Avoid deploying a large number of containers on the same host and maintain a manageable number.
   (4) Monitor the usage, performance and other indicators of Docker containers, such as zabbix.
   (5) Add real-time threat detection and event alarm response functions, such as zabbix.
   (6) Use central and remote log collection services, such as ELK.

Since security is a very specific technology, I won't go into details here. You can directly refer to the official Docker documentation, https://docs.docker.com/engine/security/

Fourth, common security configuration methods related to containers

1. Container minimization
If only necessary services are run in the container, services such as SSH cannot be easily opened to connect to the container. The following methods are usually used to enter the container.

docker exec -it a661258f6bfe bash

2. Docker remote API access control
There is an unauthorized access vulnerability in Docker's remote call API interface, at least external network access should be restricted. It is recommended to use Socket to access.

//Specify the monitoring intranet ip in the docker service configuration file
vim /usr/lib/systemd/system/docker.service
–13 lines – modify
ExecStart=/usr/bin/dockerd -H unix:///var/run/docker .sock -H tcp://192.168.80.10:2375

(2) Restart Docker
systemctl daemon-reload
systemctl restart docker
netstat -natp | grep 2375

(3) IP access control is performed on the firewalld of the host machine. The source address specifies the client address
firewall-cmd --permanent --add-rich-rule=“rule family=”ipv4” source address=”192.168.80.15 " port protocol="tcp" port="2375" accept"
firewall-cmd --reload
or
iptables -t filter -A INPUT -s 192.168.80.15 -p tcp --dport 2375 -j ACCEPT

(4) Implement remote authorized access to docker -H tcp://192.168.80.10 images on the client

Fifth, restrict the flow of traffic

//Use a firewall filter to restrict the source IP address range of the Docker container to communicate with the outside world.
firewall-cmd --permanent --zone=public --add-rich-rule="rule family="ipv4" source address="192.168.80.0/24" reject"
iptables -t filter -A INPUT -s 192.168.80.0 /24 -j REJECT

//A large number of problems in the production environment are caused by the vulnerabilities caused by the external release of the Docker container port. In addition to the problem of operating system account permission control, there are hidden dangers in the process management of Docker Daemon.
The current commonly used Docker versions all support Docker Daemon to manage the host iptables, and once the startup process adds the port mapping of -p host_port:guest_port, Docker Daemon will directly add the corresponding FORWARD Chain and -j ACCEPT, and the default DROP rule is What is done in the INPUT chain has no restrictions on docker, which leaves a serious security risk. Therefore, it is recommended:
(1) Do not use Docker services on machines with external network ip.

(2) Use docker orchestration systems such as k8s to manage Docker containers.

(3) Add --iptables=false to the Docker daemon startup command on the host, then write the common iptables rules into the file, and then use iptables-restore to redirect the input to refresh the rules.

Six, mirror security

In general, to ensure that images are only obtained from trusted repositories, harbor private repositories are recommended.
If the company does not use its own image source, it needs to use the Docker image security scanning tool Clair to check the downloaded image. Scan the mirror synchronously with the CVE database, verify the characteristic values ​​such as md5 of the mirror, and confirm the consistency before further construction based on the mirror. Once a vulnerability is found, the user is notified to deal with it, or the image is directly blocked from continuing to build.

Seven, the communication security between Docker Client and DockerDaemon

In order to prevent man-in-the-middle attacks during Docker communication due to problems such as link hijacking and session hijacking, the two ends of the c/s should communicate through TLS encryption.

By creating a TLS key certificate on the server and sending it to the client, the client accesses the container through the private key, thus ensuring the security of docker communication.
//Workflow using certificate access:
(1) The client initiates an HTTPS request and connects to port 443 of the server.
(2) The server must first apply for a set of digital certificates (the contents of the certificate include public key, certificate authority, expiration date, etc.).
(3) The server sends its own digital certificate to the client (the public key is in the certificate, and the private key is held by the server).
(4) After the client receives the digital certificate, it will first verify the validity of the certificate. If the certificate is verified, a pseudo-random number generator (/dev/random) is used to randomly generate a [symmetric key], and the [symmetric key] is encrypted with the public key of the certificate.
(5) The client sends the [symmetric key] encrypted by the public key to the server.
(6) After the server receives the ciphertext key sent by the client, it asymmetrically decrypts it with the private key it has previously reserved. After decryption, the client's [symmetric key] is obtained, and then the client's [symmetric key] key] to encrypt the returned data, so that the transmitted data is all ciphertext.
(7) The server returns the encrypted ciphertext data to the client.
(8) After the client receives it, it decrypts it symmetrically with its own [symmetric key] to get the data returned by the server.

Please download the old version before doing it. The docker version should not exceed 1.15.15. The creation is unsuccessful.

In order to prevent man-in-the-middle attacks during Docker communication due to problems such as link hijacking and session hijacking, the two ends of the c/s should communicate through TLS encryption.

By creating a TLS key certificate on the server and sending it to the client, the client accesses the container through the private key, thus ensuring the security of docker communication.

First, create the ca certificate. The ca certificate is just an officially certified certificate. Next, you need to create the certificates for the server and client nodes.

There are three steps to creating a certificate at this point:

(1) Set the private key to ensure secure encryption

(2) Use the private key to sign to ensure that the identity is authentic and non-repudiation

(3) Use the ca certificate to make a certificate

server	IP	components
master	192.168.100.135	docker-ce
client	192.168.100.140	docker-ce

1. Environmental preparation

(1) Specify Alibaba Cloud first

 yum-config-manager --add-repo https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo
  cd /etc/yum.repos.d/
sed -i 's+download.docker.com+mirrors.aliyun.com/docker-ce+' /etc/yum.repos.d/docker-ce.repo

(2) Install the old version

yum install -y docker-ce-cli-20.10.5-3.el7.x86_64 docker-ce

(3) Create a storage directory

mkdir /tls
cd /tls/

(4) Generate ca certificate and create ca certificate

openssl genrsa -aes256 -out ca-key.pem 4096
####################################################
genrsa：使用RSA算法产生私钥
-aes256：使用256位密钥的AES算法对私钥进行加密，这样每次使用私钥文件都将输入密码，可省略
-out：输出文件的路径，若未指定输出文件，则为标准输出
4096：指定私钥长度，默认为1024。该项必须为命令行的最后一项参数
###########################################################
openssl req -new -x509 -days 1000 -key ca-key.pem -sha256 -subj "/CN=*" -out ca.pem
#####################################
req：执行证书签发命令
-new：新证书签发请求
-x509：生成x509格式证书，专用于创建私有CA时使用
-days：证书的有效时长,单位是天
-key：指定私钥路径
-sha256：证书摘要采用sha256算法
-subj：证书相关的用户信息(subject的缩写)
-out：输出文件的路径
#####################################

//用ca证书签发server端证书
（3）创建服务器私钥
openssl genrsa -out server-key.pem 4096

（4）生成证书签名请求文件（csr文件）
openssl req -new -key server-key.pem -sha256 -subj "/CN=*" -out server.csr

（5）使用ca证书与私钥证书签发服务端签名证书，输入123123
openssl x509 -req -days 1000 -sha256 -in server.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out server-cert.pem

########################################
x509：生成x509格式证书
-req：输入csr文件
-in：要输入的csr文件
-CA：指定ca证书的路径
-CAkey：指定ca证书的私钥路径
-CAcreateserial：表示创建证书序列号文件，创建的序列号文件默认名称为ca.srl

//用ca证证书签发client端证书
（6）生成客户端私钥
openssl genrsa -out client-key.pem 4096

（7）生成证书签名请求文件
openssl req -new -key client-key.pem -subj "/CN=client" -out client.csr

（8）创建扩展配置文件，使秘钥适合客户端身份验证
echo extendedKeyUsage=clientAuth > extfile.cnf

（9）使用ca证书签发客户端签名证书，输入123123
openssl x509 -req -days 1000 -sha256 -in client.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out client-cert.pem -extfile extfile.cnf

//删除两个证书签名请求文件和扩展配置文件
rm -rf ca.srl client.csr extfile.cnf server.csr

//配置docker服务配置文件
vim /lib/systemd/system/docker.service
--13行--修改
ExecStart=/usr/bin/dockerd --tlsverify --tlscacert=/tls/ca.pem --tlscert=/tls/server-cert.pem --tlskey=/tls/server-key.pem -H tcp://0.0.0.0:2376 -H unix:///var/run/docker.sock

Copy the three files ca.pem, client-cert.pem, client-key.pem in the /tls directory to another host

scp ca.pem [email protected]:/etc/docker/
scp client-cert.pem [email protected]:/etc/docker/
scp client-key.pem [email protected]:/etc/docker/

//Modify the hostname and ip mapping of the server

hostnamectl set-hostname master
su

vim /etc/hosts	
127.0.0.1   master

//本地验证，使用证书访问时要用主机名连接
docker --tlsverify --tlscacert=ca.pem --tlscert=server-cert.pem --tlskey=server-key.pem -H tcp://master:2376 images


//在客户端上操作
hostnamectl set-hostname client
su

vim /etc/hosts
192.168.80.10   master

cd /etc/docker/
docker --tlsverify --tlscacert=ca.pem --tlscert=client-cert.pem --tlskey=client-key.pem -H tcp://master:2376 images

Eight, avoid information leakage in Docker containers

In recent years, a large number of personal or corporate account passwords have been leaked on Github. When this problem occurs, dockerfile or docker-compose file is generally used to create containers. If there are authentication information such as account passwords in these files, once the Docker container is opened to the outside world, the sensitive information on these hosts will also be leaked.
So the content of the container creation template can be checked in the following way.

##check created users
grep authorized_keys $dockerfile

##check OS users
grep "etc/group" $dockerfile

##Check sudo users
grep "etc/sudoers.d" $dockerfile

##Check ssh key pair
grep ".ssh/.*id_rsa" $dockerfile