Container security: The seven biggest mistakes companies are making

As enterprises increase adoption of containers, they also risk increasing the number of mistakes they make with the technology. Given that many companies are still wrapping their heads around the potential of container technology and how to best leverage it, that stands to reason. With that said, however, companies must ensure that they are establishing a solid foundation for security as they continue to identify strategies and workloads that make sense on a container platform.

Here are the seven biggest container security mistakes companies are making, and how they can “adjust their sails” to ensure smooth sailing ahead.

1. Securing containers without securing the platform on which they are deployed

Any conversation around containers security must begin with a discussion around securing the operating system (OS) platform upon which they are deployed.

Without a foundational layer of platform security, an organization risks making the workloads that are deployed within it – including containers – vulnerable. Despite often being overlooked, the selection of a solid, secure foundation at the onset will define the rest of the container infrastructure.

2. Focusing on security of what’s inside of containers and not the containers themselves

Ensuring what is inside a container is of paramount importance as the contents can compromise the security of a container. However, when the focus is heavily on securing the contents of a container, sometimes that comes at the cost of securing the container itself. Since a container is essentially a running process on a Linux host that is “contained” – a container inherently shares kernel space with the host.

This means that while containers provide many advantages over traditional virtualized deployment environments, they have a different type of attack vector that organizations need to understand. Hence, it is important to ensure the container technology your organization deploys provides security coverage and protection against seen and unforeseen attacks and attack vectors.

3. Not securing APIs

Securing applications includes managing application and API authentication and authorization. When working with applications composed of microservices, APIs are key. However, when applications have multiple independent API services, the number of service endpoints increases and additional security measures are required.

An API management tool can mitigate security issues and can provide control features beyond basic security and authentication, including actions such as restricting access to specific endpoints, applying access policies for groups of users or setting per-period limits for incoming API calls to protect infrastructure and keep traffic flowing smoothly.

4. Not tracking known vulnerabilities

The list of known vulnerabilities is constantly evolving, so organizations should make sure they check the contents of container images when first downloaded and continue to track vulnerability status over time for all approved and deployed images. Container scanning tools that deploy continuously updated vulnerability databases can offer up-to-date information on known vulnerabilities when using container images from other sources.

Deploying a private container registry is also recommended. Doing so enables organizations to manage access to, and promotion of, downloaded container images and any internally built images.

5. Allowing containers to run as privileged

Deploying or creating any application or process with the least privilege possible is important and still the best practice for containers. Since – as noted before – containers share kernel space with the host OS, enabling a container to run in fully privileged mode would allow whatever is running in the container unrestricted access to the host system. As a result, this can cause a very clear security concern.

Unfortunately, while most container use cases should not need to run as root, many images still do. Hence, it is recommended that administrators leverage security context constraints (SCCs), to define – at specific levels – the capabilities of a running container within the host OS including what it can see and what it can do.

6. Failing to integrate containers into a continuous security loop, including image provenance, patching, and security scanning and policy-based monitoring

Once containers are up and running, it is important to maintain continuous security through the development and management of the containers. Doing this is a key to securing the entire software stack. By adhering to a “build once, deploy everywhere” philosophy, developers ensure that the product of the build process aligns directly with what is ultimately deployed in production. And the continuous integration process should include policies that flag security issues immediately, halting the process of deploy before vulnerabilities can be exposed.

When digging further into the security considerations while deploying containers, it is important to look at:

Software Supply Chain and Image Provenance: With a trusted source registry, organizations can ensure secured, patched, and up-to-date images. The security approach for deployed workloads should be based on where container images originated, what they are running, and how they are running.

Patching deployments: Automatic patch detection enables patching to be more efficient and less time consuming, ensuring that continuous security becomes part of the CI/CD model.

Security Scanning and Policy-based Monitoring: Real-time monitoring and security scanning of images ensures an added layer of security.

7. Neglecting to align enterprise security needs with the agility of containers

Containers are designed to come and go quickly, challenging some traditional and relatively static security practices. It is important to adopt security solutions designed to work with the speed and agility of containers. Consider network defense: organizations want a container platform that uses software defined networking (SDN). This provides a unified cluster network that enables communication between containers across the cluster and allows organizations to segment the network traffic to isolate different users, teams, applications and environments within the cluster.

Beyond security, any container platform must to provide an experience that works for any given developer and operations team. Security can work hand in hand with an enterprise-grade container-based application platform without compromising functions and while improving operational efficiency and infrastructure utilization.