Sep 18, 2023

Presented by Orca Security Cloud-native applications have unique security risks. In this VB Spotlight, learn everything you need to know about locking down your containers and Kubernetes through all stages of the development lifecycle, the ideal DevSecOps journey and more. Containers, and Kubernetes in particular, are custom-made to run the microservices that make it possible to scale cloud adoption more effectively and make it more cost-efficient. They’ve also proven crucial in maintaining applications and staying agile — enabling fast updates and deployment. But containers and Kubernetes also have some unique security risks and challenges across all stages of the development lifecycle, and a partnership between DevOps and security is crucial, says Neil Carpenter, principal technical evangelist at Orca Security. “Security is now realizing that their existing tooling and processes don’t cover the magic new world of cloud applications and containers — they’re running to catch up and that’s a dangerous space,” Carpenter says. “Understanding what DevOps does, being part of the team, and building bridges is certainly a line item in a bigger picture, but it’s foundational to a strong security stance.” A look at container security risks There are two phases to running a container, and risk detection and elimination needs to be active in both, as well as a partnership between the IT security team and the DevOps team. The first phase encompasses the development of the container, and then everything that happens after it’s up and running. Before deployment The first half is typically a DevOps-driven process, with developers writing code and checking it in. Automation is used in testing, building container images and deploying them back into the pipeline for user testing and acceptance, and then into production. DevOps thrives on automation, Carpenter says, and the same problem is never solved twice — the solution is automated and it solves itself going forward. “For IT security professionals, this DevOps-driven world is new to us,” Carpenter says. “But vulnerability assessment is central to how IT security teams work, so scanning for critical vulnerabilities and fixing them before they become a problem is great for both the security team and development teams. Putting a collaborative process in place makes us all far better off.” Many DevOps engineers leverage infrastructure-as-code (IAC), which means writing the machine learning code that automates things like deployment, monitoring load, autoscaling, exposing ports and more. And this same code can be used to deploy across any number of environments. Security scanning IAC artifacts in the development pipeline, looking for problematic configurations is key — they can be caught and blocked before they’re ever deployed. Once it’s up and running The first challenge of a running container is ensuring that it’s securely deployed and configured. Unlike VMs, which are securely separated from each other, containers are not a security boundary. An engineer running a privileged container, or running as root, can read and write other containers running on the same machine. On top of that, risks also depend on the workload itself, which is a moving target. Even if you’re scanning it regularly, new critical vulnerabilities can be lurking around the corner. Developers need to have a full view of each container’s running workloads to look for anomalous behavior, unexpected outbound connections and unexpected process execution, as well as keep up with potential new risks. How DevOps is changing people and processes The most important issue in delivering secure cloud applications isn’t process or technology, it’s getting people together and tearing down boundaries. “I think traditionally security people, developers and DevOps have been natural enemies,” Carpenter says. “That’s not going to work in a cloud application world because so much of the responsibility for finding and addressing problems cuts across these lines.” For example, a remote code execution vulnerability in a Tomcat app running on VMs have the same vulnerability as containers running on Kubernetes in the cloud; what’s different is who will fix it and the process for fixing it. The security team can’t patch container vulnerabilities — they have to create a ticket for developers, and getting it fixed requires a completely different set of people and processes that are fairly alien to most security teams. “Bridge-building is critical,” Carpenter says. “On the security side we have to understand how this new world works and all the pieces that are involved. On the DevOps side, they have to have some understanding of why the security piece is important, and they need to deliver solutions in a way that integrates with the work they’re already doing, as well as drives what they’re already doing.” Piece two is on the security side, building out the end-to-end process and integration of security solutions, in a way that doesn’t break or interfere with the way DevOps works for the enterprise. “Don’t kill the agility,” he says. “Automate things so that everything’s at our fingertips, right where we need it, when we need it. When possible, provide context for why something is important or why something is not important. Be flexible where you can. Have exception processes that are easily manageable, monitorable and rational. Don’t be the engine of ‘no’ or whatever people use to refer to security as. Find that balance of risk where we can keep moving forward.” For a deep dive into the ways security and DevOps teams can address critical risk, the tools and solutions that can help mitigate security issues across teams and how to approach containers from the security perspective at every level of maturity, don’t miss this VB Spotlight.