Nowadays Cloud computing is thriving on its popularity as benefits of cloud adoption are countless, including better efficiency, reduced costs of virtual services, greater accessibility and flexibility. Today almost everything that includes information of individuals and companies is placed on cloud but moving applications to the cloud and acquiring the advantages means first evaluating specific data security and cloud security issues.
Docker brings certainty to application administration in shared surroundings, ensures the portability and increases the availability of application hence decreasing the overall risk. Docker Containers are much more similar to LXC containers if you’re already aware of them or have worked on them in the past. Docker makes use of a layered security approach which is an exercise of integrating various mitigating security commands to preserve resource and data.
Docker uses many security barricades to stop break out. If situation emerges where there is a break out of one container mechanism then the issue is resolved by blocking the concerned containers with the next one. We know that Docker shares Linux kernel architecture and provide as many Linux security mechanisms as possible.
There are three main zones that are to be examined when evaluating Docker security:
1) Built-in safety of containers, as performed by kernel namespaces and c groups.
2) Docker daemon attack surface.
3) The freezing security characteristics of the kernel and how they reach out with containers.
Following are the security features provided by Docker in cloud:
Namespaces provide the isolation Workplace for the containers. Docker creates a set of namespaces for the container and each aspect of a container runs in its own namespace hence does not have access outside of it. Each container also gets its own network stack thus restricting the interfaces of another container.
Below is the list of namespaces that Docker uses:
Control Groups also called “cgroups” are another main element of containers. They implement resource accounting and limiting as key element to run applications. This mechanism helps in understanding and ensuring that containers are beneficial multi-tenant citizens on a host like public and private PaaS, to guarantee a consistent uptime as well as performance even when some applications start to misbehave. Control Groups supply sufficient functional standards and even limit the memory available to a specific container.
Applications and containers running with Docker initiate to run the “Docker daemon” that needs root benefits and runs on a host machine. The user does not directly interact with the daemon,instead through the Docker client.
Docker daemon should always be controlled by the faithful users. Docker gives you the permission to share a directory among the Docker host and a guest container, regardless of limiting the access rights of the container. This helps you to run a container where the host directory will be free to operate without any restrictions. Such a structure leads to very strong safety consequences. Let’s explain it through an example, if you are implementing Docker from a web server to provision containers through an API, you must make sure to avoid potential danger with variable examination. It helps in building a sentiment that no hostile user proceeds with crafted variable causing Docker to generate arbitrary containers.
For this particular reason, REST API endpoint found an answer to a problem by considering possible options of using Docker CLI to communicate with the Docker daemon. They now make use of a UNIX socket rather than TCP socket bound.
Upcoming advancements in Linux namespaces will promptly allow running of the full featured containers in the absence of root privileges and will also solve the problems that are caused by sharing of the namespaces between host and guests.
Docker starts every container with a set of capabilities that are limited within bounds and Capabilities change the binary “root/non-root” separation into a fine grained access control system.
Removing these capabilities may lead to the breaking of the applications so it can be said that capabilities try to achieve serviceability, usability and security between Docker Containers. You always have the authority to enable extra capabilities if they are required. Below is the current list of capabilities that are used by Docker.
chown, dac_override, fowner, kill, setgid, setuid, setpcap, net_bind_service, net_raw, sys_chroot, mknod, setfcap, and audit_write.
It is also possible to control fully established systems like TOMOYO, AppArmor, SELinux, GRSEC, etc with Docker, though Docker only validates capabilities and doesn’t interfere with different systems.
Following are few examples:
1) It is possible for you to run a kernel with GRSEC and PAX. Hence increasing a large number of security controls during compile time and run time thus defeating majority of exploits.
2) Docker containers can even be used out of the box if your distribution comes with security model templates. These templates help in providing a safety shield around Docker containers.
3) It helps you in describing your own approaches by using favourite access control techniques.
In addition to other security features there are new security attributes which are used by Docker for the file system protections and are explained below:
There are a few Linux kernel file systems that have to be mounted in a container environment otherwise process may fail to run. But luckily nearly all of these can be mounted as “read-only”. Most applications should never require to write to these file systems.
Docker mounts these file systems into the container as “read-only” mount points.
. /sys
. /proc/sys
. /proc/sysrq-trigger
. /proc/irq
. /proc/bus
Privileged container processes can never write to them as these file systems are mounted as read-only and cannot cause a change to the host system. It is even possible to remount the file systems as read/write and restrict the potential of the privileged container processes.
Docker also makes use of the copy-on-write file systems which give them the power to use the same file system image as the base for the container. Whenever container writes any content to the image it always gets written to a container specific file system and thus prevents one container from noticing the changes of another container even if they write to the same file system image. One container cannot change the image content to affect the processes in another container.
With Docker it’s possible to implement security features of the other containerization systems. The final aim of Docker is to fulfill and perform two supplemental security advancements:
1) Set intended actions to map the root user of a container to a non root user of the Docker host, to reduce the outcome of a container-to-host privilege escalation.
2) To grant Docker daemon to run without root privileges and delegate operations requiring those privileges to be well-audited sub-processes, each with its own scope: virtual network setup, file system management, etc.
By default, Docker containers are secure to great extent as they provide you with a mechanism to take care of running processes inside the containers. They give you privilege to add an extra layer of security by giving you an authority to enable Apparmor, SELinux, GRSEC or any of your favourite hardening resolutions.
By Sudhi Seshachala
CTO @Xervmon Inc Sudhi, a technology entrepreneur, brings 19+ years in software, cloud technologies, IT operations and management. Have led several global teams in HP, Sun/Oracle, SeeBeyond. He has built highly scalable and highly available products, systems management, monitoring and integrated SaaS and on-premise applications. He is a trusted advisor and consults with companies of all sizes to establish devops practices, implement docker based CI/CD or AWS deployments in a cost effective scale. His work and expert insight can be followed on CloudTweaks in 2015 as part of the 12/12 contributor program.
