devopsy.kinsta.cloud

Category: GitOps

Why and How to Go All-In on GitOps
GitOps is like exercise: A little is good for you, but more is much better. Just as jogging a couple of miles every other week won’t hurt but also won’t dramatically improve your health, managing something like 30 or 40% of your processes using GitOps won’t supercharge your approach to IT operations. If you want to realize the full benefits, you must go all in.

I am not qualified to offer advice on establishing a healthy exercise regime. But I do know a thing or two about GitOps and how to make the most of it. To that end, here’s a look at why going all-in on GitOps can be challenging, how you can overcome the challenges and why doing so is worth the effort.

While you don’t strictly need GitOps to take advantage of API gateways, GitOps streamlines and scales the management of this key infrastructure in modern application architectures.

To ground the discussion, I’ll focus on a common use case for GitOps today: Using it to manage APIs in conjunction with an API gateway, which helps to deploy, observe and secure APIs.

GitOps: Defining the Basics

GitOps is the use of Git, the open-source version control system, as a single source of truth for managing infrastructure configurations. The goal behind GitOps is to replace manual configuration management with automated, code-driven workflows.

When you do this, you gain a variety of benefits, such as:
- A centralized source of truth — in the form of Git repositories — for infrastructure configuration
- The ability to manage infrastructure using declarative configurations and apply changes automatically and continuously to ensure the current state has not diverged from the declared state
- Simple and efficient collaboration, since everyone involved in configuring and managing infrastructure can operate from a centralized hub
- The ability to track changes to infrastructure configurations over time using Git’s built-in version control features
- Quick and easy rollbacks to an earlier configuration in the event you encounter a problem
- The ability to validate configurations using software agents, frequently known as linters.
For example, if you are operating an API gateway that you can manage using an infrastructure-as-code (IaC) approach, you can leverage GitOps to configure the gateway using code that you store in a Git repository. That makes it possible to scan and validate the code prior to applying the configuration. In addition, you can track changes to your configuration through Git, and everyone on your team can easily monitor and collaborate around management of the API gateway using Git as a centralized source of truth.

The State of GitOps Adoption

It is easy to talk about the benefits of GitOps. Adopting GitOps, however, can prove more challenging. Likely, more than 90% of organizations in a recent CNCF survey report that they are using GitOps to some extent, yet many have implemented it across just a fraction of their cloud-native deployments. Businesses are eager to adopt GitOps, but extending it across their IT environments is proving much more challenging.

That’s a shame because the value of GitOps increases exponentially when you implement it systematically and consistently across your organization. When you can manage every cloud native deployment using a GitOps approach, as a consequence, declarative and automated processes become baked into your culture and transform your business.

In contrast, a partial GitOps implementation might improve the efficiency of a few processes, but it won’t level up your overall operations. It will also leave you with inconsistent processes because some are managed via GitOps while others rely on manual techniques. And your teams will be caught in the middle, juggling disparate sets of tools — one set to enable GitOps and another designed for legacy operations.

This is why GitOps should ideally be an all-in affair. Implementing GitOps here and there is better than not using GitOps at all, but you won’t come close to realizing the full potential of GitOps until it is a consistent, systematic process that extends to all facets of your business and operations.

Overcoming GitOps Implementation Hurdles

But again, going all-in on GitOps is easier said than done. Here are the main challenges businesses encounter, along with strategies for working past them.

Workflow Changes

Perhaps the most obvious challenge to implementing GitOps is the need to evolve workflows from traditional, manual approaches to ones rooted in Git. You must ensure that all stakeholders know how to work with Git and are prepared to make it their go-to solution for managing configurations.

For example, if your goal is to manage an API gateway using GitOps, you need your engineers to be able to manage configurations for the gateway using code and to know how to manage that code in Git.

There is no magic bullet to solve this challenge overnight, but education is key. Organizations aiming for complete GitOps adoption should educate developers, IT engineers and anyone else who plays a role in configuration management in how Git works and how to use complementary platforms, such as GitHub or GitLab, which the business might use to store configuration code. In addition, education initiatives should explain why GitOps is so valuable, in order to achieve buy-in for full-scale GitOps adoption.

Finding GitOps-Friendly Tools

