Docker Security

Difference between Docker and Virtual Machine

Isolation and Sharing

• By adding Hypervisor layer, virtual hardware such as network card, memory, CPU and so on, virtual machines can be built on top of it. Each virtual machine has its own system core
• Docker containers isolate file systems, processes, devices, networks and other resources in an isolated way, then control permissions, CPU resources and so on, ultimately leaving containers unaffected.
  The container cannot affect the host.Containers share resources such as kernel, file system, hardware, and so on with the host.

Performance and Loss

• Container resources are less depleted than virtual machines.
• Under the same host machine, there are more containers that can be created than virtual machines.
• However, virtual machines are slightly more secure than containers, and it is extremely difficult to crack the Hypervisor layer before breaking from a virtual machine to a host or other virtual machine
• The docker container shares resources such as the kernel and file system with the host machine.
  More likely to have an impact on other containers, hosts.

  Security issues with Docker

  Docker's own vulnerability

• As an application Docker, there are code defects in its implementation.There are more than 20 vulnerabilities in the official CVE Docker historical version.
  -The main GJ methods used by hackers are code execution, privilege promotion, information disclosure, privilege bypass, etc.Docker versions are currently changing very quickly, so it is best for Docker users to upgrade to the latest version.

  Docker Source Problem

• 1) Hackers upload malicious images If a hacker implants viruses, backdoors and other malicious software in the created images, the environment has been unsafe from the beginning, and there is no security to speak of in the future.
• 2) Mirroring uses the downloadable image on the vulnerable software Docker Hub, 75% of which have the vulnerable software installed.So after downloading the mirror, you need to check the version information of the software inside, whether there are any bugs in the corresponding version, and update the patch in time.
• 3) Intermediate GJ tamper mirror may be tampered with during transmission, and the new version of Docker has provided corresponding checking mechanism to prevent this problem.

  Docker architecture flaws and security mechanisms

  Architecture Defects

• LAN GJ between containers
  Containers on a host can form a local area network, so GJ methods such as ARP spoofing, sniffing, and broadcast storms against the local area network can be used.Therefore, deploying multiple containers on one host requires reasonable network configuration and iptable rules.

• DDoS GJ Depletes Resources
  The Cgroups security mechanism is designed to prevent such GJ s, which can be avoided by not allocating too much resources to a single container.

• Vulnerable System Calls
  An important difference between Docker and virtual machines is that Docker shares an operating system kernel with the host machine.
  Once a host kernel has an override or delegation vulnerability, even though Docker is executed by an ordinary user, the GJ can also use the kernel vulnerability to jump to the host to do more when the container is RQ.

• Shared root user privileges
  If you run the container with root user privileges, the root user within the container also has root privileges on the host.

  Six main aspects of Docker security baseline standards

  1. Kernel Level

  (1) Kernel update in time.
  (2) User NameSpace (the root permissions inside the container are in a non-high permission state outside the container).
  (3) Cgroups (quotas and measures for resources).
  (4) SELiux/AppArmor/GRSEC (control file access rights).
  (5) Capability.
  (6) Seccomp (limit system calls).
  (7) Disable sharing the container's namespace with the host process namespace.

2. Host Level

(1) Create separate partitions for containers.
(2) Run only the necessary services.
(3) Prevent mapping sensitive directories on hosts to containers.
(4) Audit the Docker daemon, related files and directories.
(5) Set the appropriate number of default file descriptors.
(File Descriptor: The kernel uses a file descriptor to access files.The file descriptor is a non-negative integer.
When you open an existing file or create a new one, the kernel returns a file descriptor.Read and write files also require file descriptors to specify the files to be read and written)
(6) Docker-related files with root should have 644 or lower access rights.
(7) Periodically check each host's container list and clean up unnecessary containers.

3. Network Level

(1) Prohibit or allow network traffic between containers through iptables setting rules.
(2) Allow Dokcer to modify iptables.
(3) Do not bind Docker s to other IP/Port s or Unix Socket s.
(4) Prohibit mapping of privileged ports on containers.
(5) Only the ports needed are open on the container.
(6) Prohibit the use of host network mode on containers.
(7) If the host has multiple network cards, bind the container entry traffic to a specific host network card.

4. Mirror Level

(1) Create a local mirror warehouse server.
(2) The software in the mirror is the latest version.
(3) Use trusted mirror files and download them through a secure channel.
(4) Rebuild the mirror instead of patching containers and mirrors.
(5) Reasonable management of mirror labels and timely removal of unused mirrors.
(6) Use mirror scanning.
(7) Use mirror signatures.

5. Container level

(1) Minimize containers and minimum set of operating system mirrors.
(2) Containers run as a single main process.
(3) Prevent privileged tags from using privileged containers.
(4) Prohibit running ssh services on containers.
(5) Mount the container's root directory system in a read-only manner.
(6) Explicitly define the data tray characters that belong to containers.
(7) By setting on-failure to limit the number of times a container tries to restart, it is easy to lose data if the container restarts repeatedly.
(8) Restrict the process trees available in containers to prevent fork bombs.(fork bomb, rapidly growing subprocesses, depleting system processes)

6. Other settings

