Orlando Florin Rosu - Fotolia

IT pros work out the nuances of GitOps security, maturity

GitOps is catching on among enterprises, especially as edge workloads increase, but the industry must strike a time-honored balance between security and flexibility as it matures.

GitOps is still an emerging technology, but as edge computing grows, enterprises are beginning to sort out the details of using it in earnest.

The term refers to an infrastructure deployment pattern, usually associated with Kubernetes and container environments, in which all infrastructure provisioning and updates flow through Git code repositories.

GitOps involves managing application and infrastructure code and state centrally in git repositories, using IT automation. It has risen to prominence as Agile and DevOps software delivery techniques have taken hold, and "everything-as-code" products have arisen that can be used for everything from application code to IT compliance policy management.

CI/CD pipelines are still most widely used by enterprise IT. These put application and infrastructure code updates through a linear series of tests and gates before deployment. In the most advanced GitOps environments, any change to Git repositories is automatically applied to live infrastructure via tags for test, QA or production.

GitOps appeals to some early-adopter enterprises for its IT governance benefits, but it also represents another change to the mindset and workflows of IT teams that have already undergone multiple upheavals in the last five years.

"The types of things that you end up doing are different enough for enterprises that they need to get comfortable with the idea of things like deploying infrastructure as code right out of a git repository," said Jeffrey Hammond, an analyst at Forrester Research. "You kind of have to be past the DevOps 'I love you, you love me,' stage."

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, Forrester ResearchJeffrey 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
Jeffrey HammondAnalyst, Forrester Research

"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, 451 ResearchDaniel 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.

Dig Deeper on Application Rollout Planning and Problems

SearchSoftwareQuality
SearchAppArchitecture
SearchCloudComputing
SearchAWS
TheServerSide.com
SearchDataCenter
SearchServerVirtualization
Close