Because GitOps is a relatively new concept, not all tools work seamlessly with a GitOps-based approach to configuration management. Implementing GitOps is particularly hard in cases where you are working with tooling that has limited or no native support for declarative configuration management (meaning the ability to describe a desired state using code and enable it automatically). For instance, even if you use a platform like Kubernetes (which does support declarative configurations), you might pair that with a legacy API gateway within your stack that doesn’t natively support a GitOps approach because they are not designed to be managed using code and declarative configurations.

In some cases, you can work around this issue by installing add-ons or using additional tools to enable a declarative approach in environments that don’t otherwise support it. However, this solution requires a lot of effort to implement, and it also increases the complexity of your operations by adding more tools to the mix.

A better solution to this challenge is to migrate to tools that are designed to support declarative configuration management natively. Today, you can find GitOps-friendly tools for virtually every layer of a cloud-native deployment stack, so there is no reason to settle anymore for software that doesn’t offer full-fledged support for declarative configurations.

Managing Secrets

Managing secrets, such as keys that help secure traffic flowing through an API gateway, can be challenging when implementing GitOps, because you ideally do not want to store secrets in plain text within the same code that you use to manage configurations. If you do, anyone who can view your configuration code will also be able to access your systems and resources.

Fortunately, there are simple solutions to this issue. One is to use a secrets manager, which lets you store secrets outside your code repositories while still making them accessible for authentication requests. Another is to embed secrets in your configuration code but ensure they are encrypted to prevent unauthorized access. Either approach lets you connect secrets securely to a tool that you manage declaratively.

Managing Complexity

While GitOps simplifies and scales operations in some ways, it can also make processes more complex as it adds new types of resources (like code repositories) to workflows. This is one reason why teams sometimes feel tempted to stick with legacy API gateways that don’t support declarative configuration: Initially, such solutions can seem easier to manage as they don’t require learning a whole new workflow and additional tools. However, the organization eventually pays the price with a lack of speed and agility in the long run.

Best practices for keeping things manageable include consistently naming resources, maintaining consistent folder structures for Git code and using tools like kustomize to apply configurations consistently across disparate environments.

Linting configuration code (meaning automatically detecting formatting issues) and establishing systematic review processes can help, too.

Collaboration and Communication

To deliver maximum value, GitOps must be accompanied by cultural change within your organization. You can do this by actively encouraging teams to leverage GitOps as a means of streamlining collaboration and communication. Highlight as well how GitOps increases transparency and efficiency.

Over time, stakeholders tend to appreciate the value of GitOps organically. But you might have to kick-start the process to help shift your mindset and culture toward a GitOps-centric approach.

Disaster Recovery

GitOps simplifies disaster recovery in the sense that you can easily restore configurations based on Git code. When things go wrong — when, for example, a change to your API gateway configuration leads to a spike in latency — just revert the problematic change to the previous working state, and now you have time to investigate and identify the root cause.

To take advantage of this capability, however, you must integrate Git-based operations into disaster recovery and response plans. Most organizations that have disaster recovery strategies in place did not design those strategies with GitOps in mind. Therefore, you would need to update your playbooks and educate engineers to ensure they are prepared to make Git a key pillar of disaster recovery efforts. Reverting to a previous state must not be a fearful event but a confident exercise.

API Management

GitOps goes hand-in-hand with an API-first approach to workflows. API standards, such as the OpenAPI Specification (OAS), offer a consistent approach to defining and managing APIs across all stages of the API lifecycle. In this way, they bring more consistency and order to GitOps.

Monitoring and Observability

The ability to monitor and observe GitOps pipelines is crucial for getting ahead of issues that may disrupt GitOps workflows. For instance, if someone accidentally removes essential configuration code that your API gateway depends on, you would want to know quickly so that you can revert the change.

As with API management, open standards help here as well. In particular, OpenTelemetry, or OTel, makes it easy to collect metrics, traces and logs consistently from any application or tool.

GitOps for Legacy Systems

A final challenge you may encounter when implementing GitOps is finding your IT estate includes legacy systems that just can’t be updated to support a declarative approach.

