Containerisation in the enterprise - Qualys: There's (sometimes) a hole in my bucket

As businesses continue to modernise their server estate and move towards cloud-native architectures, the elephant in the room is the monolithic core business application that cannot easily be rehosted without significant risk and disruption.

These days, it is more efficient to deploy an application in a container than use a virtual machine. Computer Weekly now examines the modern trends, dynamics and challenges faced by organisations now migrating to the micro-engineered world of software containerisation.

As all good software architects know, a container is defined as a ‘logical’ computing environment where code is engineered to allow a guest application to run in a state where it is abstracted away from the underlying host system’s hardware and software infrastructure resources.

So, what do enterprises need to think about when it comes to architecting, developing, deploying and maintaining software containers?

This post is written by Paul Baird in his capacity as CTSO UK at Qualys — the company is known for its software that works to automate the full spectrum of auditing, compliance and protection for IT systems and web applications.

Baird writes as follows…

Containerisation creates a more agile environment for developers allowing them to support an organisation’s needs for faster development and production deployments. One of the primary benefits of using containers is scalability based on demand. With automated container orchestration tools like Kubernetes managing this process, the end result is that containers should deliver more reliable and available applications in the cloud.

Gartner estimates that more than 75 percent of global organisations will be running containerised applications in production by 2022. This is more than double the current amount of enterprises. However, while containers deliver workload isolation, abstracted application and immutability, this approach did not consider IT operations and security as part of the model from the start.

A hole in my bucket

So containers and security – what are the potential problems?

Containers break the rules on traditional approaches to asset management and security, as each image can be created, used to meet demand then turned off. Many images are stateless and leave no fingerprint that they existed, making life much more difficult for the IT security team to protect and manage these environments.

For enterprise teams, expanding the use of containers should go hand in hand with work on how to keep those instances secure.

This will lead to a need for more collaboration between IT Security and the software development team.

Container immutability can stop some problems that would affect other applications, but containers have their own complications. For example, a single insecure image can exist in a registry and then be created many times over as separate running containers and thus create a widespread attack surface.

Here are the possible issues in container deployments to look out for:

Host level problems – if a container host is misconfigured or has a vulnerability, then it can be compromised. Equally, the application on the host could be vulnerable through a newly-discovered issue, so track this as well.
Container image compromises – this would be where vulnerable software is included in the base image within the registry, which would then be included in all containers that are created.
Container vulnerabilities – a vulnerability or misconfiguration in the container itself is another potential risk.
Other stuff – attackers can also look out for ways to break out of a single container and into the wider network, or to move laterally from a compromised machine on the network and into the container implementation.

How to approach security with containers

Qualys’ Baird: Don’t use container [buckets] until you think about the potential holes.

In order to implement security around containers, there are some best practices to follow around deployments, as well as for the wider software development process. The first element is to enforce a default approach to security within the container image. This would include implementing rules such as no ssh access into running containers and not allowing the httpd process to run as a webserver on port 80 inside a database container.

The second element is to look at how security can be built into the software development process around containers. Steps to take here include implementing security scans as part of the build pipeline as it goes along, as part of the container registry and for container runtimes once they are up and operational. By looking at the whole lifecycle for containers – from how software is being developed through to production – it is easier to spot issues.

It’s also important that this should be part of the overall process for developers. Rather than trying to apply security tools separately, any approach should integrate into the tools that developers use every day using APIs. If this is not put in place, it will delay the process and defeat some of the reasons for using containers in the first place around agility and speed to develop software.

Lastly, your IT security team should implement some processes that are container-aware too.

Telemetry indicators

This will include looking at how they adapt some of their existing security processes to cater for container deployments. Examples here include looking out for potential compromises over time using telemetry for indicators of attack or compromise, file access monitoring and network access control tools. This can see if any files are accessed, processes run or IP addresses communicating with where they should not.

However you view containers, they are here to stay for developers. To make the most of them, we have to look at how to make them more secure without getting in the way. For enterprises, looking at the whole pipeline around software development and integrating into developer workflows is the approach that is most likely to succeed.