As Kubernetes’ popularity grows with IT teams, so does its allure to bad actors. That’s just the way of things in technology: More users, larger target.
Don’t expect this to do much to stem enterprise enthusiasm for Kubernetes, though. Its appeal outweighs the risks. There are some key areas for IT teams to proactively focus on when it comes to Kubernetes security, as we recently covered. There’s also plenty of good news on the security front, in the form of expert, from-the-trenches advice on how to unlock Kubernetes’ potential in a secure manner.
[ Read Part One of this series: Kubernetes security: 4 areas to focus on. ]
Here are four ways to ensure your move to containers and orchestration, and your ongoing work with them, avoids security missteps:
1. Bring security into the earliest stages of development
Whether you call it DevOps or DevSecOps or simply embrace the culture and methodologies those terms represent, the rising tide of Kubernetes adoption is exemplary of the need to break down traditional silos and embed security into every stage of the software development pipeline.
Especially if your organization is shifting from monolithic software to containers (and microservices, in many cases), treating security as a final step before deployment (or worse, as an emergency unit putting out fires in production) won’t cut it.
“Security measures are too often added into container environments only during the later stages of development,” says Gary Duan, CTO at NeuVector. “A superior strategy for threat mitigation, which enterprises are beginning to adopt more frequently now, is to ‘shift left’ and deploy security measures from the very beginning of the development process.”
Duan adds that as teams move from dev/test to production use of Kubernetes, there also needs to be a “shift right” mentality, meaning: You can’t trust that because something appears “secure” in a pre-production environment it will remain that way in the wild.
“As more enterprises use Kubernetes in production, it’s become increasingly necessary to ‘shift right’ and then secure container environments throughout the entire build-ship-run lifecycle,” Duan says. “In short, IT and security pros need to take a shift-left-then-right mentality for better end-to-end container security.”
Wei Lien Dang, VP of product at StackRox, notes a prerequisite for end-to-end security in container environments: Security pros must understand how their organizations are actually using containers and orchestration.
“It’s critical that security team members understand the specific use cases and needs of their DevOps teams so they can evaluate the best options for augmenting the native controls built into the container, Kubernetes, and Istio infrastructure,” Dang says. “Knowing the use cases will help security define and enforce good hygiene and will shape the requirements for third-party security solutions that address the needs of their company, across the full ecosystem of technology and the full software development life cycle.”
[ Get the related Red Hat whitepaper: Ten Layers of Container Security. ]
2. Actively participate in the Kubernetes community
Kubernetes has one of the liveliest (if not the liveliest) communities around. Getting involved is one of the best ways to get up to speed and stay abreast of best security practices. That community values the same thing you’re seeking: Making the most of Kubernetes’ power while minimizing any risks that come with its increasing adoption.
“This community clearly cares deeply about security, and it emphasizes education and inclusion, so security staff can look forward to a helpful, educational community from whom they can learn,” Dang says.
“Get educated and follow industry best practices, like the CIS Kubernetes Benchmark,” advises Amir Jerbi, CTO at Aqua Security. “Kubernetes is a complex system with many configuration options, any of which, if done wrong, could leave clusters open to attacks.”
Plugging into the vibrant Kubernetes community is a great step toward ensuring your organization’s implementation isn’t creating unnecessary vulnerabilities.