The ideal solution, of course, is to update to modern systems that are fully GitOps-compliant. But if migration isn’t possible, there may still be ways to bring some of the benefits of GitOps to legacy environments. For instance, legacy monolithic apps that currently run directly on servers could be redeployed using containers and Kubernetes. They would still be monoliths, but you would be able to manage their deployment declaratively.

Conclusion: Going All-In on GitOps

Recognizing the value of GitOps is easy. Implementing GitOps systematically across a business can be much harder. But as I have explained above, it is feasible to conquer each of the main challenges that businesses typically encounter on their GitOps journeys. Don’t expect to go all-in on GitOps overnight but do expect that with the right planning and tools, transforming your organization through GitOps is well within reach.
July 16, 2024
GitLab Fixes Security Flaw That Lets Attackers Run Pipeline Jobs

GitLab is urging users to upgrade the latest versions of GitLab Community and Enterprise editions, which fix a critical security flaw that allow bad actors to run pipeline a pipeline as another user.

The widely used web-based Git repository this week released versions 17.1.2, 17.0.4 and 16.11.6, which included a range bug and security fixes in both editions. The other vulnerabilities were rated as medium or low in their severity levels, but one – tracked as CVE-2024-6385 – was given a CVSS rating of 9.6 out of 10.

The security flaw affects Community and Enterprise edition versions 15.8 prior to 16.11.6, 17.0 prior to 17.0.4, and 17.1 prior to 17.1.2. The vulnerability “allows an attacker to trigger a pipeline as another user under certain circumstances,” Rohit Shambhuni, staff application security engineer at GitLab, wrote in a security notice.

Shambhuni didn’t detail the circumstances needed to allow such an attack.

However, Contrast Security CISO David Lindner said this vulnerability is something administrators need to take notice of, and heed GitLab’s advice to upgrade immediately.

“This is REALLY bad, as it effectively turns off access controls for running pipelines, which is the lifeblood of moving software from development to production,” Lindner wrote in an email. “This vulnerability could allow unauthorized users to execute pipeline jobs as any other user, which in turn could enable attackers to run malicious code, access sensitive data and compromise software integrity.”

Ray Kelly, a Fellow at Synopsys Software Integrity Group, said that given the fast pace in the SecDevOps world, “any mention of a vulnerability in pipeline functionality can certainly make the hairs on your neck stand up. Once a pipeline is compromised, software can be altered with malware, backdoors, or used to steal private information from organizations.”

All of that is difficult to detect, with security scans typically run earlier in the software development lifecycle, Kelly said. With recent supply-chain breaches, organizations need to patch flaws immediately to keep bad actors from compromising their software. In addition, running security scans in the pipeline can help detect issues before they’re deployed.

A Foundation for CI/CD

GitLab pipelines are key parts of a developer’s autonomous continuous integration and continuous deployment (CI/CD) process, driving software development through its multiple steps, from building to test to deploying code. According to GitLab, “Pipelines are comprised of jobs, which define what will be done, such as compiling or testing code, as well as stages that spell out when to run the jobs. An example would be running tests after stages that compile the code.”

They’re important for many of GitLab’s 30 million users, which include such high-profile companies as Lockheed Martin and Boeing in the aerospace field, French multinational Thales, global management consulting service Booz Allen Hamilton and General Dynamics Information Technology, an IT service management firm.

The fix for the security flaw comes less than a month after GitLab released new versions for Community and Enterprise editions to fix a similar vulnerability, which is tracked as CVE-2024-5655 and also allows an attacker to run a pipeline as another user. That flaw also came with a CVSS severity rating of 9.6.

Code Repositories as Targets

The push to rapidly such security flaws is driven in part by the increasing focus cybercriminals are taking to target code repositories like GitLab, GitHub, Python Package Index (PyPI), npm and – in the ever-expanding generative AI space – Hugging Face.

Such repositories not only hold a lot of information, but they’re an avenue for bad actors in software supply-chain attacks, who try to insert unauthorized code into the CI/CD pipeline to have it included in applications that then reach downstream IT environments. This can have wide-ranging effects, as shown by the SolarWinds incident from 2020, when hackers deployed malicious code into the company’s Orion IT monitoring and management software.

“Code repositories have become a prime target for threat actors targeting credential theft and supply chain attacks,” according to a blog post in March by cybersecurity firm SentinelOne. “Git repositories can contain not only proprietary code but also sensitive credentials like API keys, passwords, and cryptographic keys.”

