Docker SecurityEmail : billal.ariif@gmail.com

Clair (Container Vulnerability Analysis Service)Clair is a container vulnerability analysis service. It provides a list of

vulnerabilities that threaten a container, and can notify users when new vulnerabilities that affect existing containers become known.

Clair analyzes each container layer once, and does not execute the container to perform its examination. The scanning engine extracts all required data to detect known vulnerabilities, and caches layer data for examination against vulnerabilities discovered in the future.

Analyze local imagesThis is a basic tool that allow you to analyze your local Docker images with Clair.Images are made up of layers. History of a image contain ID’s of all those layers. This tool fetch all ID’s and compare them with Clair database for their known vulnerabilities.When we install any application in container and commit, out installation add a new layer. To view images layers run

# sudo docker history <image id>

Image Layers Demo We have locally available Ubuntu docker image

Now copy Image ID to check its History

Note that we have 4 layers

Run Ubuntu:14.04 image container to introduce some new layers

Conti.. After installing nano we commit our container under new image name latest_ubuntu

Now again run Docker images to view ID of our new image 'latest_ubuntu' And now lets compare history of both images, hopefully we will se extra layer in history of

image latest_ubuntu

Conti..

Conti.. Yes, here we go. Now we found another layer in the history of our new

container, due to installation of nano.

Clair Implementation Pull Clair from git # sudo docker pull quay.io/coreos/clair:latest Also download Clair config file from

https://github.com/coreos/clair/blob/master/config.example.yaml And save in home directory with name config.yml in directory names config. Now run Clair container # sudo docker run -p 6060:6060 -p 6061:6061 -v ~/config:ro quay.io/coreos/clair:latest --

config=/config/config.yaml

Analyze local Images implementation Now install Clair tool for Docker images Analysis (make sure you have installed GO before this) # sudo go get -u github.com/coreos/clair/contrib/analyze-local-images Check for locally available images # sudo docker images Copy targeted image ID # sudo analyze-local-images <Docker Image ID>

Container Logs Docker historically has handled logging is through the docker logs command - Docker captures

the STDOUT and STDERR of each container process, stores it on disk, and the user can query it with docker logs <container>.

Docker Logs Demo Host Machine Terminal:

Container Terminal:

Automating Docker Logging But think about environment where hundreds of containers are running, cumbersome for

administrator to query and monitor each. By automating the logs of all containers to a single place and then virtualization could make life

of administrator much easier.

The Approach ElasticSearch to index the log data collected and make it more easily queryable Logstash to act as a remote syslog to collect the logs from the containers Logspout to actually send the container logs to Logstash Kibana as a nice front end for interacting with the collected data Cadvisor, a dashboard for monitoring container resource metrics, for kicks

sVirt sVirt is a technology included in Red Hat Enterprise Linux 6 that

integrates SELinux and virtualization. sVirt applies Mandatory Access Control (MAC) to improve security when using virtual machines.

The default type we use for running Docker containers is svirt_lxc_net_t. All container processes run with this type.

All content within the container is labeled with the svirt_sandbox_file_t type.

svirt_lxc_net_t is allowed to manage any content labeled with svirt_sandbox_file_t.

Conti.. svirt_lxc_net_t is also able to read/execute most labels under /usr on the host. Processes running with the svirt_lxc_net_t are not allowed to open/write to

any other labels on the system. It is not allowed to read any default labels in /var, /root, /home etc. Processes in the container are not isolated from each other or the host OS.

To view policy of lxc_net run: # cat /etc/selinux/targeted/contexts/lxc_contexts

Conti.. To view policy of lxc_net run:

Conti.. The latest Daniel Walsh patch allow admins to setup the containers to run at a

specific level, which should satisfy the needs of MLS systems. # sudo docker run -d --security-opt label:level:TopSecret --security-opt label:type:docker_apache_t httpd

Here TopSecret is MLS label. MLS is defined next.

Multi-Level Security (MLS) and Multi-Category Security (MCS).

MCS labeling from a user and system administrator standpoint is straightforward. It consists of configuring a set of categories, which are simply text labels, such as "Company_Confidential" or "Medical_Records", and then assigning users to those categories.

Conti.. All this stuff is configured on Host, and results comes in form of audit logs in

/var/log/audit/audit.logs Audit logs are difficult to understand by default. We can assign specific logs identifiers to processes. Logs identifiers help in

searching right logs on right time

SeLinux Logs Demo Lets add rule for Docker Daemon to log read write execute access with identifier

'dockerDaemon' . Now after restarting Docker service grep audit logs with our identifier.

References https://access.redhat.com/documentation/en/red-hat-enterprise-linux-atomic-host/7/

container-security-guide/chapter-6-docker-selinux-security-policy https://www.mankier.com/8/docker_selinux - this explains the entire Docker SELinux policy. It

is not in layman’s terms, but it is complete. https://github.com/projectatomic/docker-selinux http://crunchtools.com/securing-docker-svirt/ Daniel Walsh - https://opensource.com/business/14/7/docker-security-selinux https://opensource.com/business/14/9/security-for-docker https://opensource.com/business/15/3/docker-security-tuning