## 3 Research Method
### Securing Containers  
Improved support for container security is needed to deal with a large array of known security vulnerabilities at the level of container images [256] and container runtimes [257]. This aspect, therefore, covers features that an application manager must understand in order to manage sensitive information, manage passwords for getting access to private Docker repositories, and limiting the security attack interface of containers by limiting the access of containers towards the underlying Linux kernel.  
**Protection of sensitive data and proprietary software.**  
_Secrets_. Docker Swarm integrated mode [258], Kubernetes [259], Mesos [260], Marathon [261] and the Enterprise distribution of DC/OS [262] offer concepts for storing sensitive information such as private keys in Secret API objects which encompass one or more encrypted data fields.  
_Pulling images from a private Docker registry._ Docker Swarm, Kubernetes, Mesos and Marathon offer support for automated login to a private Docker registry so that private images can also be pulled (see the technical report [31] for a detailed comparison).  
**Improved security isolation**. One of the weaknesses of containers is that they have a broader security attack surface than virtual machines: containers run on the same host operating system and thereby enlarge the attack surface in comparison to virtual machines that run on a more compact hypervisor. For this reason, all major cloud providers continue to use a virtual machine as a key abstraction for representing a node in order to protect their assets.  
Therefore, besides the basic isolation mechanisms at the level of linux containers, i.e., cgroups and namespaces [263], container orchestration frameworks additionally leverage existing security modules in the Linux kernel in order to configure on a per container basis what a container is allowed to do in terms of linux system calls, file permissions, etc.  
These modules include SELinux, AppArmor, seccomp and Linux capabilities. SELinux [264] and AppArmor [265] are security modules that can limit by means of access control policies what a process can do. Seccomp-bpf [266] allows filtering of framework calls using a configurable policy implemented using Berkeley Packet Filter [267] rules. Linux capabilities [268] allows one to give a user-level process specific root-level permissions. As such a process can be granted access to what it needs without running the process as root.  
All container orchestration frameworks have just begun to integrate with these different security modules. Note that the following security features are supported by Docker engine and therefore also for Docker Swarm stand-alone. However, these security features are not yet available for Services in Docker Swarm integrated mode.  
_Setting Linux capabilities per container_ is supported by Docker Swarm stand-alone [269], Kubernetes [270] and Mesos.  
_Setting SELinux labels per container_ is supported by the Fedora Atomic distributions of Docker-engine [271] and by Kubernetes [272].  
_Setting custom AppArmor profiles per container_ is supported by Docker Swarm stand-alone [273] and is a beta feature of Kubernetes [274].  
_Setting custom seccomp profiles per container_ is supported by Docker Swarm stand-alone [275] and there is also alpha support for seccomp profiles in Kubernetes [276].  
_Higher-level aggregate objects for storing multiple security profiles_. Kubernetes offers a _generic aggregate object_ in the Kubernetes API, named SecurityContext [277], which manages per container and per Pod which Linux capabilities, custom profiles, SELinux labels and other privileges must be applied. Docker [278] has launched a design proposal and work-in-progress library for supporting a similar generic object, called entitlements [279]. Such entitlements are actually envisioned as higher-level abstractions for encompassing security profiles of Services in Docker Swarm integrated mode as well as Pods in Kubernetes.