IT pros work out the nuances of GitOps security, maturity

GitOps maturity spurred by edge computing

While GitOps represents the latest in a daunting series of learning curves for an enterprise IT industry already struggling with a skills shortage. But Hammond said he believes the proliferation of edge computing, particularly Internet of Things devices, will also increase the popularity of the GitOps approach among enterprises over the next few years.

Jeffrey Hammond

"What happens if I start deploying my APIs at the edge instead of the core? I haven't even had time to learn the current cloud model," Hammond said.

Still, distributing APIs and processing power to edge nodes that connect back to legacy systems such as mainframes will still appeal to some enterprises more than trying to refactor and migrate those workloads to public clouds, he said. And that's where GitOps comes in.

"GitOps is almost required at the edge ... the last thing you want to do is deploy [individually] to a hundred different edge nodes," Hammond said. "You want to have the system roll it out for you in a matter of minutes, and that doesn't happen without a GitOps workflow."

Commercial supporters of open source GitOps frameworks, such as Weaveworks, are reconfiguring their product lines to create a path between cutting-edge, developer-driven cloud-native IT teams and traditional enterprises.

Weaveworks introduced Weave GitOps Core this week, a free, curated version of the open source Flux version 2 GitOps tool, with the goal of making it easier for departmental developer teams within larger companies to get started with it. Those users can then move directly to Weave GitOps Enterprise, also updated to support Flux v2 this week, which supports multiple Kubernetes clusters and multiple clouds for $3,000 per Kubernetes node.

Or, at least, that's the idea, from a Weaveworks standpoint.

"They need to do more to build awareness, and increasingly, [will also be competing with] vendors like VMware with Tanzu, and Microsoft with GitHub," Hammond said. "They have their work cut out for them."

GitOps security tension prompts debate

For most early-adopter enterprises using GitOps, the most common approach is to maintain at least two separate Git repositories for application and infrastructure code, often managed by two or more separate teams.

"With smaller accounts as many orgs run -- one per workload, or per team -- you can limit blast radius [of security vulnerabilities]," said Stan Brinkerhoff, principal software engineer at Cox Automotive Inc., an online automotive retail company that owns brands such as Autotrader and Kelley Blue Book.

This separation of duties hasn't hindered the organization's broader work to instill a "you build it, you run it," DevOps mentality, Brinkerhoff said, especially as the company has embraced GitOps deployment through Argo CD.

"Argo CD, for example, with GitHub Actions and EKS/Fargate [involves] very little toil around CI/CD tooling," he said. "With fewer bespoke Jenkins pipelines, the teams can more often Google how to use a feature ... versus writing non-documented code for pipelines."

But to some IT experts, the connection between application developers and GitOps deployments should be strengthened further.

The most popular GitOps open source tools, Argo CD and Flux, can connect developer identities with specific Kubernetes identities, but do so indirectly. Argo has its own role-based access control (RBAC) system for this, and while Flux uses native git and Kubernetes RBAC mechanisms, it also acts as a middleman between them using policies.

GitOps is almost required at the edge ... the last thing you want to do is deploy [individually] to a hundred different edge nodes

"GitOps tools should be able to do things on behalf of an individual [developer], to save them from having to do those things manually," said Oliver Schoenborn, an independent cloud DevOps engineering contractor at Sentian Cloud Computing Inc. "As such, the tool that gets triggered by Git commit should [share] the permissions of the user that did the commit."

The multi-repository approach and policy-based management of separate application and infrastructure repos "seems onerous to me," Schoenborn said during discussions at the GitOps Summit virtual event this month. "Even for a regular commit, [the developer] needs to wait for someone else who has write access to that other repo to push a change to a Helm chart before they can test their changes."

In Schoenborn's view, this process is too slow and cumbersome to support true continuous deployment.

Argo and Flux maintainers had different responses to Schoenborn's desire for a more direct connection between Git authors and infrastructure.

"We had someone ask for something similar some time back," said Henrik Blixt, principal manager of open source and platform at financial software maker Intuit, which created Argo CD, pointing to an April 2020 GitHub issue. "But it was closed as we released [the ApplicationSets controller], which solved that person's use case."

Flux maintainers, however, said they'd take Schoenborn's request under consideration.

"Flux leans this way, [while] Argo has its own RBAC," said Alexis Richardson, CEO at Weaveworks. "But [as] you start integrating across many systems, then you need the overhead of cross-checking , aka policy."

Open questions remain as GitOps matures

To industry analysts, these discussions indicate that GitOps remains in its infancy, and is subject to a lingering divide between the interests of smaller, developer-driven organizations and larger enterprises with bigger IT teams.

Daniel Kennedy

"[Schoenborn's] is a classic developer position ... that they spend too much time explaining to folks how things should work -- 'just let me do what I need to do,'" said Daniel Kennedy, an analyst at 451 Research, a division of S&P Global. "But at a certain scale, there are scaling concerns developers don't necessarily want to be involved with, nor should they be, because no enterprise wants a developer who [is paid] more to spend time maintaining infrastructure."

Schoenborn acknowledged this concern for large enterprises, but "small orgs should have access to safe practices, too," he said, "Especially since there is no technical reason it can't be done."

Other industry watchers said Schoenborn's perspective points to the future evolution of GitOps and Kubernetes.

"Currently permissions and defaults in Kubernetes are sub-optimal from a security perspective, so improving automation and control will be attractive to some organizations," said James Governor, an analyst at RedMonk. "I believe that automation, controls and guardrails for Kubernetes infrastructure is the next wave for the platform, as much as an improved developer experience."

Enterprises can use tools such as Open Policy Agent as GitOps matures, to handle concerns about separation of duties, Governor said.

"One advantage of GitOps is that you know who changed what, when and why, from a central policy perspective," he said.

Beth Pariseau, senior news writer at TechTarget, is an award-winning veteran of IT journalism. She can be reached at [email protected] or on Twitter @PariseauTT.