Complete Guide to Container Security Mechanisms - XenonStack

What are Containers?

Containers are a completely isolated environment. These are a solution to the problem of how to get the software to run reliably when moved from one computing environment to another. Consists of an entire runtime environment –

  • An application, plus all its dependencies.
  • Libraries and other binaries.
  • Configuration files needed to run it.

Why Container Security Mechanisms?

Containers a standard way to package your application’s code. It is the isolated process i.e., the process running in the sandbox that typically only sees the other methods that are started in the same container. Containers make our app portable –

  • It looks the same everywhere.
  • No matter where you run it.
  • Doesn’t need to install all the app dependencies.

Containerization allows for greater modularity i.e., and the application can split into modules.

Container Security Mechanisms

Linux Kernel namespaces

Docker uses namespaces of several kinds to implement the isolation that containers require to remain portable and abstain from affecting the remainder of the host system E.g., process id

Linux control groups (cgroups)

Provide a mechanism for efficiently running and monitoring system resources, by partitioning things like CPU time, system memory, disk, and network bandwidth, into groups, then assigning tasks to those groups.

The docker daemon in Container Security Mechanisms

  • Docker daemon is the mastermind behind the whole operation.
  • When docker run command is used to start up a container, the docker client will transpose that command into an HTTP API call and transmits it to docker daemon Docker daemon then assesses the request, talks to the underlying OS and provisions your container.

Linux capabilities

This feature aims to break up the power of the superuser so that an application requiring some privilege does not get all rights.

Linux security mechanism AppArmor, SELinux

SElinux acts as a protective agent on servers. SELinux relies on compulsory access controls (MAC) that restrain users to rules and procedures established by the system administrator.

Overview of Docker Security

Dockers are the containers that make our app shareable. A Dockerfile is a text file or a list of instructions that we pass to a docker engine to tell it how we build a container. Docker build command is used to pass a docker file to a docker engine. Docker engine follows the instructions set in the docker file to build a docker image. Docker image uses a docker run command to start a container based on that image.

If code needs to be compiled and executable, it can be done in two ways –

  • Compile code manually and specify in the docker file
  • Describe how to compile your executable in the docker file as an instruction, so the docker engine will follow this instruction to compile an executable.

Docker engine can manage how many physical resources, how much RAM, how much CPU is allowed to use by each of these
containers.Every time we run docker build command if docker file is changed, we are not replacing the old docker image, the new docker image is continuously being created every time we run a docker build command

Things that make docker-engine special – We can take any docker image and start it as a container on a different OS. The new container will run in the same way as it runs on the original computer.

Accessing The Container Security Mechanisms

Containers are accessible because they provide a standard way to package an application code. They make the app portable and does not need to install all dependencies. But there are still some difficulties in container security. Some container software is used to secure containers. Docker is commonly used container software.

Docker container technology increases the default security by creating the isolation layers between the application and between the application and hosts. Isolation is a powerful mechanism in controlling what container can see or access to or what resources they can use. Docker container provides resources constraints with Linux namespaces and cgroups.

Security Workflow

When the developer has completed their aspect, they will push to the continuous integration system (CI), which will build and test the images. The image will then drove to the registry. It is now ready for deployment to production.

Docker Image Provenance

The gold standard for image provenance is Docker Content Trust. DCT presents the capability to use digital signatures for data sent to and received from remote Docker registries. With docker content trust enabled, a digital signature is added to the image before they are pushed into the registry. When the image pulls docker content trust will verify the signature, by ensuring that the image comes from the correct organization and the content of the image exactly matched with the image that was pushed.

It is also possible to verify the image using digests. A digest is the sha256 hash of a docker image. When the image is pushed, a docker client will return a string that represents the digest of an image. Whenever the image is pulled, the docker will verify the digest matches with an image. Any update in the image will result in the generation of the new digest.

Security Scanning

Docker security scanning gives the ability to do a binary level scan of all images. The image scanner automatically helps to identify all the vulnerabilities and reduce risk., it also ensures the integrity of a container image. Docker security scanning is available as an integral part of the docker cloud and docker data center but not as a stand-alone service.

Auditing for Container Security Mechanisms

The production environment is regularly edited to ensure that all the containers are based on up to date containers, and both hosts and containers are securely configured. Auditing directly follows security scanning and image provenance. It isn’t enough to scan image before they are deployed as new vulnerabilities are reported. Therefore, it is essential to scan all the images that are running. Some tools can be used to verify that the container files system has not diverged from the underlying file systems. Tools, such as docker diff is used to list the changed files and directories in a container file system since the container was created.

Isolation and Least Privileged

The significant security benefit of the container is the extra tooling around isolation. Containers work by creating a system with separate namespaces. The principle of least privilege is defined as “Every program and privileged user of the system should function using the least amount of privilege required to complete the job” Concerning containers this represents that each container should run with minimal set of privileges possible for its effective operation.A container can also be secured by running containers with read-only file systems. In docker, this is achieved by only passing the read-only flag to docker run.

Bypassing the read-only flag, the attacker will unable to write the malicious scripts to the file systems and unable to modify the contents.The network traffic is between containers on the same host, which increases the risk of unwanted disclosure of information to other vessels. To reduce these risks, the developer should restrict the container access by allowing intercommunication that are necessary by linking specific containers.

Runtime Threat Detection

No matter how good a job is done with vulnerability scanning and container hardening. There are always unknown bugs and vulnerabilities that may recognize in runtime and cause a disturbance. That is why real-time threat detection is essential. Tools like AuqaSecurity and Twistlock offer runtime threat detection. Twistlock provides full-stack container and cloud-native cybersecurity for teams using Docker, Kubernetes, serverless, and other cloud-native technologies. Twistlock integrates with any CI tool and registry and runs wherever we choose to run containers and cloud-native applications.

Twistlock integrates with any CI tool and is used to provide unmatched vulnerability and enforcement for container images, hosts, and serverless functions. Twistlock automatically learns the behavior of the images and microservices while preventing anything anomalous.

Access Control

The most two standard security modules are SELinux and AppArmor. They both are an implementation of the Mandatory Access Control (MAC) mechanism. SELinux and AppArmor are brave attempts to clean up the security holes in Linux containers. MAC will check that the user or process has the right to perform various actions such as reading and writing.

Application Armor (AppArmor) is an effective and easy to use Linux application security system. AppArmor protects the OS and applications from any kind of internal and external threat.AppArmor is available for docker containers and applications present in the containers. AppArmor is always recommended to use as is by default with Ubuntu 16.04. Security-Enhanced Linux(SELinux) is the implementation of the MAC security mechanism. It allows the server admin to define various permissions for all processes.

SELinux defines how processes can interact with another part of the server. E.g., An apache user with full permission can only access /var/www/html directory but cannot access the other part of the system without policy modification. If an attacker managed to access the Apache web server, it would only have excess to exploit the server. The files will have regular access as defined in the policy of the server. The attacker does not have access to other parts of the system or internal LAN.Therefore, the damage can restrict to the particular server and files.

Avoid root access

The namespace feature in Linux containers allows developers to avoid root access by giving isolated containers a separate user account. So, a user from one container does not have access to another container. System Administrator should have to enable this feature, as this feature is not enabled by default.

A Holistic Strategy

Successfully adopting containers is a challenging task for many. Choosing the use of containers in a production environment is not possible without container networking and container security. The purpose is to rethink how security storage will emerge when container count increments in production, working not just tens or hundreds of nodes but thousands at a time.To Implement Security Mechanism we advise taking the following steps –

Leave a Comment

Name required.
Enter a Valid Email Address.
Comment required.(Min 30 Char)