Container Security

Chapter 13. Container Runtime Protection

As we saw in Chapter 10, one of the characteristics of containers is they lend themselves to microservice architectures. Application developers can break down a complex software application into small, self-contained pieces of code that can be scaled independently, each delivered as a container image.

Breaking a large system into smaller components with well-defined interfaces makes it easier to design, code, and test the individual components. It also turns out to make them easier to secure.

Container Image Profiles

If a given container image holds the code for an application microservice and that microservice does one small function, it’s relatively easy to reason about what that microservice should do. The code for the microservice is built into a container image, and it’s possible to construct a runtime profile corresponding to that container image, defining what it should be able to do.

Every container instantiated from a given image should behave the same way, so it makes sense that a profile of expected behavior can be defined for an image and then used to police the traffic to and from all the containers based on that image.

Note

In a Kubernetes deployment, runtime security might be policed on a pod-by-pod basis—for example, through the PodSecurityPolicy object, or through security tools that also act at this level. A pod is essentially a collection of containers that share a network namespace, so the underlying mechanisms for ...