Extensions of DevOps: GitOps and SecOps

Continuous deployment of cloud-native apps has revolutionized team collaboration. Transparency and observability are the norms of successful teams that aim for a high level of automation at every level of development and deployment.

By offering a single source of truth for changes to infrastructure as well as changes to policies and rules, these extensions made possible by cloud architecture are enhancing current DevOps methods.

What is GitOps

A Git repository contains the entire system, including code, configuration, monitoring rules, dashboards, and a comprehensive audit trail. GitOps is an evolution of DevOps in which Git serves as a single source of truth for the entire system, allowing for rapid application development on cloud-native systems and Kubernetes in particular.

Weaveworks coined the term “GitOps” to describe DevOps best practices in the era of Kubernetes, with a strong emphasis on declarative infrastructure. GitOps’ fundamental theorem states that if a process can be described, it can be automated. And if it can be automated, it can be controlled and accelerated. The goal is to describe and version control everything, including policies, code, configuration, and monitoring. With GitOps, the state of your infrastructure should be reflected in your code.

GitOps borrows logic from DevOps:

  • All code must be subject to version control.
  • Configuration is equivalent to code.
  • Additionally, the configuration must be version-controlled.

The concept behind GitOps is openness. A declarative environment captures the state, allowing for straightforward comparisons between the observed and desired states. In fact, the system can be observed at all times. In summary, every service has two truth sources: the desired system state and the observed system state.

In the purest sense of GitOps, Git maintains a repository that describes your infrastructure and all of your Kubernetes configuration, and your local copy of code provides a complete repository for version control. When you push new code or configuration to Git, something on the other end listens for this push and makes the corresponding changes automatically. All changes occur in the same manner. The entirety of your infrastructure and configuration resides in a centralized repository, and every change is triggered by a commit and push to that repository.


How it works

Code is committed and pushed to GitHub, after which a CI/CD workflow listens on the other side, makes the necessary configuration changes, and commits them. Instead of engineers directly interacting with Kubernetes or the system configuration – for example, by using the Kubernetes command line interface (CLI) – they do everything through Git: writing configuration, pushing configuration and then applying those changes via the CI/CD workflow.

The three primary objectives of GitOps include:

  1. Pipelines: Construct fully automated C/CD pipelines, allowing Git to serve as a source of truth for the desired system state.
  2. Observability: Implement 24/7 monitoring, logging, and security observation and measurement of every service pull request in order to obtain a comprehensive view of the current system state.
  3. Control: Put everything under version control and create a repository containing a single source of truth for recovery purposes.

Weaveworks is observing an increase from a few deployments per week with Cl systems to 30 to 50 deployments per day with GitOps. In addition, DevOps teams are twice as fast at fixing bugs. Managing the state of code in Git as opposed to Kubernetes enables improved tracking and recovery. It also enables continuous experimentation on the Kubernetes architecture, such as A/B testing and customer feedback.

What is SecOps

Traditionally, security teams deliver security test results and vulnerability scans to operations teams for review and implementation. Traditionally, security teams hand over security test results and vulnerability scans to operations teams for review and implementation, typically during application deployment. As long as an application is operational and performing as expected, security’s participation in the process is deemed acceptable. However, information exchange and approval cycles can cause delays and slow a DevOps workflow that would otherwise be agile. It is not surprising that this occurs, given that the two teams have very different objectives. Operations attempt to make the system’s operation as simple and resilient as possible. In contrast, security seeks to control the environment—the fewer processes running, the better. In reality, these late-stage handoffs between operations and security are problematic for many reasons, not the least of which is that neither team shares its insights and expertise. Consequently, potential threats can develop into show-stoppers, and security-related issues frequently fester for longer than necessary.

When organizations lack a mechanism for communicating and transferring key security data on an ongoing basis, they are incapable of mitigating security risks, prioritizing and remediating security threats and vulnerabilities, and ultimately protecting the application environment. However, organizations do not need to compromise security in order to maintain uptime and performance. Hence, SecOps comes into play. Similar to how DevOps bridges the efforts of software developers and operations teams, SecOps bridges the efforts of security and operations teams. Similarly to how a DevOps approach enables product developers to deploy, manage, monitor, and secure their own applications, a SecOps approach provides engineers with visibility into both operations and security concerns. It is a shift from individual tacticians, such as system administrators and database administrators, to more strategic organizational roles. This provides organizations with a centralized view of vulnerabilities and remediation actions while automating and accelerating corrective actions. All configuration and infrastructure are stored in a central Git repository using a GitOps methodology. DevOps engineers compose development and deployment policies, whereas security engineers compose network and firewall security policies. And they are all stored in the same repository. Collaboration between these teams – DevOps and SecOps, or SecDevOps – raises the stakes by enhancing efficiency and visibility into what has occurred and what should occur in the future.

By replacing disconnected, reactive security efforts with a unified, proactive CI/CD-based security solution for both cloud and on-premises systems, SecOps gains a more cohesive team with diverse backgrounds working towards a common goal: frequent, rapid, zero-downtime, secure deployments. This objective enables both operations and security to analyze security events and data with the intent of reducing response times, optimizing security controls, and checking and correcting vulnerabilities at each stage of development and deployment. The blurring of the lines between the operations and security teams increases visibility into any required changes to development or deployment, as well as the potential consequences of those changes.

[Learn More: Disaster recovery via the DevOps approach]

Share the Article:

Share This

Share This

Share this post with your friends!