Security Will Be Instrumental for the Success of GitOps
As the idea of using GitOps to speed deployments grows more intriguing to more organizations, questions around the security practices of this emerging practice are being raised.
This was the theme of this latest podcast from The New Stack, hosted by Alex Williams, founder and publisher of The New Stack. This podcast features Om Moolchandani, co-founder and chief information security and chief technology officer for security provider Accurics; Cindy Blake, senior security evangelist for GitLab, Frank Kim, fellow at the SANS Institute; Sanjeev Sharma, head of platform engineering, Truist Financial; and Katie Gamanji, ecosystem advocate for the Cloud Native Computing Foundation (CNCF).
“People are concerned because there hasn’t been a history of traditional tools to draw on” for GitOps, Blake said. “We’ve solved it first for embedding the scanning within your DevOps lifecycle. It may not sound like GitOps, but that’s what I would consider an essential foundation piece that you need to have for a secure software base to start with,” said Blake.
To this end, Accurics has done some work with GitLab to integrate their capability and bring those results into the developers’ pipeline.
GitOps could be not just about how to deploy software faster, but could also serve as a foundation for remediating vulnerabilities throughout the development and deployment process. “From a security perspective, we got the mean time to remediate which, people say, that’s anywhere from two to three months on average, in terms of fixing your serious security vulnerabilities,” said Kim. “And this is really what GitOps and these modern practices and tools allow us to do: to shrink that window of exposure, so we can better protect our organizations. I think that’s where we all want to want to get to.”
GitOps Modern Practices for Reaching a Desired State and Decreasing Exposure
Moolchandani defined GitOps as a process “that specifically relies upon Git, and uses infrastructures as code (IaC), as well as DevOps methods to deliver high-velocity CI/CD.” It is especially useful for deploying applications in Kubernetes environments but it can also be “applied elsewhere,” Moolchandani explained.
There has also been much discussion and adoption of GitOps in the community, which “is always a good sign, especially from the end-user community,” said Gamanji. CNCF projects Argo CD, a declarative GitOps CD, and Flux, used “to automatically ensure that the state of a cluster matches the config in Git” (according to FLux’s documentation), were early projects, and have seen adoption “within the end-user community, which is always a good plus,” said Gamanji. “So, I definitely think this is something that will be more present within the infrastructure nowadays. So it’s always good to explore it from different angles, especially with security.”
Gamanji’s mention of Flux prompted Kim to describe just how much GitOps, as well as continuous delivery, has evolved. He recalled how, when he first started working in the software field 20 years ago, applications were deployed in production every 18 months — a length in this day and age is practically unheard of. “It was ridiculous, and we didn’t have any of those tools or processes or methodologies that you guys were just describing…We didn’t even have Git, of course, back then,” said Kim. “And this is why I’m so excited about a tool like Flux, for example, ensuring the state of your Kubernetes clusters, matching your configuration.”
It is also “very encouraging” to see “large software vendors now talking about GitOps and including it in their commercially supported tools,” Sharma said. “That’s what will drive large-scale enterprise-grade adoption,” he said.