Because of popular trends, technological lobbying or needs, software architectures evolve.
Thus, various architectures have one day be the reference:
- Component / Object (DCOM/CORBA)
- Service (SOA)
Each mutation brings a lot of advantages as a new set of challenges. In this article, we will go through the challenges of the security of Micro Services and especially security around the Docker solution.
The adoption of micro-services was born from a need to increase the modularity and agility of applications but their use makes more complex the security of our information systems.
The challenge of securing micro-services
Previously, it was necessary to ensure the security of a single application. Today, it is necessary to protect a large number of services and their implementations. They interact with each other through various APIs and data flows. They live as quickly as they die. More services means more elements exposed to cyber attacks or misuse. The article, written by Graham Lea, is a good reference and a nice White Paper about security for microservices as it establishes a comprehensive list of best practices to implement.
Nevertheless, the article does not explain how and what tools to use to set up this rules.
What security policy for Docker?
To meet the development of microservices, IT Industry turned to the use of containers and particularly to its most known: Docker.
However, we can not audit a docker container as a conventional server:
- In principle the containers are not accessible via ssh.
- Insulation of containers does not make them visible from the docker server.
It is needless to use a traditional SAST scanner because it is impossible to make an inventory of libraries or even having access to software configuration files used by the container.
Nevertheless, here are the main essential safety tips for your environment docker:
Security of Docker Images
Docker containers need images to work. It is the first link in the chain that we have to validate.
This introduces a small revolution to the IT Team, some tests which were assigned to Operators have been migrated into the continuous integration chain of Developers. They are now done in build or post-build process.
These solutions (Deep Container Inspection, DCI) are intended to ensure that tools and software embedded in the images are not vulnerable. Exploiting vulnerabilities could lead a malicious person to take control of the container. It could then attempt to obtain root privileges (privilege elevation), and / or attempt to take control of neighboring containers.
Security of Images in the Docker Hub
By easy of use or rapid prototyping needs, you may decide to use build image from the registry.
It is necessary to be vigilant as the ‘Hub Docker Registry’ offers a multitude of downloadable images. Always prefer the official images proposed and validated by Docker. They are regularly updated, well documented and audited by the service ‘Docker scanning service’.
If you have no other choice than use an unofficial image, make sure it has been sufficiently downloaded. You may read the comments about the image and check the ‘Dockerfile‘ on github to ensure that the image corresponds with what is indicated.
If you are ready to use a third party registry because the image is not available on Docker Hub, check its reputation, and check that the communication established with this new register is secured and encrypted.
Security of Docker Engine
To run the containers, you must properly configure the Docker Engine. Organizations such as the Center for Internet Security (CIS) and Gotham Digital Science have written recommendations. They are described in the following documents:
The open source project ‘docker-bench-security‘ implements the CIS’s recommendations using a script to run. It checks that the host running the containers set the best security practices. This is like applying hardening tips to Docker, its configuration and the right settings of the security profile (apparmor, seccomp, selinux).
However, take care that the tools do not automate all the recommendations. Some tests can only be performed by an audit, depending on the deployed environment.
The security of data sharing
Do not forget to have a look to the data shared between containers (Volumes in the docker language).
Do not expose more information than necessary. Use of containers is also a way to compartmentalize information;
Avoid wasting space on the host server’s disk, for example ElasticSearch image is using host directory : /usr/share/elasticsearch/data*
* Those information are available through the command ‘docker volume ls’ and ‘docker volume inspect’.
The security of the Docker Ecosystem
Do not miss the security of the ecosystem around docker: swarm, Kubernetes, mesos, nomad, traefik, flocking, etc. This ecosystem grows quickly (too quickly) but security has become a priority. As example, the Docker Version 1.12, that included natively swarm, adds encryption mechanisms facilitating the generation and deployment of certificates between cluster nodes.
An important security tip, after each update of your docker tools, I would suggest you pay attention to the changelog file and check for new functionalities related to security.
Improving Docker security
Blamed in its beginning for major security flaws (privilege escalation ,lack of isolation), the action take by Solomon Hykes and his team has proven successful.
“As we grow, we will continue our investment in our security team, contributions, tooling and processes. This investment will make Docker safer, helping it become a secure and trusted partner for our users. “DEC.2014
We showed you the basic tools and some tips to ensure the security of micro-services infrastructure.
We’ve compiled some of the best security practices in Elastic Detector for automation and rapid deployment, feel free to do test and share comments.