docker security
Post on 14-Feb-2017
444 Views
Preview:
TRANSCRIPT
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
top related