Unleashing the power of cloud with containerisation
New NCSC guidance describes how organisations can make the most of containerisation.

vertigo3d via Getty Images
One question that the NCSC is often asked, is whether to use containers in the cloud. It’s a straightforward question, but the answer is quite nuanced, as there are many ways that containerisation can be used, some of which work much better than others.
Today we are releasing security guidance on using containerisation, so it felt like the perfect opportunity to discuss how to get the most from it, and how it fits into using a cloud platform.
There’s lots to love about containers
Used well, containerisation can bring many security and operational benefits to your cloud services. It’s probably best to start with these advantages (and why we want them) before we then discuss how to make them a reality.
The Open Container Initiative provides standards for both container images and how to run containers. This means that we can reliably build and run containers using many different tools and ecosystems, while still getting all the benefits of cloud from the software that runs in the container. This is the ideal balance for technical lock-in in the cloud. For example, cloud services can securely provide credentials to the containers they run.
The container image format makes it easy to analyse its contents, such as for vulnerability scanning. This gives us a broad set of capabilities that have failed to materialise for other formats like virtual machine disk images. Even better, these can be applied across the entire container ecosystem, unlike tools that focus on the packaging format of just one programming language.
Unlike a virtual machine, containers can be managed and analysed at runtime by tools that aren’t present in the container. This means we can use minimised container images without sacrificing security, debugging, or other operational capabilities.
Container images include a lot of important context that is helpful at runtime. For example, container images specify the process that will be started when the container runs, which can make container-aware protective monitoring and incident detection more effective. Similarly, ‘secrets’ (like API keys and other credentials) can be injected into the container securely and containers can be connected at runtime to achieve service mesh architectures. These open up new possibilities for secure architectures while reducing the burden on engineering teams.
Containerisation is not the only way you can achieve these benefits, but it is one of the simplest way to combine these properties. Nevertheless, you should consider your specific use case and take the approach that works for you.
Security opportunities, not guarantees
It’s important to recognise that the security benefits associated with containerisation are opportunities, not guarantees. In other words, if you take an existing application and turn it into a container, you are unlikely to gain any security benefits if you do nothing else. In fact, if you take applications that used to be in separate machines (or virtual machines) and put them all into containers on one machine, you may have worsened your security posture.
To get the most out of containerisation, you need to invest time and resources to adapt your approach to be ‘container native’.
As we cover in our new guidance on using containerisation, you need to adapt how you build container images and run containers to ensure that you make the most of the security opportunities that containerisation can bring.
When you use containerisation in the cloud, you also need to think about how much responsibility you can share with your cloud provider so that they can achieve these security outcomes on your behalf. For example, when using serverless compute services that will build your code for you, the service can make it easier for you to test your workloads locally, or to analyse their contents by giving you the ability to export the container image it builds.
How much separation is enough?
One of the most common discussion points in container security is whether containers provide a security boundary. I think it’s better to think about the security outcomes you’re trying to achieve. You wouldn’t normally run code you didn’t trust alongside sensitive data or workloads, and containerisation doesn’t change that. You should always expect robust compute separation between your workloads and other people’s. Depending on the specific application, you may also want strong separation between each of your own applications.
As we say in technically enforced separation in the cloud, kernel-enforced compute separation (such as containerisation) does not provide strong separation. But this doesn’t mean we can’t use containers! Instead, you should use options like hypervisor-enforced separation to separate containers from one another, when strong separation is necessary.
Adapting to the cloud
As we’ve discussed in our guidance on using a cloud platform securely, it’s important to think about how you adapt to the cloud, and this is just as important with containerisation. While containerisation may be how you meet your security requirements, you should still expect your cloud provider to do the heavy lifting for you. You should be wary of services where:
-
you must manage the compute cluster that hosts the containers
-
the cloud provider cannot help you to build container images
-
the execution environment runs containers in non-standard ways
-
you cannot integrate with the cloud platform’s normal authentication and access control mechanisms
-
you cannot apply strong compute separation between your containerised applications
So should you use containers in the cloud?
It all boils down to how you use containerisation:
-
If you build container images well, using tools and services provided by your cloud provider, and your provider runs those containers for you, you can make full use of the power of the cloud.
-
If you run a container cluster yourself on infrastructure-as-a-service, then you significantly limit the benefits of the cloud.
In many cases, it won’t even be visible to you that you’re using containerisation. This will be the case in many SaaS applications and PaaS services where you provide some code and your cloud provider does the rest. Just because containerisation helps make the most of cloud, doesn’t mean you need to be able to see the containers.
Containerisation is one of the best ways to take full advantage of the cloud, so you should be focusing less on whether to use containers, and more on how to use them.


