About Docker security Docker-TLS encrypted communication issues

1. Security issues with Docker

Docker’s own vulnerabilities

As an application, Docker itself has code defects in its implementation. CVE officially records more than 20 vulnerabilities in historical versions of Docker. Common attack methods used by hackers include code execution, privilege escalation, information leakage, and privilege bypass. Currently, Docker versions are updated very quickly, so Docker users are advised to upgrade Docker to the latest version.

Docker source code problem

Docker provides a Docker hub that allows users to upload images they create so that other users can download them and quickly build an environment. But it also brings some security issues.
For example, the following three methods:
(1) Hackers upload malicious images If hackers implant Trojans, backdoors, and other malicious software into the images they create, the environment will be unsafe from the beginning, and there will be no security at all in the future.

(2) Images use vulnerable software. Among the images available for download on Docker Hub, 75% of them have vulnerable software installed. Therefore, after downloading the image, you need to check the version information of the software in it to see if there are any vulnerabilities in the corresponding version, and update and patch it in time.

(3) Man-in-the-middle attack: Image tampering may occur during transmission. The new version of Docker has provided a corresponding verification mechanism to prevent this problem.

2. Docker architecture defects and security mechanisms

Problems may arise from the architecture and mechanisms of Docker itself, such as an attack scenario in which a hacker has taken control of some containers on the host machine, or has gained access to a way to build containers on a public cloud, and then attacks the host machine or other containers.

LAN attacks between containers

The containers on the host can form a local area network, so attacks such as ARP spoofing, sniffing, and broadcast storms against the local area network can be used. Therefore, deploying multiple containers on a host requires reasonable network configuration and setting iptable rules.

DDoS attacks exhaust resources

The cgroups security mechanism is designed to prevent such attacks. This problem can be avoided by not allocating too many resources to a single container.

Vulnerable system call

An important difference between Docker and a virtual machine is that Docker and the host machine share the same operating system kernel. Once the host kernel has a vulnerability that can lead to privilege escalation or privilege escalation, even if Docker is executed as a normal user, when the container is invaded, the attacker can still exploit the kernel vulnerability to jump to the host machine and do more things.

Shared root user permissions

If you run the container with root user privileges, the root user in the container also has root privileges on the host machine.

3. The difference between docker container and virtual machine

Isolation and Sharing

The virtual machine adds a Hypervisor layer to virtualize virtual hardware such as network cards, memory, and CPU, and then creates virtual machines on top of them. Each virtual machine has its own system kernel. Docker containers isolate file systems, processes, devices, networks and other resources, and then control permissions, CPU resources, etc., so that containers do not affect each other and cannot affect the host machine. The container shares the kernel, file system, hardware and other resources with the host.

Performance and loss

Compared with virtual machines, containers consume less resources. On the same host machine, the number of containers that can be created is greater than that of virtual machines. However, the security of virtual machines is slightly better than that of containers. To break into the host machine or other virtual machines from the virtual machine, you need to break into the Hypervisor layer first, which is extremely difficult. The Docker container shares the kernel, file system and other resources with the host machine, and is more likely to have an impact on other containers and the host machine.

Docker security baseline standards

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

Kernel level

(1) Update the kernel in a timely manner.
(2) User NameSpace (root permissions in the container are in a non-high-privilege state outside the container).
(3) Cgroups (quotas and metrics for resources).
(4) SELiux/AppArmor/GRSEC (control file access permissions).
(5) Capability (division of authority).
(6) Seccomp (limited system calls).
(7) It is prohibited to share the container namespace with the host process namespace.

Host level

(1) Create independent partitions for containers.
(2) Run only necessary services.
(3) It is prohibited to map sensitive directories on the host to the container.
(4) Audit the Docker daemon, related files, and directories.
(5) Set an appropriate default number of file descriptors.

(File descriptor: The kernel uses file descriptors to access files. File descriptors are non-negative integers. When opening an existing file or creating a new file, the kernel returns a file descriptor. Reading and writing files also requires the use of file descriptors to specify the files to be read and written)

(6) The access permissions of Docker-related files with user permissions of root should be 644 or lower.
(7) Periodically check the container list of each host and clean up unnecessary containers.

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 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 prohibited to use host network mode on containers.
(7) If the host machine has multiple network cards, bind the container incoming traffic to a specific host network card.

Image level

(1) Create a local image repository server.
(2) The software in the image is the latest version.
(3) Use trusted image files and download them through secure channels.
(4) Rebuild the image instead of patching the container and image.
(5) Manage image tags properly and remove images that are no longer used in a timely manner.
(6) Use mirror scanning.
(7) Use image signature.

