Five Tips For Securing GitOps Environments
Written by Sigal Zigelboim   
Thursday, 13 October 2022

GitOps, a novel term introduced over the last 5 years, refers to a process of automating IT infrastructure using infrastructure as code and software development best practices such as  version control, collaboration, compliance, and CI/CD. Learn about the basics of GitOps together with five best practices that can help you secure your GitOps environment.

GitOpsMetawide

What Is GitOps?

GitOps is a new methodology to help deliver software applications and manage containerized environments. It uses a Git repository as the single source of truth for applications and their declarative infrastructure. 

GitOps involves using software agents to recognize any divergence between an application’s desired state in Git and the actual state in a live environment. An automated reconciler updates or rolls back the live environment if it identifies the application as out-of-sync. 

Development teams can leverage familiar tools based on Git to control their application delivery pipelines. Developers can use pull requests to simplify and accelerate application deployment and many other tasks traditionally handled by IT or complex cloud automation.

How Does GitOps Work?

Here are key principles of GitOps:

Infrastructure as Code (IaC) 

GitOps involves using a separate repository for your IaC project. You host the IaC project in a Git repository that automatically version-controls the project and facilitates team collaboration. Instead of pushing changes to the main branch, you need to go through the same pull request procedure. It enables everyone on the team to submit a pull request, make code changes, and collaborate uniformly with team members on the same pull request.

Separation between CI and CD

GitOps requires using a CI pipeline to validate config files and test them similarly to testing application code changes. Afterward, the pipeline tests application code commits. You can set up a process that requires team members to approve the final changes. The goal is to facilitate collaboration and visibility between contributors.

When developers or security experts examine and approve the pull request, you can ensure that config changes are well-reviewed before they are applied to the environment. Next, the pipeline merges the changes into the main branch and deploys them using a continuous deployment (CD) pipeline.

Best Practices to Secure GitOps Environments

Here are some security best practices when implementing GitOps.

Strike the Right Balance When Shifting Left

Shifting security left doesn’t only mean delegating security tasks to developers. It involves adjusting the team’s expectations, assigning new roles, and implementing the appropriate tools. The security team is still responsible for risk management and must ensure regulatory compliance requirements, minimize attack windows, and protect sensitive data. However, the security team can also encourage the development team to adopt a more active role in the security process. For example, developers should test the code they write. Security admins can configure policies to help reduce misconfiguration issues and provide static application security testing (SAST) and dynamic application security testing (DAST) tools that developers can easily use. 

Testing and security tools must be easy to configure and send alerts directly to developers while minimizing false positives. The security team might instruct developers on how to use tools or connect them to CI/CD pipelines. The right tools simplify security by automatically scanning code for issues and providing fast feedback without stopping the development pipeline. 

Split the CI and CD Process

Traditionally, DevOps treats the CI/CD pipeline as a single process. The GitOps workflow separates this pipeline into two distinct processes:

  • The continuous integration (CI) process involves building and packaging the application code into container images. This process remains unchanged when you transition to a GitOps model.

  • The continuous deployment (CD) process involves a new workflow in the GitOps environment. Implement a fully automated deployment process and adjust the live environment to match the desired state specified in your Git repository. When the pipeline successfully merges code into the main branch, the GitOps agent immediately reconciles the live environment’s state with the new target state.

 

One way to separate the CI/CD process is to deploy an extra Git repo as an intermediary between the building and deployment processes. The Git repository includes environmental data, with each commit triggering a deployment process. This approach prevents the CI process from affecting underlying infrastructure such as Kubernetes clusters.

This separation also protects against misconfiguration and improves compliance with security standards. It ensures that all changes to the production environment have clear audit trails, with everything managed entirely via a central Git repository.

Avoid Cloud Drift

All changes to the cloud environment must be recorded in Infrastructure as Code (IaC) templates kept in the central Git repo. Each template must be in-sync with the cloud environment through immutable compute instances and coordination loops.

In an ideal GitOps implementation, the controller continuously syncs the IaC template’s desired state with the production resource’s actual state, updating resources whenever it detects a divergence. However, some organizations implement a partial GitOps model—not all computing resources are immutable, so removing or replacing them is not always possible. In this case, resource changes and maintenance often cause configuration drift in the cloud. Look out for cloud drift and monitor the configuration to allow developers to add changes to the IaC templates (or undo them) and ensure the audit trail includes them. 

Provide Actionable Feedback

GitOps helps developers work quickly, but only if they can respond immediately to feedback. When developers push updates too quickly without adequate oversight, the resulting friction can slow down the build or deployment. The team will often ignore noisy or complicated feedback. 

All feedback should be intuitive and actionable, keeping the developers in mind to ensure compliance with security practices and remediation guidelines. Security tools must prioritize alerts and provide clear instructions. Another option is to add IDE extensions that directly apply fixes to the code.

Use Container Firewalls

Most GitOps implementations use containers as a deployment mechanism. A traditional network firewall is not sufficient to protect a containerized environment. It cannot maintain visibility over east-west traffic in between or within hosts and cannot adapt to the frequent changes with containers constantly starting and terminating.

A container firewall provides a similar level of protection as a next-generation firewall (NGFW)—it secures all container traffic, including north-south, east-west, and inter-container traffic. Cloud native container firewalls can secure services, workloads, and application stacks, while containers start, scale, and stop. They also protect cluster ingress and egress traffic, similar to a traditional gateway firewall.

I hope these five best practices will be useful as you adopt GitOps while improving your organization’s security posture.

GitOpsMetasq

 

More Information

What Is GitOps

Related Articles

Secure Coding Best Practices for 2022

Insights Into Successful Software Delivery

Happy Developers Think More About Security

The State Of Secure Software Development - Three OpenSSF Courses

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.

 

Banner


AWS Adds Support For Llama2 And Mistral To SageMaker Canvas
12/03/2024

As part of its effort to enable its customers to use generative AI for tasks such as content generation and summarization, Amazon has added these state of the art LLMs to SageMaker Canvas.



GitHub Enterprise Server Adds Deployment Rollout Controls
11/03/2024

Version 3.12 of GitHub Enterprise Server, the self-hosted version of GitHub that organizations can install on their own servers, has been released with support for restricting deployment rollouts [ ... ]


More News

 

Last Updated ( Saturday, 17 December 2022 )