Researchers with cybersecurity firm Apiiro in a report in February wrote about a repo confusion attack that affected more than 100,000 GitHub repositories that played out “when unsuspecting developers use repositories that resemble known and trusted ones but are infected with malicious code.”

Pushing for Secure Development

CISA and other federal security and law enforcement agencies have been urging organizations and programmers to focus on security in every step of the development, a cornerstone of the White House’s Secure By Design initiative. It’s an effort aimed at not only creating more secure code but also shifting the responsibility for software security from customers to developers.

As part of the program, CISA and the FBI this week issued an alert pushing tech companies to eliminate command injection flaws in operating systems, which enable threat actors to remotely execute code on devices at the network edge.

“OS command injection vulnerabilities have long been preventable by clearly separating user input from the contents of a command,” the agencies wrote. “Despite this finding, OS command injection vulnerabilities … are still a prevalent class of vulnerability.”

July 12, 2024
Security, Automation and Developer Experience: The Top DevOps Trends of 2024

If you ask most folks to describe the top DevOps trends in 2024, you’ll likely hear buzzwords like AI or DevSecOps.

Those are certainly trendy topics. But based on my everyday work helping businesses plan and execute DevOps strategies, I’m noticing a different set of salient trends in DevOps. Although much is being said about how technologies like AI might impact DevOps, the biggest changes I’m seeing right now involve other types of solutions and techniques.

Here are what I view as the three most important current DevOps trends, along with a breakdown of how they may change DevOps tools and processes.

Policy-Based Management and IaC Drive DevOps Security Innovation

Security has always been a priority for DevOps practitioners. But right now, I’m seeing DevOps teams adopt new strategies to improve the security of the applications and environments they support.

One large-scale change is the greater use of cloud-based policy management to enforce security best practices in cloud environments. Teams configure cloud services and resources using the code-based configuration frameworks that cloud providers support, then scan the configurations to detect risks.

This approach makes it possible to enforce cloud governance consistently, centrally and automatically. Instead of simply writing governance policies and hoping that engineers remember to follow them when they configure cloud resources, businesses are building automated governance guardrails via policy-based management.

In a similar vein, more and more of the DevOps teams I work with are embracing static code analysis of infrastructure-as-code (IaC) templates as a means of detecting risks. As with policy-based management of cloud resources, an IaC-centric approach to infrastructure provisioning makes it possible to automate infrastructure management and identify security risks earlier in the development lifecycle.

Some teams use cloud policy and IaC code scanning to warn one another about security policy changes that might cause an application or service to break. They do this by inserting configuration changes into their code using “audit” mode if their configuration framework supports it, or by configuring IaC scanners to flag changes if an audit feature is not available. This allows engineers to detect whether a change might cause a problem for an existing deployment.

This is important because security and application teams operate separately in many organizations. When the two groups lack an efficient way to communicate about changes, they can disrupt each other’s operations – the “right hand/left hand” problem. Configuration scanning provides a systematic way to ensure that each group is on the same page when it comes time to introduce changes – and the “audit” mode approach provides a grace period that allows time to react before a change takes effect.

Doubling Down on DevOps Automation with GitOps

Another overarching trend currently reshaping DevOps is using GitOps to make DevOps automation more efficient and consistent.

GitOps is the use of Git (or a similar source control system) to manage automated DevOps workflows. It involves defining configurations using code and applying them through features like GitHub actions.

When you opt for GitOps, you move DevOps automation controls from individual workstations to centralized source control repositories. The result is the ability to track and manage all automated workflows via a central hub. Doing so increases efficiency and mitigates issues like different engineers working with different versions of the same automation frameworks on their personal desktops.

In addition, GitOps automatically generates records of what changed and how it changed, because every action is logged through the source control system. This isn’t exactly documentation in the traditional sense and means that GitOps comprehensively documents every change – which is beneficial because human engineers tend not to be so thorough when documenting their actions.

To be sure, GitOps is not without its challenges. Implementing GitOps effectively requires additional skills – namely, expertise with both IaC frameworks and source control systems – that not all DevOps engineers possess. I also notice a tendency on the part of some teams to set up GitOps pipelines but rely on manual approvals instead of automated actions to trigger changes. That approach largely undercuts the value of automating pipelines in the first place.

