Container orchestration frameworks like Kubernetes have brought about untold technological advances over the past decade. However, they have also enabled new attack vectors for bad actors to leverage. Before safely deploying an application, you must answer the following questions: How long should a container live? Does the container need to write any files during runtime?
Determining the container’s lifetime and the context in which it runs is critical, especially when hosting an internet-facing service.
What is Container Drift?
When deploying an application within Kubernetes or OpenShift, a container image must first be created from a build file. This image serves as a static snapshot of what an application will look like when it’s first executed at runtime.
These images comprise several layers, each typically mapped to a single command in the original build file. One image layer, often called the “container layer”, provides a space in which a container can write. This writable space is useful for various reasons, such as updating the underlying operating system components of a container at runtime, storing application artifacts or storing log files that can be used for troubleshooting.
However, having this writable space poses several security risks. The longer the container writes to this space, the less the container has in common with the image it was created from. Experts often refer to this phenomenon as container drift.
A Security Blind Spot
As with any application running in a production environment, periodic security scans can detect software vulnerabilities. However, there are key differences when scanning a standalone application and scanning a program running within a container.
Due to performance concerns around running containers, security scans do not typically run against the container itself. Instead, the softw ..
Support the originator by clicking the read the rest link below.