(1) Conduct regular security audits of host system and containers.
(2) Run the container with the least resources and the least privileges.
(3) Avoid deploying a large number of containers on the same host machine and maintain a manageable quantity.
(4) Monitor Docker container usage, performance and other indicators.
(5) Increase the capability of real-time impediment detection and event response.
(6) Use central and remote log collection services

Docker Security Rules

Container Minimization

• Run only necessary services in containers, services such as ssh are not open

  [root@localhost ~]# docker exec -it mycontainer bash

  Docker remote api access control

• Docker's remote call API interface has an unauthorized access vulnerability and should restrict access to the external network

  [root@localhost ~]# docker -d -H uninx:///var/run/docker.sork -H tcp://192.168.142.128:2375

• Specify in docker default profile, then access control on host iptables\firewalld

  Limit flow direction

• You can use Iptables filters to limit the range of source IP addresses for Docker containers to communicate with the outside world

Iptables -A FORWARD -s <source_ip_range> -j REJECT --reject-with icmp-admin-prohibited

Iptables -A FORWARD -i docker0 -o eth0 -j DROP 
Iptables -A FORWARD -i docker0 -o eth0 -m state -state ESTABLISHED -j ACCEPT

Start Docker service with normal user

• User mapping solves the problem that user 0 in a specific container equals root on the host system, and LXC allows remapping user and group ID s

[root@localhost ~]# yum -y install lxc uidmap
[root@localhost ~]# vim /etc/lxc/default.conf
lxc.id_map = u 0 100000 65536
lxc.id_map = g 0 100000 65536

File System Restrictions

• Mounted container root directories are absolutely read-only, and file directory permissions for different containers are separated, optimizing 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

  Mirror security

• In general, make sure you only get mirrors from trusted libraries, and do not use the--insecure-registry=[] parameter
  

  Communication security between Docker client and Docker Daemon

• In order to place problems such as link hijacking, session holding, etc., which result in intermediate GJ when Docker is communicating, both sides of c/s should communicate by encryption

[root@localhost harbor]# docker --tlsverify --tlscacert=ca.pem --tlscert=cert.pem --tlskey=key.pem -H=0.0.0.0:2376

Resource constraints

• Limiting container resources reduces security risks and 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 upgrades kernel vulnerabilities in a timely manner

• Host failure or problems requiring kernel upgrade
• Docker containers should support thermal migration
• Kernel upgrade planning, execution, and relocation scenarios should be considered

Install safety reinforcement

• Use secure Linux kernels, kernel patches, such as SELinux, AppArmor,
  GRSEC, etc.

Avoid information disclosure in Docker containers

• Check the contents of the container creation template

# 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
# Add your checks in below

Log Analysis

• Collect and archive Docker-related security logs for auditing and monitoring purposes, and use rsyslog or stdout+ELK for log collection, storage, and analysis
• Use the following command on the host to access log files outside the container

docker run -v /dev/log:/dev/log <container_name> /bin/sh

• Docker built-in commands

docker logs -f

Docker Bench for Security

• Is a script to examine dozens of common best practices for deploying Docker containers in a production environment
• Environment Installation
  After downloading the binary, 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.sh

ulimit

• It can limit resources 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, maximum virtual memory for a process, and so on.
• Set CPU Time

docker daemon --default-ulimit cpu=1200
docker run --rm -ti --ulimit cpu=1200 ubuntu bash

• View after entering the container

ulimit -t

Docker-TLS Encrypted Communication

• In order to prevent link hijacking, session hijacking, etc. from causing intermediate GJ in Docker communication, both sides of c/s should communicate by encryption

1. Deploy master server

[root@localhost ~]# hostnamectl set-hostname master
[root@localhost ~]# su
[root@master ~]# vim /etc/hosts
127.0.0.1  master
[root@master ~]# mkdir /tls
[root@master ~]# cd /tls/
#Create a ca key
[root@master tls]# openssl genrsa -aes256 -out ca-key.pem 4096
#Create a ca certificate
[root@master tls]# openssl req -new -x509 -days 1000 -key ca-key.pem -sha256 -subj "/CN=*" -out ca.pen
#Create 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
#Sign with ca certificate and private key certificate, enter 123123
[root@master tls]# openssl x509 -req -days 1000 -sha256 -in server.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out server-cert.pem
#Generate Client Secret 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 profile
[root@master tls]# echo extendedKeyUsage=clientAuth > extfile.cnf
#Signature certificate, input 123123 requires (signing client, ca certificate, ca secret key)
[root@master tls]# openssl x509 -req -days 1800 -sha256 -in client.csr -CA ca.pem -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
#Configure docker
[root@master tls]# vim /lib/systemd/system/docker.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:2376 -H unix://var/run/docker.sock
#Restart Process
[root@master tls]# systemctl daemon-reload
#Restart Service
[root@master tls]# systemctl restart docker

#Copy the / tls/ca.pem/tls/cert.pem/tls/key.pem files to another host
[root@master tls]# scp ca.pem 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 

2. Deploy client Server

[root@localhost ~]# hostnamectl set-hostname client
[root@localhost ~]# su
[root@client ~]# vim /etc/hosts
192.168.45.129 master

3. Testing on Client

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

Thanks for reading!!!