However, these are challenges that teams can solve through education and by fully leaning into GitOps. In addition, techniques like automated testing of GitOps configuration code can help to build teams’ confidence in automations and reduce reliance on manual approvals.

Going forward, expect to see more adoption of GitOps techniques among teams seeking to level up their approach to DevOps automation. Automating individual DevOps processes (such as software testing and deployment) won’t be enough; truly efficient organizations will turn to GitOps to automate their entire DevOps workflows, from end to end.

Investing in Developer Experience

Making software delivery processes more predictable and efficient is merely a step toward DevOps’s ultimate goal, which is to help developers become productive and satisfied with their jobs.

To that end, I’m noticing interest and investment in developer experience right now. This is playing out through two interrelated initiatives.

One initiative is platform engineering. It involves creating DevOps teams that specialize in certain functions, such as network management or security. Those teams are designated to support those functions throughout the organization. This approach reduces cognitive overhead for developers by freeing them from the need to handle types of work outside their main focus. In other words, instead of forcing developers to be DevOps generalists, platform engineering lets different teams focus on doing what they know and enjoy best – leading to greater productivity and higher levels of job satisfaction.

The other major developer experience trend currently playing out is developer self-service. This means developers can obtain the technical solutions they need on demand without a complicated procurement process. In most cases, organizations enable self-service by implementing internal development platforms (sometimes called internal developer portals) (IDPs) which host ready-made infrastructure resources and software environments that developers can deploy on a self-service basis.

There are risks inherent in these trends. They require specialized types of skills. When poorly implemented, platform engineering and IDP solutions can create more problems than they solve. However, when you ensure that your teams have the requisite expertise, and deploy a carefully planned IDP that gives developers access to the resources they need, you’re likely to see a significant reduction in friction within your organization and a boost in developer productivity and happiness.

Real-World Changes, Beyond the Hype Cycle

Admittedly, discussing DevOps trends centered on security, automation and developer experience may not be as exciting as debating whether AI will take away DevOps engineers’ jobs. But if you want to know what’s truly changing in the world of DevOps – as opposed to which conversations are most hype-worthy – these are the places to look.

Security, automation and developer experience are also among the domains of DevOps where there is a great deal of opportunity to innovate – and, indeed, where adopting new tools and techniques will be critical for organizations that don’t want to be left behind as DevOps evolves.

May 17, 2024
Best of 2023: ‘Scrum == Cancer’ ¦ Plus: Linux 6.5 Ships

As we close out 2023, we at devopsy.kinsta.cloud wanted to highlight the most popular articles of the year. Following is the latest in our series of the Best of 2023.

Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

This week: Scrum sucks, sources say; and here comes the Linux 6.5 kernel. (more…)

December 29, 2023
Microsoft kills Python 3.7 ¦ … and VBScript ¦ Exascaling ARM on Jupiter

Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

This week: VS Code drops support for Python 3.7, Windows drops VBScript, and Europe plans the fastest ARM supercomputer. (more…)

October 11, 2023
Google’s Shiny New AI Dev Environment — the ‘Experimental’ Project IDX

Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

This week: Google’s full-stack, browser based development environment in the cloud. It’s not just a Copilot clone, but aims to help you “get an app from zero to production.” (more…)

August 10, 2023
Declarative Compliance With Policy-as-Code and GitOps
In recent times, the quest for greater agility, faster releases, enhanced scalability, security and performance brought forth the advent of several automation tools, technologies and frameworks. Software development has evolved considerably over the years to mitigate these challenges.

Monoliths have been split into microservices for improved scalability, maintenance and faster releases. Since DevOps is adept at bridging the gap between development and operations teams, now these two teams can work together to improve productivity and speed up release cycles.

The Need for Compliance

One of the critical strategies for business success is to stay compliant since processes are always improving and evolving. Compliance ensures that your DevOps processes and practices are consistent and meet regulations or regulatory standards.

An organization with a compliance-driven DevOps culture can cut down on operational costs, improve efficiency and reduce risks considerably.

What is Declarative Compliance?

