Never take container security for granted

The concept of containers was first introduced in the 1970s with the development of Unix V7. In 2001, Jacques Gélinas’s VServer project permitted “running several general-purpose Linux servers on a single box with a high degree of independence and security.” They went mainstream in 2006 with Google’s process containers, and a mere 12 years later, two-thirds of IT leaders indicated that moving workloads from virtual machines to containers is a priority for their company’s future.

There are numerous advantages to containerization: lower costs, higher performance, and broad-spectrum application availability. One inherent, assumed advantage is security. While both Docker security and Kubernetes security protocols within a containerized environment are robust, risks do exist. It’s easy to ignore these, and we often find IT leaders asking, almost rhetorically, “What is container security?” However, developing a secure containerized environment requires understanding the risk and adopting industry best practices.

As our world continues to transition to containers in ever-increasing numbers, they will become the target of more and more black hat activity. Whether you’re using Docker, Kubernetes, or both, establishing firm security practices now will set your company up to evolve with the industry and stay ahead of the curve.

The greatest container security risks and challenges

Security within containers themselves is high, and the most significant vulnerabilities lie outside of active instances. These are three areas where you should prioritize security efforts.

Vulnerability #1: Container images

When an image is executed, a developer pulls its executable software packages from a repository and runs them without checking to see if they are corrupted or contain any threats. Repositories may contain outdated or incorrectly configured images, which increases their vulnerability to attack. They might be corrupted, and running them can contaminate other containers. Attackers may even be able to gain system-level access and introduce malicious containers on other user systems.

Container images

Establishing proper image security begins with validating the source of all images in your containers. This includes images developed in-house since even customized images are typically built using some level of third-party code. SecOps engineers should create a list of trusted sources and then develop automated controls to ensure only trusted, up-to-date images can be used in your systems. Signature authentication software is a crucial part of this application.

Vulnerability #2: Access control

Access control is a crucial part of any network, but it can be easy to forget when working with containers. The two primary vectors here are the possibility of superuser account compromise and access control lists that are outdated, granting permissions to admins and users who should no longer be able to access certain areas. The former is often encountered when superuser access is employed too frequently: the more commonly "god" accounts are leveraged, the greater the risk of the account credentials being compromised. Risks are introduced via the latter vector when access control lists aren’t regularly purged, and former employees and vendors retain permissions that should have been revoked.

Setting up a properly segregated admin and user schema with appropriate permissions is foundational. Superuser accounts should be accessed as rarely as possible, with the username and password locked in a safe until it’s needed. As a general rule, if you see these "god permissions" used on even a monthly basis, it's likely too often. You should also routinely scrub access control lists weekly or biweekly to ensure that permissions are granted and revoked on an as-needed basis and are kept current.

Vulnerability #3: Host environment

It’s easy to limit our thinking to containers themselves when considering container security, but the greater vulnerabilities occur in the host environment. Failure to harden the security of the systems containers are running on can introduce substantial risks that even the most robust container security protocols can’t negate.

One practice you should adopt is to remove all noncritical native services from the host, which requires users to go through the containers themselves to access the host. This consolidates control at the container daemon, substantially decreasing your potential attack surface. If you’re using proxy servers, this is particularly crucial because an attacker can use a proxy to bypass container security controls.

Best practices for achieving effective container security

Container security best practices

1. You should begin by conducting a vulnerability assessment process and taking action to address any specific issues on your systems. After this, consider implementing the below-mentioned Docker best practices and Kubernetes best practices to further robust overall container security.

2. Conducting routine automated scans of both active containers and image repositories is crucial. Processes like authorization, auditing, and behavior profiling can be automated, which will allow you to detect aberrant behavior early and address it quickly. The question of being attacked isn’t a matter of "if," but "when," and promptly recognizing and resolving the problem is foundational to both Kubernetes and Docker container security.

3. Subconsciously we often exclusively relegate the concept of access control to users, but we can’t forget container access. Properly configuring containers for access, system resources, and Kernel requirements are critical to limiting the potential scope of hostile activity. Regularly reviewing these access policies can help prevent any attack from spreading rapidly between containers. Control groups and namespaces should be priorities for container security.

4. Developers can fall into bad habits that undermine container security. By definition, a container should be lightweight and only used for short periods. It’s not uncommon to conduct an audit and find developers treating them more like servers: routinely adding files and only updating them periodically. You might find instances where containers haven’t been updated for weeks or months at a time. Both Kubernetes and Docker were designed for using high numbers of small containers; reversing this and using low numbers of large containers undermines their security design.

5. Put strict procedures in place to authenticate the signatures of any image you download and ensure they come from trusted sources. Numerous scanning tools are available to automate this process, but however it’s accomplished, ensuring it happens should be a non-negotiable priority.

6. Adopting a least-privileged user access policy that’s consistently updated is vital, and audits and updates should occur more frequently as an organization's size increases. Even admins should only have access to the areas for which they’re authorized, and any need for increased access should be defined explicitly in its scope and limited in its duration. Managing vendor access is even more crucial to avoid introducing unnecessary vulnerabilities.

Final thoughts about container security

Containers are flexible, robust, and designed to be secure. However, that inherent security comes with certain assumptions, and like a chain, it’s only as strong as its weakest link. The host system must be hardened against attacks that could be introduced through that OS. Images should be verified, validated, and repositories kept current. Developers must use containers how they were designed to be used, and access must be limited and kept up-to-date. During operation, systems, image repositories, and containers themselves should be routinely scanned for abnormal activity.

Assessing and addressing your vulnerabilities is an excellent first step toward establishing a secure environment. Regardless of which you’re using, Kubernetes and Docker security best practices require similar mechanisms and are complementary in how they operate. The tips we’ve provided here will go a long way toward limiting your attack surface and preventing security breaches.

Alex Sokolov, Senior Software Engineering Manager at iTechArt

Let's get rolling
Drive your business, and get solutions,
not just technologies.
Have a project in mind?
We'll help you develop this idea into a great solution.
Give us a shout!