Protecting containers in runtime is a critical element in securing containerized applications. There are a number of threats that occur in real-time when containers are running in production so a container security strategy must go beyond just eliminating vulnerabilities during the build phase. Containers in runtime and working applications can hold the crown jewels of your organization and the end of the software development lifecycle cannot be the finish line when it comes to security. Even with its obvious importance, traditional security monitoring and protection tools do not work effectively for containers in production.
Endpoint detection and response (EDR) and endpoint protection platforms (EPPs), for example, cannot scale to massive container deployments and delivers a performance impact that effectively hinders the ability for production environments to operate as required. Security appliances don’t work either, as they lack visibility into container traffic and without the right data and context, will simply drown a SOC with alerts and false positives.
There are three main challenges to address in order to enhance or improve security for containers in runtime: monitoring, isolation, and response.
1 – Container Runtime Monitoring
First, there’s the monitoring challenge: Containers are ephemeral, which is core to their value in the first place but makes monitoring incredibly difficult. In a monolithic client-server application monitoring usually covers the application plus all the servers involved with its operation and the communication platform that connects them. There’s no way to apply this same approach to a containerized environment without drastically affecting application performance. Traditional monitoring tools also lack visibility inside the container, at the API level, and will struggle to keep up with the rapid deployment rate of container workloads.
2 – Container Runtime Isolation
Second, there’s the isolation challenge. Containers that are spun up on the same host share the same underlying operating system. So not unlike when one Christmas light goes out and they all go out, if one container is compromised, there is a good chance that the other containers on the same OS could be compromised as well.
When considering container security strategies you’ll want to find an approach that not only allows for high integrity detection of threats but one that also provides contextual intelligence so you can understand if your threat has compromised the shared OS and respond appropriately.
3 – Container Runtime Response
Third, the response challenge: This is where a runtime problem isn’t just a runtime problem. If you identify a container has been compromised, you may want to take it down, which could include the composition and deployment of a new image. This means taking on a dev-to-production task that necessitates the integration of CI/CD pipelines with runtime detection and response.
Despite these challenges, there are also fundamental traits of containers that can help keep container runtime protected. Immutability, for example, ensures that a running container, as an instantiation of the image, can be stopped or replaced, but not updated dynamically. Think of this as a type of version control in that nothing can change on the fly, for good or more importantly, for bad, for containers in runtime.
So what can you do about it securing containers in runtime? We recently put together 12 key questions to help ensure security is integrated beyond just the development lifecycle and included as part of a production deployment.
There also needs to be a shift in your security strategy to stay focused on runtime security. It can be tempting to relax once you feel confident you scanned for all the vulnerabilities before putting a container into production, but threats such as zero-day attacks are always looming.
To learn more about container security and why it is so challenging in the production environment, check out our article on container security challenges