What is Container Security? Everything You Must Know

Container-based systems create new layers in software delivery pipelines. It's essential to protect the host OS, the container runtime, and the containers themselves, all of which run on the same hosting stack. This brings up new points to think about. We need to consider how we build and run containerised apps. 

How Container Security Differs from Traditional Security 

In the old days, cloud security was about protecting a single point of defence: a perimeter. Yet, the advent of containerisation brought this approach under scrutiny, as organisations must now rethink their security postures. The container ecosystem is no small feat, given the dazzling array of tools and unique challenges they present, which diverge so much from the traditional security methods we once knew.  

The container environment is more complex and dynamic. With container technologies, any changes need to be made upstream, unlike traditional methods where software is updated on the host it runs on.

Also, cloud native computing changed how we approach creating, deploying, and securing applications. To keep up with this, we must adopt new approaches and strategies and leave traditional ones in the dust.  

And while container technologies are gaining widespread traction, responsibilities are being “shift-left”. Meaning that, containers need protection right from the earliest stages of the CI/CD pipeline through to deployment and production (being driven by developers as they define software as code, infrastructure as code, etc.). Developers are asked to handle security in ways they haven’t before. 

What makes containers unique? 

Among the mere fact that containers differ from virtual machines (VMs) and other deployment methods, the most significant stand-off is that the entire application lifecycle is changed when adopting containerisation. 

• Containers have fewer dependencies on the underlying infrastructure to support them.  
• They're built from machine-readable images, allowing various operating systems and application types to coexist on the same machine. This setup ensures isolation among different applications while effectively optimising the use of machine resources. 
• Because they are so declarative and written in a way that they only do exactly as defined in the code application, they behave consistently – predictable. Consequently, any deviation from that expected behaviour results in an anomaly or suspicious activity that can be tracked.  
• Not only that, but containers are ephemeral by nature, as they allow you to spin up and down within minutes or seconds.  
• Plus, they are portable, which makes deployment across distributed environments (multi-cloud) more seamless.  

One issue can amplify across layers 

What sets container security apart is the impact of a single issue. When one container image is flawed, every instance of the container can be up to grabs of exposure, enhancing the attack surface. This grows as you have multiple containers spun up from the same image. And with public image repositories, one compromised image can be distributed to millions of machines worldwide. Visibility also becomes hard when containers are spread across your environment; the difficulty of seeing into system operations and security posture only worsens. 

Long-lived containers: A new paradigm 

What’s more, containers originated with the idea of ephemeral workloads (short-lived processes that spin up, perform a function, and then shut down). Now, containers are widely used beyond just short-lived microservices. Many traditional applications, which used to run on a VM, are now containerised and deployed. These long-lived containers introduce new security challenges we cannot hide from.  

Container Security Risks  

We can break down the risks of containerised applications into two stages: before production (as you build and create the app) and after deployment (when you run and operate the app). 

Container Images Risks 

• Image vulnerabilities: Deploying a container with vulnerabilities because of image versioning with embedded vulnerabilities. They may have missed a critical update or simply be outdated. 
• Image configuration defects: Not just software defects but also configuration defects can be a problem. 
• Embedded malware: Malicious files from unverified third-party software could also be part of an image. Images are bundles of files, so embedded malware can attack other containers in the containerized environment.
• Embedded clear text secrets: Putting secrets directly into the image file system is risky. Anyone who can access the image can easily extract the secret. These secrets could be credentials used by applications for secure communication between components. 
• Use of untrusted images: A drawback of container portability is the urge to run images from unverified sources. 

Container Registry Risks 

Container registries are usually trusted. However, if compromised, they can impact all downstream containers and hosts. These are the risks:

