IT pros determine the nuances of GitOps security and maturity

GitOps is still an emerging technology, but as advanced computing grows, companies are starting to seriously work out the details of its use.

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

GitOps comes from GitFlow, a broader model for managing the code and health of applications and infrastructure centrally in git repositories, using IT automation. Both have grown in importance as Agile and DevOps software delivery techniques have taken hold, and “all-as-code” products have emerged that can be used for everything from application code to software. management of IT compliance policies.

CI / CD pipelines are still the most widely used in enterprise IT. These subject application and infrastructure code updates to a linear series of tests and doors before deployment. In the most advanced GitOps environments, any changes to the Git repositories are automatically applied to the live infrastructure via tags for testing, QA, or production.

GitOps appeals to some early adopters for its IT governance benefits, but it also represents another shift in mindset and workflows for IT teams who have already undergone multiple upheavals over the past five years.

“The types of things you end up doing are different enough for companies that need to get familiar with the idea of ​​things like deploying infrastructure as code directly from a git repository,” said Jeffrey Hammond, analyst at Forrester Research. “You must have kind of passed the ‘I love you, you love me’ DevOps stage.”

GitOps maturity driven by edge computing

While GitOps represents the latest in a series of daunting learning curves for an enterprise IT industry already struggling with a skills shortage. But Hammond said he believes the proliferation of advanced computing, especially IoT devices, will also increase the popularity of the GitOps approach among businesses over the next several years.

Jeffrey Hammond

“What if I start deploying my APIs at the edge rather than the core? I didn’t even have time to learn the current cloud model, ”Hammond said.

Nonetheless, distributing APIs and processing power to edge nodes that connect to legacy systems such as mainframes will always appeal to some organizations more than trying to refactor and migrate those workloads to public clouds, a he declared. And that’s where GitOps comes in.

“GitOps is almost required at the edge … the last thing you want to do is deploy [individually] at a hundred different edge nodes, ”Hammond said. “You want the system to deploy it for you in minutes, and that doesn’t happen without a GitOps workflow. “

Business proponents of open source GitOps frameworks, such as Weaveworks, are reconfiguring their product lines to create a bridge between advanced cloud-native IT teams led by developers and traditional enterprises.

Weaveworks this week presented Weave GitOps Core, a free and organized version of the open source GitOps tool Flux version 2, with the aim of making it easier to start up teams of developers from departments within large companies. Those users can then upgrade 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 Weaveworks’ point of view.

“They need to do more to raise awareness, and more and more, [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 sparks debate

For most companies that have adopted 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 organizations are running – one per workload or per team – you can limit the explosion radius [of security vulnerabilities]”said Stan Brinkerhoff, senior software engineer at Cox Automotive Inc., an online automotive retail company that owns brands such as Autotrader and Kelley Blue Book.

This segregation of duties has not hampered the organization’s larger work to instill a ‘you build it, you run it’ mentality, said Brinkerhoff, especially as the company embraced the deployment of GitOps. via Argo CD.

“Argo CD, for example, with GitHub Actions and EKS / Fargate [involves] very little work around CI / CD tools, “he said.” With fewer custom Jenkins pipelines, teams can more often Google how to use a feature … rather than writing undocumented code for pipelines. “

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

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 although Flux uses native git and Kubernetes RBAC mechanisms, it also acts as an intermediary 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 peripheral 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 these things manually, ”said Oliver Schoenborn, an independent Cloud DevOps engineering contractor at Sentian Cloud Computing Inc.“ As such, the tool that is triggered by Git commit should [share] the permissions of the user who made the commit. “

The multi-repository approach and policy-based management of separate applications and infrastructure repositories “seems expensive to me,” Schoenborn said during discussions at the virtual GitOps summit event this month. “Even for a regular commit, [the developer] must wait for someone else who has write access to this other repository to send 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.

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

“We had someone who requested something similar a while back,” said Henrik Blixt, senior director of open source and platform at financial software maker Intuit, who created Argo CD, highlighting an April 2020 GitHub issue. “But it was closed when we released [the ApplicationSets controller], which solved this person’s use case. “

Flux officials, however, said they would consider Schoenborn’s request.

“Flux leans this way, [while] Argo has its own RBAC, ”said Alexis Richardson, CEO of Weaveworks. ” But [as] you start to integrate on many systems then you need the overlap overload, aka policy. “

Open questions remain as GitOps matures

For industry analysts, these discussions indicate that GitOps is still in its infancy and is subject to a persistent gulf between the interests of small, developer-led organizations and large enterprises with larger IT teams. important.

Daniel Kennedy, 451 ResearchDaniel kennedy

“[Schoenborn’s] is a classic developer position … that they spend too much time telling people how things should work – ‘let me do what I have to do,’ ”said Daniel Kennedy, analyst at 451 Research, a division of S&P Global. “But on a certain scale, there are scalability issues that developers don’t necessarily want to be involved with, and they shouldn’t be, because no company wants a developer who [is paid] more to spend time maintaining infrastructure.

Schoenborn acknowledged this concern for large companies, but “small organizations should have access to safe practices as well,” he said, “especially since there is no technical reason why this should not happen. cannot be done “.

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

“Currently, permissions and defaults in Kubernetes are suboptimal from a security perspective, so improving automation and control will be appealing to some organizations,” said James Governor, analyst at RedMonk . “I think automation, controls, and guardrails for Kubernetes infrastructure are the next wave for the platform, as much as an improved developer experience.”

Businesses can use tools like the Open Policy Agent as GitOps matures to deal with segregation of duty issues, the governor said.

“One of the benefits of GitOps is that you know who changed what, when and why, from a central policy perspective,” he said.

Beth Pariseau, Senior Editor at TechTarget, is an award-winning veteran of computer journalism. She can be reached at [email protected] or on Twitter @PariseauTT.

Source link

Previous Shogun, e-commerce technology platform, wins $ 67.5 million
Next [Jobs Roundup] Work with starting the LocoNav full fleet software with these openings

No Comment

Leave a reply

Your email address will not be published. Required fields are marked *