Declarative compliance is defined as the process of managing and enforcing compliance in which policies are defined using code, and the system’s desired state is declared rather than explicitly programmed. To enforce compliance policies, you don’t write scripts or programs; instead, you use a high-level language or configuration file.

Declarative Compliance provides several benefits:
- Increased efficiency
- Better managed compliance
- Minimized risk of human errors
- Enhanced security
- Faster deployment
- Better collaboration
With declarative compliance tools, the system’s state is defined as a set of policies, and the tool makes sure it matches the desired state. The tool will automatically fix anything out of compliance, bringing the system back into compliance if there’s a deviation.

Tools for Declarative Compliance

Some of the popular declarative compliance tools are:
- Open Policy Agent (OPA)
- Terraform
- Kubernetes Policy Controller
- Chef Compliance
- AWS Config
Declarative Compliance for Infrastructure and Application Deployment

Often, declarative compliance is used in infrastructure management and application deployment, where policies are written as code and enforced across multiple environments. In addition to managing compliance at scale, declarative compliance tools ensure that the system’s desired state stays consistent across multiple systems and applications over time.

With declarative compliance, organizations can manage compliance more efficiently, effectively and securely since they can define policies as code and enforce them automatically. In addition to reducing errors, downtime and security breaches, this approach enables organizations to stay compliant and maintain their system consistently.

Introduction to Policy-as-Code

A policy-as-code approach allows you to write programs that govern security, compliance and rules throughout your application’s life cycle. It entails defining and applying code to manage and automate policies. It shares the same ideas as infrastructure-as-code (IaC) and other DevOps practices like continuous integration and continuous delivery (CI/CD).

A policy enforces constraints and restrictions to prevent unauthorized access to resources such as databases, storage, services, etc. By codifying policies, you can enforce rules and constraints throughout the development life cycle to prevent non-conforming resources from being deployed by integrating these policies into the software development life cycle.

Figure 1: Policy-as-Code at work!

Why Policy-as-Code?

Typically, businesses have the required processes, tools and procedures to guarantee the deliverable’s quality. Performance, scalability, ease of use and accuracy are typical quantifiable quality metrics used to ascertain the quality.

You can examine the quality of your application using these metrics, but a manual procedure will take time and is prone to mistakes. A better alternative is to leverage policy-as-code.

The traditional policy enforcement processes have certain drawbacks. It is challenging to perceive that your policies would be entirely adhered to, i.e., they will not be broken. It is cumbersome to check against a list of policies manually.

Moreover, the traditional policy enforcement method cannot scale in today’s agile world, where organizations have been growing continuously with more and more employees, services and teams.

Here are the key benefits of policy-as-code at a glance:
- Faster and more efficient deployments
- Automated governance, approvals and policy enforcement
- More reliable and secure applications
- Centralized policy management
- Leverages version control
- Better visibility of policies
- Enhanced collaboration
How Does it Work?

Policy-as-code involves three key elements:
1. The policy itself, which contains the required code to model the decision-making process
2. The data and information about the environment, service or application
3. The query that is responsible for triggering the decision-making process
Here’s how policy-as-code works:
1. Policies are defined as code in a human-readable format
2. These policies are then translated into machine-readable code using Rego or HCL
3. The policies are integrated with the IaC pipeline
4. A policy engine evaluates the infrastructure and the application resources against these policies
5. The policy engine accepts the policies as input, processes them and then produces a query result
6. The policy engine reports violations (if any) to the respective stakeholders, such as the development or security teams
7. If violations are reported, the necessary remediation is performed automatically or manually
Types of Policies
- Security policies: Security is enforcing adequate technological controls to safeguard company assets.
- Compliance policies: Compliance policies are designed to help organizations adhere to governance standards. Typical examples include PCI DSS, GDPR, HIPPA, etc.
- Operational excellence: This encompasses policies pertaining to service degradation or interruption.
What is GitOps? How can GitOps Help With Compliance?

GitOps is a subset or extension of DevOps encompassing a collection of practices that can simplify deployments using Git. It is an operating model for cloud-native applications that leverages Git as a single source of truth for declarative applications and infrastructure. Using GitOps, you can implement a standardized policy-as-code approach across your CI/CD and GitOps pipelines.

