Why DevSecOps Is Critical for Containers and Kubernetes
DevSecOps is a big and sometimes difficult shift for organizations. The key to success? Take small steps.
DevOps has enabled organizations to harness the automation and speed of deployment that cloud-native technologies such as containers and Kubernetes provide. However, if security is not tightly integrated into DevOps, organizations’ ability to take full advantage of the cloud-native model is severely diminished. If this sounds familiar, your company is at best getting less bang for its cloud-native buck and at worst putting the business and customers at risk.
Indeed, today’s rapid and frequent development cycles demand that security be an integral and shared part of the entire app life cycle: DevSecOps. For example, it is best practice never to patch a running container but, rather, to always rebuild and redeploy. To do this well and at speed, organizations must use automated unit and functional tests, and they need to integrate automated security gates.
In fact, you really can’t make the shift to a true DevSecOps model without investing in automation throughout the infrastructure and application life cycle. For example, solutions such as Ansible and Kubernetes operators have enabled organizations to add automation to Kubernetes itself. ArgoCD is another solution that is getting some real traction by applying the GitOps model to Kubernetes cluster configurations. (After all, it’s just as important to manage the configurations for your application platform as it is for the applications themselves.)
Not all of the security tools companies have been accustomed to using will work well in this new model. Containers and Kubernetes have created challenges for traditional security tools that can’t adapt to the degree of automation and the speed of deployment that these and other cloud-native technologies deliver. Fortunately, there is a broad ecosystem of container/Kube-native solutions available, ranging from analysis tools that integrate with the CI/CD pipeline to the container runtime and to Kubernetes network security. Moving forward, container-optimized operating systems will change how we think about managing and securing the host operating system itself.
But DevSecOps is not just about tools; it’s also about culture and process.
In many companies, the role of security is still isolated to a specific team in the final stage of development. This model runs completely counter to the cloud-native development model, in which there is a shared responsibility for security (and everything else). If teams can’t see the benefits of collaboration and instead stick to their own silos, it can indicate a lack of communication that will most certainly lead to a debilitated application development pipeline — which can then lead to an inability to compete as customers go elsewhere for the apps and services they demand.
With that said, DevSecOps is a big and sometimes difficult shift for organizations. Team members need to understand that this direction is supported by their management and that it will be valuable to both them and their organizations to collaborate and to update their skill sets for the technologies that support and enable a more dynamic development and deployment pipeline.
The key to getting there is to take small steps. It is helpful to start with a pilot project: Identify a project and cross-functional team (app dev, ops, security) to implement a DevSecOps pipeline and process. Identify goals and use cases, and prepare to iterate. Once the team is working well, document the implementation and the results, including business value (such as faster time to market or ability to address security issues up front). At Red Hat’s Open Innovation Labs, we’ve seen organizations that have adopted DevSecOps improve their time to market by 81% (moving from a 38-week deployment cycle to a 7-week cycle), and a 97% improvement in confirming functionality is complete (from 4 weeks to 4.5 hours).
Once the project has been successfully completed, recruit key and enthusiastic contributors and executive sponsors across the appdev, operations and security teams to evangelize and help expand the model to other parts of the organization. But, again, continue to plan to adapt. As much as possible, give teams the agency to meet goals in the way that works best for them, while also providing guidance on best practices and supporting consistency.
If DevSecOps is put effectively into motion, each team will certainly have plenty to promote — most notably, its ability to enable the organization to fully leverage the power of cloud-native models in general and containers and Kubernetes specifically.