Container level

(1) Minimize the container and the minimum set of operating system images.
(2) The container runs as a single main process.
(3) The privileged tag is prohibited from using privileged containers.
(4) It is prohibited to run ssh service on the container.
(5) Mount the container's root directory system in read-only mode.
(6) Clearly define the data drive letter belonging to the container.
(7) By setting on-failure, you can limit the number of times the container attempts to restart. Repeated container restarts can easily lead to data loss.
(8) Limit the process tree available in the container to prevent fork bombs.

Other settings

(1) Regularly conduct security audits on the host system and containers.
(2) Run containers using minimal resources and minimal permissions.
(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.
(5) Add real-time threat detection and incident response capabilities.
(6) Use central and remote log collection services

Docker-TLS encrypted communication

In order to prevent link hijacking, session hijacking and other problems from causing man-in-the-middle attacks during Docker communication, both ends of the c/s should communicate in an encrypted manner.

Create a folder and modify the host name (for subsequent use)

[root@server1 ~]# mkdir /tls

[root@server1 ~]# cd /tls

[root@server1 tls]# hostnamectl set-hostname master

[root@server1 tls]# bash

[root@master tls]#

Client Additions:

[root@client ~]# vim /etc/hosts 

Create a ca key and set the key password

[root@master tls]# openssl genrsa -aes256 -out ca-key.pem 4096

Generating RSA private key, 4096 bit long modulus

...........................................++

...................................................................................................................................................................................++

e is 65537 (0x10001)

Enter pass phrase for ca-key.pem:

Verifying - Enter pass phrase for ca-key.pem:

Create a CA certificate

[root@master tls]# openssl req -new -x509 -days 1000 -key ca-key.pem -sha256 -subj "/CN=liuwei" -out ca.pem

Enter pass phrase for ca-key.pem: ###Enter password

Create a server private key

[root@master tls]# openssl genrsa -out server-key.pem 4096

Generating RSA private key, 4096 bit long modulus

...............................++

................................++

e is 65537 (0x10001)

Signature private key

[root@master tls]# openssl req -subj "/CN=lw" -sha256 -new -key server-key.pem -out server.csr

Use CA certificate and private key certificate to sign, enter 123456

[root@master tls]# openssl x509 -req -days 1000 -sha256 -in server.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out server-cert.pem

Signature ok

subject=/CN=lw

Getting CA Private Key

Enter pass phrase for ca-key.pem: 

Generate client key

[root@master tls]# openssl genrsa -out key.pem 4096 

Signature Client

[root@master tls]# openssl req -subj "/CN=client" -new -key key.pem -out client.csr

Create a configuration file

echo extendedKeyUsage=clientAuth > extfile.cnf

Signature certificate, enter 123456, required (signature client, CA certificate, CA key)

[root@master tls]# openssl x509 -req -days 1000 -sha256 -in client.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out cert.pem -extfile extfile.cnf

Signature ok

subject=/CN=client

Getting CA Private Key

Enter pass phrase for ca-key.pem: 

Modify the docker configuration file and restart the service

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:2388 -H unix:///var/run/docker.sock 

Restart Docker

[root@master tls]# systemctl daemon-reload

[root@master tls]# systemctl restart docker

Copy the three files /tls/ca.pem /tls/cert.pem /tls/key.pem to the client

[root@master tls]# scp ca.pem [email protected]:/etc/docker 

[root@master tls]# scp cert.pem [email protected]:/etc/docker 

[root@master tls]# scp key.pem [email protected]:/etc/docker 

When verifying tls, you need to use the ID set by the private key, so the above host names must be changed to lw

Local Authentication

[root@lw tls]# docker --tlsverify --tlscacert=ca.pem --tlscert=cert.pem --tlskey=key.pem -H tcp://lw:2388 version 

Download the NGINX image

[root@lw tls]# docker pull nginx

Deploy the client environment and verify TLS

Enter the /etc/docker directory

Check the docker version on the client side

[root@client docker]# docker --tlsverify --tlscacert=ca.pem --tlscert=cert.pem --tlskey=key.pem -H tcp://lw:2388 version 

Deployment environment, verify tls

View the client images

[root@client docker]# docker --tlsverify --tlscacert=ca.pem --tlscert=cert.pem --tlskey=key.pem -H tcp://lw:2388 images 

This is the end of this article about Docker security and Docker-TLS encrypted communication. For more information about Docker TLS encrypted communication, please search for previous articles on 123WORDPRESS.COM or continue to browse the following related articles. I hope you will support 123WORDPRESS.COM in the future!