• Sensitive data exposure: Image registries pose a security risk. They hold images that include your application code, binaries, and libraries. You need to secure these valuables to prevent unauthorised access or tampering. 
• Poor authentication and authorisation: Registries can save images to run sensitive apps or access sensitive data. Weak authentication and authorisation can expose attackers to the application's intellectual property or technical details. 
• Insecure connections to registries: Connecting to registries over insecure channels can expose the content of an image to confidentiality risks. This also increases the risk of man-in-the-middle attacks that can intercept network traffic. 
• Stale images in registries: Registries store all images, which over time, may contain stale images with vulnerabilities. This increases the risk of accidental deployment of an obsolete or vulnerable image. 

Container Runtime risks 

Container runtime security means finding new vulnerabilities in running containers and securing applications from these threats. Container run times can be tricky. Traditional security tools monitor the communication of containers, but they don't track what occurs inside them. These are some of the risks: 

• Vulnerabilities in the runtime app: Runtime software vulnerabilities are uncommon. However, there are situations where malware can target resources in other containers or the host OS. This allows an attacker to get into other containers or monitor inter-container communication. 
• Outbound network access from containers: A compromised container with outbound access can scan networks and expose other resources. Managing egress traffic in containerised environments is tricky. Virtual connections make it hard to see the source, destination, and payload. Traditional security tools often fail to inspect this traffic, increasing the risk of undetected threats.
• Insecure runtime settings: Admins can modify container runtime settings, but some changes can make security weaker. Adding unnecessary permissions exposes both the container and the host OS to risk. Running containers in privileged mode makes the problem worse. It gives access to all host devices and can impact other containers too.
• App vulnerabilities: It’s not always the container that’s vulnerable. The app running in it could be your problem (e.g. SQL injection or cross-site scripting). If compromised, attackers can exploit it for unauthorised access and sensitive data.
• Rogue containers: Developers create containers to run tests. But if no one checks them for vulnerabilities and misconfigurations, they can be a target for attackers. What makes it worse is that these containers can be stealthy. Your dev team and security admins may not even know they’re there. 

Container Orchestration Risks

• Vulnerabilities in the orchestrator stack: Orchestrators were created with full admin access for the entire environment. But an orchestrator can be used to run applications by different teams. If access isn’t granted at a granular level based on role and scope, malicious or careless use can impact other containers managed by the same orchestrator. 
• Unbounded admin access: Orchestrators have their directory service separate from the rest of the organisation’s directories. This can lead to weaker account management practices and orphaned accounts, compromising the whole system.
• Poor inter-container network: A major risk is the traffic between applications on the same virtual network. If two applications have different sensitivity levels, this can create security gaps. For example, if a front-end website is compromised, an attacker can use the shared network to get to a more sensitive application behind it.
• Mixing workload sensitivity levels: Orchestrators improve density and scale. This lets various workloads operate on the same host. A public web server can work together with financial data processing, which is sensitive. If the web server is vulnerable, your financial data can be compromised. 

Host OS Risks 

• Attack Surface Optimisation: Any service you expose to the network is an attack surface. Container-specific OSs have a smaller attack surface than general-purpose OSs. This is because they lack unnecessary libraries and package managers. However, they have a larger attack surface than a hypervisor because they share the same kernel. 
• Foundational System Components: Every host OS, even those made for containers, has vital system components. These are cryptography libraries and kernel primitives. If those have vulnerabilities, they can compromise all the containers and applications running on the host. 
• Direct Host Access Risks: When users log into the host directly to manage containers, they create security risks instead of using an orchestrator. Direct access lets users make big changes to the system. A user handling one application’s container could accidentally or purposely harm other containers. 
• Insecure Container Configurations: Misconfigurations can expose host volumes to file tampering. If a container can mount a sensitive host directory, it can modify essential system files that affect the host and all its containers. 

Container Security Best Practices 

It is essential to implement various security measures throughout the full lifecycle to secure containers, from development to deployment and runtime.

Containerised applications require you to focus on multiple-layer defences. Let's break down the best practices for container security:

Closing thoughts

As much as we'd like a magic bullet for container security, finding one is very unlikely. Instead, a multi-layered defence is key, also known as defence in depth.

As no system is perfectly secure, it’s about mitigating risk at an appropriate level for each application.