The key principles of GitOps are:
- The state of the system is captured and stored in a Git repository
- The entire system is configured declaratively
- Automated deployment
You can create policies in Git and store them in a particular repository, which is essential since Git offers sophisticated change management tools like version control. Only the compliance team would have admin access to the repository.

It’s easy to enforce policies with Git, and you can apply them to any execution engine, like CI or CD. With GitOps, you can audit and document every action that affects data consumption.

You can expose system changes, optimize deployment and use a version-controlled infrastructure. By managing compliance with GitOps, you can make sure that the changes are visible, verifiable and auditable.

Figure 2: GitOps at work!

Using GitOps as the Execution Engine in a GitOps Process

There are several benefits to using GitOps as a process execution engine, including:
- Increased automation: GitOps automates software delivery, reducing manual intervention and increasing deployment accuracy and speed.
- Better transparency: GitOps records all changes to the system in a transparent and auditable way so that you can track compliance easily.
- Maintaining consistency: GitOps keeps the system in the desired state defined in the Git repository, reducing non-compliance risk.
- Fosters collaboration: All changes to the system are made through the Git repository, so GitOps encourages collaboration across teams.
Using Policy-as-Code and GitOps: Policy-Based Compliance

By using GitOps and policy-as-code, teams can manage compliance-as-code in an auditable, declarative way and enforce it via GitOps, ensuring that the desired state is always maintained. This can help your teams to codify compliance requirements as code, store them in version control and automatically enforce them through GitOps.

Organizations can improve the consistency and reliability of their systems by defining and enforcing compliance requirements using policy-as-code and managing their deployment processes with GitOps. While this can minimize compliance violations, it can also maximize efficiency.

By following policy-based compliance declaratively, businesses can define policies as code and enforce them automatically and repeatedly. By adopting such an approach to compliance management, you can better manage compliance in complex systems in a consistent, scalable, agile, transparent and collaborative manner.

For example, you can leverage policy-as-code to define policies for infrastructure provisioning and configuration management to ensure that the infrastructure complies with organizational policies and industry standards. Typical examples are defining policies for network configuration, access control and resource allocation.

Use Cases: Using Policy-as-Code and GitOps in a Production Environment

Infrastructure Provisioning

Open Policy Agent (OPA) can define policies for infrastructure resources like AWS Elastic Compute Cloud (EC2) servers. You can use GitOps to manage the deployment of infrastructure resources by storing IaC files in a Git directory. When the IaC files are changed, GitOps is adept at automatically deploying the changes while OPA checks for policy compliance.

Deployment

You can use policy-as-code tools such as OPA to create application deployment policies requiring specific security settings, while GitOps manages the application deployment by storing manifests.

Manage Kubernetes Clusters

You can leverage policy-as-code to better manage your Kubernetes clusters. So, you can write your code to define policies to manage Kubernetes resources, such as nodes, pods, clusters, etc., declaratively.

Compliance Management

You can use policy-as-code to establish and implement rules and regulations, such as those pertaining to security, to help businesses ensure that their systems comply with industry regulations and standards.

OPA can be used to set compliance policies, like restricting access to sensitive data to authorized users only. You can use GitOps to manage the deployment of compliance policies seamlessly.

Trusted Delivery: Policy-as-Code Integrated With GitOps Workflows

Trusted application delivery is a software delivery approach emphasizing security and trust in the software supply chain. This ensures that any software delivered to the clients is devoid of security flaws, malicious code and other attacks.

This approach prioritizes security and trust at the development, testing, packaging and deployment stages and integrates security and compliance checks into the GitOps pipelines. This quality check reassures clients about the product’s quality and ensures that any modifications adhere to predetermined rules and principles.

Trusted application delivery allows for quick deployment while securing apps with automated guardrails. These guardrails are implemented using policy-as-code. By enforcing these guardrails, you encourage frequent deployments while ensuring that the reliability and security of the application are not compromised.

Conclusion

Declarative compliance with policy-as-code and GitOps is a best practice for achieving greater compliance, reliability and agility in software development and deployment processes. You can simplify defining and enforcing compliance policies using declarative configuration files and automation tools. Using Git as the single source of truth for all configuration changes, an organization can achieve greater efficiency, visibility and auditability in the compliance process.
April 6, 2023
OpenAI Hires 1,000 Low Wage Coders to Retrain Copilot ¦ Netflix Blocks Password Sharing

Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

This week: ChatGPT darling OpenAI wants people to write code in English, and the unintended consequences of blocking shared accounts. (more…)

February 2, 2023
Microsoft Outage Outrage: Was it BGP or DNS?

Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

This week: All of Microsoft’s cloud services go down, everywhere except China. Redmond’s IaaS, PaaS and SaaS—including GitHub—were dead for several hours, and are still running unreliably—despite Microsoft saying it’s fixed the problem. (more…)

January 25, 2023
The Secret to Secrets Management: Reduce Source Code Vulnerabilities

We are in the cyberattack age. From Microsoft to Crypto.com, no company is completely safe from malicious attackers, and it seems as if a new major cyberattack is announced weekly, if not more frequently. As more companies not only go digital but expand their digital offerings and initiatives, there are more opportunities for cyberattackers. Security teams within IT organizations are hard at work to ensure that their company isn’t next in the headlines. However, as the tech world moves to everything-as-a-service (IaaS, PaaS, SaaS, etc.), the move toward everything-as-code is happening in tandem. As a result, many developers are unknowingly keeping sensitive data (secrets, passwords, certs, keys, etc.) stored in Git source code repositories. This information is often pushed to production which puts sensitive information at greater risk of exposure.

The good news is there is a way to ensure that secrets are locked tight within source code. Let’s explore the complexity and realities of securing source code today and how to take the guesswork out of finding at-risk code that could land your company on the front page of the news tomorrow.

Secrets Management is Challenging and Costly

Sophisticated cyberattackers will stop at nothing to breach valuable data assets. Secrets leaked from source code make it easy for threat actors to access applications using the same credentials intended for legitimate purposes.

At the pace of continuous software development, developers must move quickly to build applications. However, security teams that are expected to prevent breaches are not often well-versed in all facets of the software development life cycle (SDLC). This becomes an issue as the number of lines of code (and the secrets kept within) rise alongside the number of apps developed. According to a recent report from 1Password, “two in three (65%) IT and DevOps employees estimated their company has more than 500 secrets.” And, according to the same report, “the average cost of a secret’s leak is $1.2 million. Poor secrets management can result in organizations losing $8.5 billion annually.” Secrets are vital to building any connected application or process. If hard-coded or left unprotected in source code, the proverbial keys to the kingdom are at risk of exposure—as are your loyal customers.

It’s clear that source code security should be a priority for security teams and DevSecOps professionals. Let’s examine how they can achieve this without sacrificing developer productivity.

How to Reduce Threats Through Secrets Management Best Practices

Manually searching source code repositories for vulnerable secrets can be almost impossible. However, there are some best practices to follow to ensure vulnerabilities are caught early and often:

● Identify and remove secrets in code: You can’t protect what you can’t see. It’s important to have visibility into source code to be able to see where vulnerabilities may exist. There are a few ways of potentially going about shining a light on vulnerabilities. One is through manual scanning of source code, but this takes away valuable time developers could be spending on more innovative tasks. There are also some open source solutions that can help with scanning source code repositories, but as with everything open source, this means developers will have to maintain it (keep it up to date, integrate it, etc.). Instead, security teams should consider looking for a unified toolchain platform to help with source code vulnerability identification and remediation.
● Alert and remediate in code repositories: Provide a fast feedback loop to a developer or DevOps engineer before releasing code into production. Remediation should happen at the time of commit. The idea here is to block secrets from being committed to your source code repositories in the first place.
● Adopt a secrets management tool: Don’t store secrets or binaries within source code—nothing but code should be in your source code repositories. Remove secrets to a secrets manager (i.e. HashiCorp Vault), keys and certificates manager (i.e. Azure Key Vault), etc. Modularize and isolate these managers, but make sure they still communicate with each other so that they don’t expose secrets.

As cyberattacks continue to increase, it is imperative that security teams take a hard look at their source code to ensure that it is locked up tight. Keeping secrets out of source code entirely is recommended in theory but difficult to ensure in practice. Following the above best practices will help reduce the risk of exposure of sensitive data and reduce the risk of losing loyal customers and revenue dollars.

August 30, 2022