devopsy.kinsta.cloud

Tag: Open Policy Agent

HashiCorp Introduces tfpolicy, a Native Policy Framework for Terraform
HashiCorp has introduced Terraform policy (tfpolicy), a new policy-as-code framework built directly into Terraform. Now available in public beta on HCP Terraform, tfpolicy lets platform teams write governance rules in HCL, the same language they already use to define infrastructure, rather than reaching for a separate policy tool and a separate syntax.

The launch addresses a problem that’s grown alongside Terraform itself. As infrastructure estates expand across hybrid cloud environments, platform teams are managing systems spanning public cloud providers, SaaS platforms, on-premises infrastructure, and internal platforms, often with multiple teams contributing changes via Terraform. That sprawl has pushed teams toward multiple tools and disconnected policy workflows just to maintain consistent governance.

Why the Old Model is Straining

Policy as code isn’t new. HashiCorp’s own Sentinel and the open-source Open Policy Agent (OPA) have handled this job for years, enabling organizations to codify compliance requirements and automate security checks. Both work by treating policy as a separate evaluation layer that sits atop an infrastructure plan, either passing or blocking it.

That separation was useful when it was introduced, but it comes with a tradeoff. A 2025 academic review of policy enforcement in Terraform workflows noted that Sentinel is deeply integrated into the Terraform Enterprise ecosystem and offers fine-grained, context-aware policy controls. In contrast, OPA is a general-purpose engine that connects to Terraform via separate tooling such as Conftest and custom CI/CD pipelines. Either path means learning a second language and maintaining a second toolchain alongside the Terraform code itself.

Industry analysis of policy rollouts points to a related issue: policies embedded directly in Terraform files are difficult to manage consistently across many modules and teams, and policy logic often blurs with infrastructure code, violating the separation of concerns. Teams end up choosing between a bolted-on external engine or scattered inline checks, and neither option fully closes the gap.

What tfpolicy Changes

HashiCorp built tfpolicy directly on Terraform and its provider ecosystem, so policies can evaluate infrastructure across any provider Terraform already supports, without a separate policy language to learn or a separate system to operate. That’s the core pitch: one language, one workflow, less context-switching.

The more interesting part is what tfpolicy can evaluate that older frameworks generally can’t:
- Resource relationships. Instead of checking resources one at a time, tfpolicy can look at how they connect. HashiCorp’s example: requiring every IAM role to have at least one policy attached, a rule that only makes sense when you can see the relationship between two resources at once.
- Data source lookups. Policies can pull in external context at evaluation time, such as checking that an EC2 instance uses only AMIs from an approved inventory, rather than relying on values hardcoded into the policy itself.
- Provider and module download controls. tfpolicy can block unapproved providers or modules before they’re used in a workflow, a step toward treating the software supply chain, not just the deployed infrastructure, as part of governance.
- Post-deployment evaluation. Not every issue shows up in a plan. tfpolicy can check policies against the infrastructure after it’s provisioned, catching issues such as provider-generated ARNs or identifiers that only exist once a resource is live.
That last point matters more than it might sound. Most policy engines are gatekeepers: they run before an application and either let it through or don’t. tfpolicy extends governance into the infrastructure’s actual lifecycle, checking the real state rather than only the planned state.

Where This Fits

tfpolicy isn’t replacing Sentinel or OPA outright; HashiCorp still supports both. But for teams already standardized on Terraform, it removes a real barrier to adoption: the need for a second team or a second skill set just to write policy. HashiCorp is also positioning it as approachable for AI-assisted workflows, releasing an agent skill for writing and testing tfpolicy files and converting existing Sentinel policies.

Mitch Ashley, VP and practice lead for software lifecycle engineering and AI-native software engineering at The Futurum Group, sees this as more than a convenience play. “Embedding policy evaluation into Terraform’s provider ecosystem, including checks against live infrastructure after provisioning, shifts policy from a pre-apply gate to a continuous property of the deployment lifecycle,” Ashley said. “Resource-relationship and data-aware checks let governance reason about connected, live systems instead of static plans alone.”

That shift raises a real question for platform teams already running a separate policy engine. “Platform teams on Terraform now have to weigh whether a bolted-on policy engine still earns its complexity once native, lifecycle-aware checks live in the same toolchain,” Ashley said. “Competing governance tools will need to match that depth or become redundant overhead.”

The bigger trend here isn’t really about Terraform. It’s about governance moving closer to the tools people already use, instead of living in a separate system they have to context-switch into. Academic researchers studying policy-as-code adoption have flagged the steep learning curve of dedicated policy languages as a real barrier to consistent enforcement — folding governance into HCL is a direct answer to that friction.

tfpolicy is now available in public beta via HCP Terraform. Documentation and getting-started guidance are available through HashiCorp’s developer portal.
July 20, 2026
What is OPA (Open Policy Agent)?

Open Polic y A g ent (OPA) is a versatile policy engine designed to handle policy enforcement across cloud infrastructures. It enables users to define and apply policies consistently across a variety of systems, helping maintain security and compliance in dynamic environments.

In my view, OPA represents a significant step forward for cloud infrastructure. From experience, unless a specialized solution is in place, a well-executed OPA implementation can greatly strengthen enterprise software.

Using OPA involves submitting requests as JSON or YAML objects. The engine evaluates these requests against its defined policies and data, producing a determination—essentially a decision of approve or deny. It is then the responsibility of your application to act on this decision.

Decoupling Policy Logic From Business Logic

A key advantage of using OPA is its ability to decouple policy decisions from the business logic in your services. With OPA, the engine determines the outcome of a policy, while your application takes responsibility for enforcing it. This separation makes it possible to manage all policies in a single location, instead of having to update business logic across multiple systems—systems that may be written in different languages and maintained by different teams.

What is Rego?

Rego g o is the specialized language used by OPA to define policies. It is a declarative language built for inspecting and manipulating structured data, such as JSON and YAML, which are commonly used to express access rules in cloud environments.

Inspired by Datalog g, Rego extends its capabilities to handle structured document formats like JSON and YAML. While some developers find it challenging to learn, it remains the primary language for OPA users.

How Do You Create an OPA Policy?

Creating an authorization policy in OPA begins with loading your authorization data in a structured format, such as JSON. Next, you write policy rules in Rego to transform this data and establish the authorization context. For example, this might involve identifying a userʼs role or determining which organization owns a particular file. Once the data is properly structured, OPA evaluates it to decide whether a request should be allowed or denied.

How Would You Design RBAC Using OPA?

RBAC, or Role-Based Access Control, is a framework that uses roles to manage user access to resources. The concept of roles is widely understood, and users often expect them as a standard part of any authorization system. For many application developers, defining roles is the quickest and simplest way to start implementing authorization.

To build a role-based access control (RBAC) system using OPA, the first step is assigning roles to your users. This can be represented using a dictionary. For instance, in our example, we have two roles: admin and member. Alice holds both roles, while Bob is only a member.

Next, we define the permissions associated with each role. In this scenario, members can only “readˮ the Acme repository, whereas admins can “writeˮ and “deleteˮ it.

With roles and permissions established, we implement logic to check whether a user can perform a specific action. For any given user, we first determine their assigned roles. Then, we aggregate the permissions across all of their roles to see what actions they are allowed to take.

In this simple example, the policy clearly defines the permissions each user has. With this policy in place, OPA can evaluate whether a user is authorized to perform a requested action.

What Does OPA Do Well?

OPA excels as a general-purpose policy engine. It can ingest data from multiple systems in their native formats, making it highly adaptable. Using its rules language, Rego, you can inspect and transform this data as needed to make authorization decisions. This focus on interoperability makes OPA especially effective when working with third-party systems where you donʼt control the data. Additionally, OPA is well-suited for machine-to-machine operations.

What Are Open Policy Agent Alternatives?

Recently, OPA has hit some community skepticism with OPAʼs main developers being hired by Apple as part of an acquisition of OPAʼs corporate sponsor, Styra.

While OPA will remain open-source, the sunsetting of Styraʼs commercial products has pushed some developers to look for alternatives. One alternative is a platform like Oso. There are, however, some key differences between OPA and Oso (despite the similar name).

Engineering teams are increasingly adopting managed services for core infrastructure, and authorization is no exception. As a result, a growing number of authorization-as-a-service options have emerged alongside self-managed approaches. In this landscape, OPA remains a widely used general-purpose policy engine, implementing authorization as low-level operations on structured data.

February 3, 2026
GitOps in the Wild: Scaling Continuous Delivery in Hybrid Cloud Environments

Over the last 10 years, software delivery has undergone a significant transformation. Continuous integration and continuous delivery (CI/CD) procedures, in conjunction with infrastructure as code (IaC), have become the backbone of modern DevOps pipelines. Yet, as organizations grow into hybrid and multi-cloud environments, these approaches are often unable to keep up with the complexity of distributed systems, regulatory constraints and team autonomy. This is where GitOps has come into the spotlight as a powerful paradigm for managing infrastructure and applications. At its core, GitOps is an extension of DevOps principles, which treats Git not only as a code repository but as the single source of truth for declarative system states. With automated reconciliation between desired and actual states, GitOps promises consistency, auditability and speed in environments where drift and misconfiguration are constant risks. It allows developers to deploy confidently while providing operations teams with better guardrails and observability. While some early adoption has shown promising results, adopting GitOps on a broader scale ‘in the wild’ has brought up new challenges. Running GitOps at enterprise scale — across multiple teams, regions and cloud providers — requires more than just tools like ArgoCD or Flux. It requires a delicate balance in architecture, governance, security and cultural change. This post examines how organizations can go beyond proof-of-concept approaches to successfully scale GitOps in hybrid cloud environments. Based on real-world practices and emerging patterns, we’ll investigate the opportunities, pitfalls and strategies for achieving continuous delivery at scale — where Git is no longer a version control system, but the backbone of reliable, compliant and resilient software operations.

What is GitOps Really?

GitOps is also called IaC with Git, but in reality, it is much more. GitOps is based on applying software engineering principles, e.g., version control, code review and automated testing, to infrastructure and operations. Rather than operating configurations using imperative scripts or ad hoc commands, companies store the desired system state (applications, infrastructure, policies) in Git repositories. Based on them, specialized GitOps controllers, such as ArgoCD or Flux, can continuously bring the realized environment in line with the specified state. When a deployment drifts or fails, the controller attempts to bring it back to compliance automatically, which makes Git the source of truth in its entirety for both infrastructure and workloads. This model minimizes human error and provides a clean audit trail, rollbacks and reproducibility, which are essential in current compliance and rapid-movement environments.

The difference between GitOps and traditional CI/CD is the control location and the manner in which the delivery occurs. Under standard pipelines, CI/CD tools inject changes into environments, which may need high permissions, service accounts or manual involvement. GitOps inverts this approach — environments invert the state they want out of Git — and the deployment is consistent, verifiable and not tied to sappy external pipelines. This change is insidious but potent — it dissociates the delivery mechanism itself with tooling in the center and puts operational intelligence in its own right. To developers, GitOps implies a standard process of commanding, examining and unifying, which results in automatic deployment. It offers operators more powerful guardrails and a single mechanism to operate distributed systems in Kubernetes clusters, hybrid clouds or edge environments.

The Case for GitOps in Hybrid Cloud

The hybrid cloud has become a new reality for many enterprises, intentionally or accidentally. Regulatory compliance usually restricts sensitive workloads from staying on-premises, whereas cost savings and scalability cause other workloads to be transmitted to public clouds. Moreover, acquisitions, regional data residency legislations and changed business demands combine piecemeal IT environments across more than two providers and platforms. It is widely known that managing application delivery is difficult in such environments — teams must align multiple deployment models, security policies and operational practices and ensure that systems are compliant and resilient. Single-environment, traditional CI/CD pipelines are effective when confined to single environments — but fail when they are extended to heterogeneous infrastructures where multiple governance requirements conflict.

Here’s how GitOps offers an attractive benefit. When Git is used as the sole source of truth, and declarative definitions are used to define infrastructure and applications, GitOps generates a consistent operational pattern that is platform-independent. Regardless of whether a workload is running on either AWS, Azure or Google Cloud, or on bare metal, the workflow of deploying and managing it appears the same: Update the Git repository and have GitOps controllers reconcile the changes. Such consistency not only lowers teams’ learning curve but also minimizes the risk of misconfiguration in the environment, where the differences between platforms are a frequent source of outages. For organizations with a hybrid or multi-cloud strategy, GitOps guarantees that governance, security and compliance policies can be coded centrally and applied uniformly across distributed environments.

In addition to consistency, GitOps also comes with the critical basics of resilience and auditability, which are crucial in a hybrid cloud. Drift detection ensures that the environments are continuously audited to their specified state and are immediately visible when configurations change manually, when there is trouble or during security events. The rollback is simple — a Git revert puts the system back in an understandable condition, no matter what cloud or cluster the workload is hosted on. In any industry where audit and compliance reporting are standard, Git history offers a record of all changes in operations that can be verified and have a time stamp. Such traceability is hard to provide with ad hoc pipelines but naturally appears with the use of Git as the backbone operational framework. In hybrid cloud environments, where the risk is more on the surface, GitOps provides efficiency and promises governance, compliance and trust.

Challenges of Scaling GitOps

Although the benefits of GitOps are evident, it does not take much time to realize the complexities of extensive team-based or pilot project-based scaling. Operation design at scale is one of the initial challenges. Organizations are faced with the question of whether to implement monorepos that allow better visibility but introduce bottlenecks, or multi-repos that introduce additional governance overhead and enhance team autonomy. Access control between or among repositories, clusters and teams cannot be managed efficiently, and this is especially significant in controlled industries. GitOps comes with new dependencies, too: Availabilities in Git, branch-protection regulations and pull-request processes directly impact deployment pipelines. This can make developers frantic without proper planning and slow delivery timing. Besides, there is still an unequal maturity of tools. However, applications such as ArgoCD and Flux are potent; with the possibility of multi-cloud failure, policy practices and centralized observability are being developed. This burdens businesses with building so-called custom solutions, adding to their existing workload.

The GitOps scale issues connected with security and culture are equally important. To transfer the deployments into Git workflows, developers, operators and security teams must work together differently. Developers must get comfortable with infrastructure-as-code and Git-driven release procedures, and operators need to have faith in automated reconciliation instead of human intervention. Resistance tends to arise in cases where roles and responsibilities are not decoded. Security is another crucial issue: Since control is centralized in Git, repositories and access tokens become a valuable target. Their protection needs robust role-based access control (RBAC) policies, secret management systems (e.g., Vault or Sealed Secrets) and techniques such as signed commits and image verification. Simultaneously, the fact that the concept of GitOps implies that everything is constantly reconciled might increase the number of mistakes if a wrong configuration is fused, making Git the single point of failure. These dangers stand out in particular. In contrast, GitOps offers an effective delivery platform; to expand it to a hybrid cloud, one must use tools and invest in governance, culture and security.

Strategies for Success

Simple tool adoption is not enough to successfully scale GitOps in hybrid cloud environments; it involves considerate architectural designs that balance autonomy and control. The hub-and-spoke model is a time-tested model, characterized by the fact that a central repository (the so-called hub) controls global configurations, policies and security standards. Still, individual teams use application-specific repositories (the so-called spokes). The model enables organizations to implement minimum guardrails, including cluster networking policies, rules or compliance requirements and allows teams to run their delivery workflows. Another good course of action is to divide GitOps into infrastructure and application. Having separate repositories and pipelines between foundational infrastructure (clusters, networking, storage) and application deployments helps organizations increase complexity and eliminate accidental cross-impact between infrastructure and application changes.

Figure 1. Hub-and-Spoke Design

As evident in Figure 1, in the hub-and-spoke design, the hub is the central control plane for connectivity, security and governance and the spokes host distributed workloads. Communication runs through the hub for easy management and compliance. Applied to GitOps, the hub is the central Git repository alongside GitOps controllers (such as ArgoCD and Flux) serving as the single source of truth. Spokes are dispense environments — clusters, clouds or edges — that reconcile the state with the hub. This way, consistent deployments, centralized policy enforcement and observability can be achieved, while each spoke can be operated autonomously. This makes it easier to scale GitOps across multiple hybrid and multi-cloud environments.

Repository design is also another crucial aspect. Monorepos provide clients with a single perspective for all environments, which is easy to audit and see. Still, they can rapidly grow in complexity, using dozens of teams and thousands of services. Multi-repo approaches, on the other hand, give more distinct boundaries and ownership at the cost of being fragmented in the absence of strong governance. Different companies use a mix of the two: Monorepos on infrastructure components, which must be global, and multi-repos on application teams, which appreciate autonomy. Regardless of the organization structure, there should be defined branching strategies, pull-request templates and an approval workflow that is in line with the compliance requirements. Another essential part is drift detection, which includes automated notifications and dashboards tracking configuration drift across clusters, helping teams identify issues early and minimize mean time to recovery (MTTR).

Governance and policy-as-code are needed to scale GitOps. Policies and their usage, security and compliance can be codified with tools such as Open Policy Agent (OPA) using either Gatekeeper or Kyverno. These policies are pre-flight checks so that only the compliant manifests reach production clusters. Policy checks allow governance to be set up as an automated, repeatable process, not a manual bottleneck embedded in GitOps workflows. Policy-as-code can offer a malleable way to apply localized rules without breaking international norms in hybrid environments where regulatory specifications exist in each region. Moreover, organizations can add cost-consciousness to policies, which can ensure that scaling decisions do not go against FinOps practices.

Another requisite for success is observability. GitOps pipelines reveal metrics of interest to developers as well as the site reliability engineering (SRE) and compliance groups. Primary indicators comprise the frequency of reconciliations, drift events, failed deployments and rollback numbers. Working with GitOps controllers, Prometheus (as illustrated in Figure 2) and OpenTelemetry enables teams to gain real-time visibility into the status of delivery processes. Dashboards can represent deployment pace, error budgets and commercial conformity in various clusters and clouds. This is essential in hybrid cloud usage where operation blinds are prevalent. In combination with alerting systems, observability ensures that issues are addressed and that the problem does not turn into a wave of outages.

Fig 2. Prometheus Monitoring Architecture

The diagram shows the Prometheus monitoring architecture, one of the core tools often used with GitOps and OpenTelemetry for observability. Prometheus servers gather metrics from exporters or jobs by scraping them directly or using the Pushgateway for short-lived jobs. The data flows into Prometheus’s time series database (TSDB), which is made available via an HTTP server. Service discovery (e.g., Kubernetes) is a mechanism for dynamically identifying monitoring targets. Metrics can then be queried via PromQL, visualized in Grafana or the Prometheus web UI and exported through APIs. Alerts are routed through Alertmanager to tools such as PagerDuty or email to provide real-time insights into deployments, reliability and compliance across hybrid clouds.

Security hardening should not be disregarded. By putting control of operations in Git into one point of trust- and accordingly, a potential point of failure. Enterprises should apply intense RBAC rules in Git files and clusters, and keep confidences encrypted and under the security of HashiCorp Vault, Sealed Secrets or SOPS. They should incorporate cryptography in committing and containerizing image signatures using solutions such as Sigstore or Cosign. These practices block attacks and unauthorized modifications in supply chains. More importantly, teams must incorporate safe defaults into GitOps processes, like the need to approve any production change more than once, so that automation increases security, as opposed to avoiding it.

Scaling GitOps is also more of a cultural process than a technological one. Code developers, engineers and security developers need to adapt to the new deployment model triggered by Git commits and not by manual processes or one-off scripts. This change demands an investment in training and onboarding, along with a blameless culture that promotes experimentation and learning from failures. GitOps processes that fail must undergo regular postmortems by the teams to improve systemic aspects instead of promoting blame. In the long run, it becomes a way of developing trust in the model, boosting adoption and giving developers the ability to take ownership of the delivery without compromising governance and reliability for the operators.

When combined, these strategies bring a key reality out to the fore — that GitOps at scale is not a kind of silver bullet — but a disciplined set of techniques encompassing architecture, governance, observability, security and culture. By exploring GitOps, organizations can realize the value of continuous delivery in hybrid cloud contexts, and not only enhance consistency and efficiency, but also resiliency and compliance on an enterprise scale.

Case Study: GitOps at Scale

To demonstrate how GitOps may be used in a real-world hybrid cloud setup, we will consider the case of FinServe Global. This fictitious financial services company operates in North America and Europe but represents a real-world organization. Like several regulated businesses, FinServe had to contend with two dimensions: Updating its delivery pipelines and complying with rigid compliance and data residency standards. To address regulatory requirements, the company had a significant physical presence in regional data centers, and at the same time used AWS and Azure to scale and innovate. Fragile deployment practices had increasingly become a substantial barrier by 2021; a subset of teams was using Jenkins pipelines as custom, while others were using Ansible scripts and some were deploying using their fingers. This inconsistency hindered the speed of delivery and generated audit headaches and operational risk.

The breaking point was reached because a compliance audit revealed inconsistencies between the data center environment configuration and cloud deployments. FinServe retaliated by piloting a GitOps platform (with ArgoCD to deliver applications and Flux to manage infrastructure) before their platform engineering team. A hub-and-spoke repository pattern was developed: A cluster repository characterized by global networking, security and compliance criteria, and each product group had its own repository of application manifests. Open Policy Agent was used to implement policies for enforcing resource limits, encryption standards and network rules and meeting regulatory requirements. Secrets were founded on HashiCorp Vault and watched directly on GitOps. This isolation of concerns enabled platform engineers to provide guardrails while developers deployed applications.

Observability was an expensive investment in successfully implementing GitOps. The team combined ArgoCD and Flux with Prometheus and Grafana, allowing for the development of dashboards that monitored all clusters’ reconciliation statuses, drift detection and deployment success rates. These dashboards were also gradually made essential for monitoring operations and proving compliance at audits. As an example, the auditors could access specific Git commits related to any change in production and time-stamped approval records. Such transparency reduces the manual work needed in preparation for clearing regulatory reviews.

Cultural change is also equally important. The new workflow was initially unwelcome among developers who saw GitOps as an extra burden to their existing CI/CD. To facilitate the change, the platform team launched developer enablement classes and designed templates, which streamlined the deployment practices without compromising flexibility. Early victories (e.g., shorter rollback) and fewer on-call incidents contributed to confidence-building. During the 12 months, pilot teams implementing GitOps increased to more than 40 product teams with more than 500 microservices in their hybrid context.

The results were tangible. Deployment frequency also improved by 35% and the MTTR was reduced by about 50%. Most importantly, audit preparation took less than a week, and was reduced to a few days, courtesy of the version history of Git and the policy enforcement mechanism coming into play. FinServe also stated that configuration-related incidents declined as drifts were easily identified before entering production.

FinServe’s experience highlights that GitOps is not merely an upgrade in tooling but an organizational change. By integrating architectural discipline, policy-as-code governance, good observability and cultural investment, the company could simultaneously scale GitOps in a hybrid cloud setup and accomplish more speed, compliance and resilience.

Conclusion

GitOps has become a swiftly advancing pattern rather than a developing practice, offering a compelling framework for delivering software in non-trivial, distributed conditions. Being the sole source of truth in Git and performing the reconciliation of the desired and actual states partially automated makes hybrid cloud operations consistent, auditable and reliable, where traditional pipelines fail to deliver the needed consistency, auditability and reliability. However, in addition to the pursuance of ArgoCD or Flux, success at scale is not achieved by chance, but by intentional modifications in architecture, governance, observability and security, supported by cultural change.

Companies investing in these foundations can deploy faster, reduce operational risk and become highly compliant, enabling developers to gain more autonomy. Automation of delivery is not the only goal of GitOps in the wild; it is an endeavor of building trust between systems and teams. It is a viable combination of tools and an avenue to stabilize and scale software functionality for businesses in today’s hybrid cloud age.

November 14, 2025
Styra Makes Source Code Available for Enterprise Edition of OPA

Styra is now making the enterprise edition of the Open Policy Agent (OPA) available under a source license that enables IT teams to modify or change the underlying code as they see fit when integrating it with other applications.

Enterprise OPA is a drop-in replacement for OPA, agent software for implementing policy-as-code that is already available under an open source license. Styra’s enterprise edition provides access to a version that provides better performance, native integrations for a suite of data sources and additional capabilities such as policy decision analysis.

Previously, Enterprise OPA was only available in either a binary or container format. While these formats enable Enterprise OPA to be widely used, they limited it from being built directly into applications for performance optimization because no access was provided to source code.

Chris Hendrix, director of product management for Styra, said the source license also provides organizations with an assurance that they will be able to continue to modify Enterprise OPA in much the same way as they modify the open source edition.

It’s not clear how many DevOps teams are managing policy-as-code within their pipelines, but as application security regulations become more stringent, it’s only a matter of time before most of them do so in one way or another. Styra’s approach relies on a Rego programming language that some DevOps teams have found challenging, however. To make it simpler, the company is working on a low-code approach that would help make Enterprise OPA more accessible, said Hendrix.

In addition to encouraging more DevOps teams to use Enterprise OPA under a source license, Syra is clearly moving to make it more attractive to replace existing instances of OPA with a more robust implementation licensed from the company. No one knows how many instances of the open source edition of OPA advanced under the auspices of the Cloud Native Computing Foundation (CNCF) are running in production environments. But as those applications become more complex, the need for deeper levels of integration enabled by a faster version of OPA becomes more apparent.

OPA enables developers to programmatically embed compliance controls without waiting for a compliance team to make them available. That ultimately makes it simpler to ensure that the proper controls have been implemented before an application is deployed in an on-premises IT environment. That capability also makes it easier to document which controls have been applied to make any audit less time-consuming.

Shifting responsibility for compliance controls to the left also enables DevOps teams to better understand which controls address specific regulatory mandates incorporated into most applications versus which controls might be specific to a specific regulation. Armed with those insights, it then becomes simpler to incorporate policy-as-code within a DevSecOps workflow.

Hopefully, more applications running in production environments will soon be secure by default. Naturally, one of the first places to start is by making sure the compliance controls needed to achieve a baseline level of security have been pervasively implemented.

August 28, 2023
Styra Unfurls Cloud Service for Implementing Compliance-as-Code

Styra, Inc. today launched an authorization service based on the Open Policy Agent (OPA) software that can be invoked via an application programming interface (API).

Torin Sandall, vice president of open source for Styra, said the Styra Run cloud service will make it much simpler to embed enterprise-grade authorization capabilities within applications. Today, developers spend too much time building, maintaining and operating their own authorization platforms to manage permissions across multiple applications.

In addition to enabling developers to access pre-built OPA logic, Sandall noted the service also offloads storage and global replication of end-user permissions data to a cloud service.

The service itself currently runs on Amazon Web Services (AWS), but Styra plans to make the service available on other cloud platforms in the future, he added.

OPA makes use of a general-purpose policy enforcement engine that developers can embed within applications using the Rego language. OPA is now being advanced under the auspices of the Cloud Native Computing Foundation (CNCF) and is gaining traction among cloud-native application developers. OPA provides a means to enforce compliance-as-code across a wide range of microservices that now routinely access a wide range of distributed data.

However, Styra Run should make OPA more accessible to a wider range of organizations, especially those that are looking to shift responsibility for security and compliance further left toward developers as part of a set of DevSecOps processes, noted Sandall. Developers that don’t have a lot of compliance expertise can now rely on a cloud service that enables them to focus more of their time and effort on writing code, he added.

The arrival of Styra Run also comes at a time when more organizations are reviewing their software supply chain processes in the wake of a series of high-profile security breaches. It’s not clear to what degree compliance and cybersecurity teams have developed an appreciation for OPA, but as more organizations embrace compliance-as-code, the pressure on those teams should decrease as those applications are inherently more secure than legacy applications.

There will, of course, be some developers that prefer to embed OPA into applications themselves, but a cloud service accessed via API will be the path of least resistance for most developers building software-as-a-service (SaaS) applications, said Sandall. The issue may simply be making developers aware that another low-latency option exists; one that doesn’t require them to deeply master the Rego programming language for the sole purpose of achieving compliance, he added.

Regardless of approach, the general expectation going forward is that applications will more easily be able to meet a wide range of compliance mandates without requiring IT teams to deploy and maintain dedicated compliance infrastructure. As such, there may soon come a day when any application that doesn’t use some type of compliance-as-code framework will simply be rejected out of hand.

July 13, 2022
Kong Integrates Service Mesh with OPA

Kong, Inc. today announced an update to Kong Mesh, built on top of open source Kuma service mesh, that adds support for Open Policy Agent (OPA) software that enables DevOps teams to manage compliance as code.

Kuma and OPA are both being developed under the auspices of the Cloud Native Computing Foundation (CNCF). Kuma, unlike other service mesh offerings, provides connectivity across both microservices-based applications running on Kubernetes platform and monolithic applications deployed on virtual machines.

In addition to adding support for OPA, the 1.2 release of Kong Mesh adds authentication mechanisms between the global and remote control planes operating across multiple zones. That functionality extends the Kuma Discovery Service (KDS) to support multiple authentication mechanisms.

Finally, Kong has added support for the federal information processing standard (FIPS).

Like the Istio service mesh, advanced by Google and IBM for Kubernetes environments, Kuma is based on open source Envoy proxy software. In contrast, however, Kuma is both lighter-weight and designed to span both cloud-native and legacy application environments.

Marco Palladino, CTO at Kong, said OPA support will be a significant advance for both classes of workloads as organizations start to employ Kuma within the context of zero-trust computing environments. As DevSecOps processes are extended to include managing compliance as code, OPA will provide a programmable mechanism for ensuring that policies are not only properly implemented, but can also be easily audited, Palladino said.

In general, an effort led by Kong, VMware and others to elevate the service mesh conversations to more broadly address application connectivity is underway. A service mesh, at its core, provides the means for integrating hundreds of application programming interfaces (APIs) at scale. It also provides a level of abstraction above the network layer that makes it easier to connect applications across a heterogeneous networking environment.

Kong is making a case for a lighter-weight approach that spans multiple platforms and is highly extensible. As such, third-party vendors and IT teams can add extensions to Kuma as they see fit.

Ultimately, Palladino said, the time has come to take cloud computing to the next level. If all organizations wind up doing is lifting and shifting monolithic applications to public clouds, an opportunity to advance the state of IT will have been lost.

Of course, it’s still early days as far as adoption of service meshes are concerned. Most organizations today are relying on API gateways, proxy software or ingress controllers to manage APIs. It’s not clear to what degree a service mesh may remove the need for some of that existing application connectivity middleware.

Regardless of which approach is ultimately favored, it’s apparent that, as microservices-based applications become more widely deployed, a different approach to application connectivity will be required. Monolithic applications, however, are not going away. In some cases, a monolithic application might be carved up into a smaller set of microservices, but it’s unlikely that every existing monolithic application will lend itself to that architecture any time soon.

March 9, 2021
CNCF Graduates Open Policy Agent Project to Manage Compliance as Code

The Cloud Native Computing Foundation (CNCF) announced this week that the Open Policy Agent (OPA) project, which many IT teams are employing to manage compliance as code, has officially graduated.

Torin Sandall, co-founder of the OPA project and vice president of open source at Styra, whose compliance management platform is based on OPA, said formal recognition of OPA alongside other CNCF projects, such as Kubernetes, should help further adoption of the open source project that first took shape in 2016.

Now being advanced under the auspices of the CNCF, the open source agent created by the OPA project is increasingly being incorporated into a wider range of compliance and security platforms. At the same time, more developers are starting to manage compliance as code across a wider range of applications. The ultimate goal is to make it easier to meet compliance requirements using a declarative framework so that responsibility for implementing compliance policies shifts further left toward developers.

OPA uses a general purpose engine for enforcing policies that uses a set of rules that developers embed within applications using the Rego language. OPA has gained traction among cloud native application developers because it provides a means to enforce policies across a wide range of microservices.

Sandall said going forward, the primary focus of the OPA project should be to develop and share as many integrations as possible. There are many instances where a use case for OPA has been created, but development teams simply don’t know that use case exists. As a result, many IT teams are attempting to employ compliance as code to address an issue that others have already solved, Sandall said.

During its time as an incubation project managed by the CNCF, the security special interest group (SIG) within the CNCF conducted two external OPA security audits. The OPA project has also defined a security vulnerability disclosure process and a security response team.

It’s not clear whether chief compliance officers within enterprise IT organizations have developed an appreciation for OPA. In theory, many compliance issues could be avoided if organizations mandated using OPA – or another approach to managing compliance as code – within their applications. Those compliance issues, of course, are multiplying as the number of compliance mandates expand globally. The challenge is that most compliance teams don’t have much visibility into the application development process.

In the meantime, as DevSecOps processes continue to mature, it seems almost inevitable they would expand to include compliance mandates, most of which only exist to ensure some base level of security is present. Of course, developers may not want to be responsible for compliance mandates. However, the sooner compliance issues are addressed in the development process, the less likely they are to become DevOps’ problem when deployed in a production environment.

February 5, 2021
DevOps Chat: OPA and the CNCF, With Torin Sandall

The Open Policy Agent (OPA) was accepted for incubation by the Cloud Native Computing Foundation. In this DevOps Chat we spoke with one of the founders of the project, Torin Sandall, about OPA and why the CNCF is the right place for OPA. We also discuss the company he works for, Styra, which works with OPA.

As usual, the streaming audio is immediately below, followed by the transcript of our conversation. Enjoy!

Transcript

Alan Shimel: Hey, everyone. This is Alan Shimel, MediaOps, the people behind devopsy.kinsta.cloud, Container Journal, Security Boulevard and DevOps Chat, and you’re listening to another DevOps Chat.

I’m really happy to have as a guest for this DevOps Chat, Torin Sandall, and Torin is actually one of the co-founders of the Open Policy Agent (OPA) open source project, which recently came under the guidance management of Cloud Native Computing.

So, let’s welcome Torin. Torin, you there?

Torin Sandall: Hey, Alan. Yeah, great to talk to you.

Shimel: Great to have you here, and a pleasure to have you joining us on this podcast. Torin, let’s first start off with, maybe there are people out here who don’t know what OPA is—what Open Policy Agent is, right? There’s some great, if you go to—actually, if you go to CNCF.io, there’s a blog article all about it and I’ll put it in our show notes. But for those who are following along or listening to this in their car or what have you, talk to us—what’s Open Policy Agent?

Sandall: Yeah, that’s a great question, and it’s a good way to get started.

So, Open Policy Agent is a domain agnostic policy engine, okay? So, it’s general purpose, meaning that you can kind of take it and use it to enforce all kinds of policies and governance regimes across a wide range of technology.

So, for example, if you want to say that, you know, all of your containers have to be sourced from an internal image registry, you can express that kind of a policy with OPA, or the Open Policy Agent. If you want to do something like say that certain users can only see certain pieces of data served by a micro service, you can also do that with the Open Policy Agent. And if you want to restrict who can SSH into a server or run a pseudo command on a server, you can also do that with the Open Policy Agent.

So, the idea is that we give people this engine that allows them to unify policy control across various pieces of their stack.

Shimel: Excellent. And you know what’s interesting? I was talking to someone the other day and we were talking about, you know, how does Kubernetes fit into this whole Cloud Native thing? Because Cloud Native and the CNCF is bigger than just Kubernetes. And they gave me a really good analogy. They said, “Think of it as like, you know, a fleet of warships or, you know, a U.S. Navy fleet and maybe Kubernetes is the aircraft carrier. But there’s more to the Navy than the aircraft carrier. There’s more to a fleet than an aircraft carrier. There’s battleships and cruisers and destroyers and subs and frigates and amphibious landing ships,” and you know, I’m not a Navy expert. [Laughter] But there’s all these different elements that make up the fleet—and it’s a huge fleet.

And so, you know, when I look at OPA, you know, Open Policy Agent—and we’re gonna talk about joining Cloud Native Computing Foundation—it’s a necessary ship in the fleet, right? That really makes it easier and more practical to use a lot of the tools that are not only in the fleet, but a lot of the commercial tools that kind of exist on the periphery as well. Fair?

Sandall: Absolutely, yeah. The CNCF is a collection of projects that provide a lot of value within the overall ecosystem, and there are a few things that kind of bind them together, and those are kind of high level principles. So, you know, they’re all open source, they are all, you know, they’re oriented around containers. They’re oriented around very dynamic systems that you need to manage at scale.

And so, one of the interesting things about a lot of the projects within the CNCF is that they are kind of building blocks. You can think of them as libraries or building blocks for the overall system, right? And so, you know, they integrate together, you can plug them into other systems and so on. And so, that’s how we kind of look at OPA. That’s how we think about OPA, is as a building block or as a library for enabling rich, fine grain control across a variety of parts of your environment.

Shimel: Absolutely.

Sandall: And, yeah, and so, policy is particularly important when you start to talk about adoption of technology within large organizations, right? As Kubernetes has matured and enterprises have really started to run with it and deploy real production workloads on top of it, they’ve recognized the need for not just simple best practice kind of security measures, but much more sophisticated and rich and fine grained rules and constraints that need to be enforced in a system in order to keep everybody safe. And so, that’s where OPA fits into Kubernetes.

Shimel: Yeah, absolutely. You know what? I realized, and I apologize, I really didn’t do a good job of letting you introduce yourself to our audience on top of [Cross talk].

Sandall: [Laughter] That’s okay.

Shimel: So, Torin, I apologize. In addition to you being one of the co-founders of the project, why don’t you share a little bit about what you do in your day job and the rest of your life?

Sandall: For sure, yeah. So, I think what’s relevant here is that I’m the co-founder of the Open Policy Agent project. I’m also a software engineer at a startup called Styra. We’re the makers of the Open Policy Agent. We founded the project about three years ago—a little over three years ago, actually, and yeah, so we’re kind of like the stewards of the project today. That said, we’re starting to see a lot more people from the community kind of come in and start contributing to Open Policy Agent and related kind of projects in the ecosystem.

So, that’s sort of what I do. My focus is kind of on Open Policy Agent, but I’m super interested in the overall Cloud Native ecosystem and security and policy and all that kinda stuff.

Shimel: So, you know, and I should also mention—I did a terrible job laying this one out, Torin, I apologize. We should also mention that the big news coming out—I guess it was this week, or maybe late last week—was that OPA, Open Policy Agent, has now become or come under the auspices of Cloud Native Computing Foundation (CNCF).

Sandall: That’s right, yeah. So, we actually, we joined the CNCF as a sandbox to your project last year, in 2018. OPA was added into the CNCF sandbox. So, the CNCF has multiple tiers, and right now there’s sandbox, incubation and graduated.

And so, this year, basically, they do a review of projects, you know, every year, and they check in on how the projects are doing and how they’re growing and how their communities are evolving. And that’s just useful, right? To kind of maintain, kind of, you know, good hygiene within the ecosystem. But this time around, we felt that—everybody kinda felt that OPA was growing quite a bit and it kind of deserved to move up to the next level incubation within the CNCF.

And so, the move from sandbox to incubation is really a reflection of the progress that we’ve made over the last year in terms of both production users as well as proof of concepts and integrations, and new external contributors joining the project.

Shimel: Got it. And, you know, I will just mention that, you know, CNCF has really done an amazing job of shepherding these projects, from sandbox into incubation, and then from incubation into graduation. I forgot the number, if it was five or six projects they’ve graduated now.

Sandall: Yeah, I think there’s about five graduated projects today. You know, Kubernetes is one of them, it’s kind of one of the flagship projects, and there are others. And so, yeah, so, they’re really doing a good job of curating a very important set of building blocks, like I said, that are gonna help organizations get to cloud native.

Shimel: So, let me ask you a question—and I think this is something our audience would really enjoy. How did you, as a co-founder of the OPA project, right, what was your sort of motivation for, you know, bringing it under the CNCF?

Sandall: So, yeah, that’s a great question. What we found was that after, you know, the project had been around for over a year, or rather over almost two years, I guess. And what we found with talking to users and potential users was that they wanted to see OPA as part of a kind of vendor neutral organization, right? So, Styra, the company that I work for, had kind of built OPA, and it’s been open source since day one, but people really like to see these kinds of projects, these kinds of core infrastructure components a little bit decoupled from, like say, any particular organization.

Shimel: Mm-hmm.

Sandall: And so—

Shimel: Well, not decoupled from any particular organization. Decoupled from any one particular vendor.

Sandall: One vendor—yeah, sorry. One vendor.

Shimel: There’s not a single vendor.

Sandall: Yes. And so, you know, we looked around and we looked at the CNCF and we really liked what they were doing and we figured that that was the right place for OPA to be.

So, you know, the CNCF basically provides us with this kind of vendor-neutral home for the project, and it allows us to kinda create a rallying point around policy in the cloud native ecosystem. So, that was the main, high level motivation for joining CNCF.

Shimel: Got it. And it makes perfect sense. I mean, I’ve gotta tell you, you know, I don’t know if you’re familiar, but recently, the CNCF launched—not the CNCF, excuse me—the Linux Foundation, right, which is kinda the parent of the CNCF, right?—

Sandall: Right, yes. Yes.

Shimel: —launched another foundation called the CD Foundation, Continuous Delivery.

Sandall: Yes, yes.

Shimel: And CloudBees, the folks at CloudBees and the Jenkins project was given under to the CD Foundation. Jenkins had Jenkins X, Netflix put in Spinnaker and Google put in—I forget its name now, with a T.

Sandall: Tekton?

Shimel: Tekton. They put, you know, put Tekton into the thing. And I had a good chance to interview some of the CloudBees folks with this, and I asked them the same kinda question I just asked you. You know, and it was a very similar answer, that not only do end users perhaps shy away from a single vendor supported project, but it’s very hard for a project to break out of that mold and get other vendors or talent at other vendors to contribute, because they think they’re doing it for the benefit of one of their competitors.

So, by putting it under a neutral party like this, you know, not only is it more palatable to your end users and to the community as a whole, but it’s especially more attractive to that segment of the community that are made up of vendors. And whether you hate vendors and you think they’re all commercial slime who sold out to the man or not, the fact of the matter is, those are the people who have the resources to put into these projects and to move the needle and to keep that ball moving forward and push the rope up the hill and all of that. So, can’t live with ‘em, can’t live without ‘em, and this is a great kinda middle ground.

Sandall: That’s a good point, and I think that, you know, what we’re starting to see are more and more security vendors getting interested in OPA or Open Policy Agent. I like to call it OPA. It’s hard to call it O-P-A when you’ve got that OPA word that you can use, but anyway—

Shimel: Yeah, yeah, yeah. [Laughter]

Sandall: [Laughter] But yeah, so, we’re seeing more and more security vendors get interested in OPA and, you know, that is gonna be instrumental in the long run to achieving the goal of unifying policy control across a number of different systems, right? There’s never gonna be one vendor that rules everything and there’s always gonna be an amalgamation of different technologies. And so, you know, the best that we can do, I think, is provide this building block that can be embedded all over the place and that has, like, the fundamental kind of groundwork that enables unification. So, very exciting times.

Shimel: Absolutely. So, I’m gonna ask you now to put on your entrepreneur’s hat, right? As a co-founder of your company as well, and let’s look at it Torin from that point of view. How is this helping—and I’m not familiar with your company, so I’m gonna apologize in advance. Say the name for us, again?

Sandall: Sorry, the name of the company is Styra.

Shimel: How do you spell that?

Sandall: S-T-Y-R-A.

Shimel: Got it. So, how does this help Styra?

Sandall: That’s a great question. So, yeah, when the founders—I’m not a founder of Styra, I’m an employee at Styra.

Shimel: Oh, I’m sorry. Okay.

Sandall: But anyway, when the founders of Styra started the company, one of the things that they observed was that, in order to unify enforcement of policies across a wide range of technology, there would need to be kind of like a language based approach applied to the problem domain.

And so, that’s one of the things that the Open Policy Agent provides—it gives people this high level declarative language that they can use to codify policies. And so, that was kind of recognized as something that would be needed, and what you quickly kind of—the conclusion you quickly arrive to is that, this was in 2016, 2015, and even more so today, it’s true, but what you quickly arrive at is the realization that that kind of a technology needs to be open source, right? It’s unlikely that organizations are going to want to adopt a proprietary, closed source language. It’s just not going to happen.

And so, right from the very beginning of the company, it was recognized that an important part of the technology was going to be open source. And so, that’s how the kind of project sort of got started.

Shimel: Got it. Got it, got it, got it. You know, I don’t wanna put you on the spot, but a little Styra background—Styra’s venture backed or bootstrapped, or?

Sandall: Yeah, we’re venture-backed, and we recently did a bit of a launch at the RSA Conference a few weeks ago.

Shimel: Really?

Sandall: And so, that was very exciting, yeah. And so, you know, you can think of Styra as a control plane for policies. So, OPA kind of acts as the data plane, right? It’s this thing that you can embed into applications, you can embed it into Kubernetes, you can put it all over the place. But, what you need is also the ability to kind of manage those OPAs that are running all over the place.

And this is what we see within the OPA community—the people that are using OPA building it into their systems. Companies like Netflix that have built an internal security platform around OPA, what they’ve ended up doing is creating a centralized management plane for policy and for security.

And so, that’s what we’re doing at Styra is, we’re helping people kind of think about distributed enforcement of policy and centralized management of policy.

Shimel: Got it.

Sandall: So, we’re focusing today on Kubernetes and you can check out the website, we’ve got a bunch of information on there, but yeah, that’s the high level.

Shimel: Excellent stuff. As a matter of fact, just looking at the website, I didn’t realize this but Styra is Bill Mann’s company.

Sandall: That’s correct, yeah, he’s the CEO.

Shimel: So—just to show you how old I am. I’ve known Bill Mann a really, really long time, like, I remember the day he joined CA.

Sandall: Bill knows a lot of folks, yeah. [Laughter]

Shimel: Yeah, he gets around. Bill’s been around, and so have I.

Sandall: Yeah.

Shimel: I don’t know if that’s a good or a bad thing, you know? But hey, we’re still kickin’. So, tell Bill I said hello, he’ll get a chuckle out of it.

Sandall: Yeah. I will do that, yeah. And we’ve got a great founding team. They are some of the folks that did Nicira, which is one of the very, you know, basically, the first SDN kind of company, right? They [Cross talk]—

Shimel: Yep, I remember that one as well.

Sandall: Yeah. So, we’ve got a deep background within the security and policy space, and we’re kinda taking that and really bringing it into the cloud native ecosystem.

Shimel: Very cool. You know, I don’t wanna make this about Styra because we really wanted to concentrate on OPA and CNCF, but maybe we’ll still, maybe we’ll schedule something, a second one, and we’ll talk—we’ll dive more into Styra.

Sandall: Yeah, that would be great.

Shimel: You guys are gonna be at KubeCon in Madrid—or I mean, in Barcelona?

Sandall: We are gonna be in KubeCon, yes, in Barcelona in May. There are going to be a bunch of talks about Open Policy Agent. There’s gonna be, I think there’s at least three or four sessions that are happening. There’s also a little thing called Cloud Native Rejects the weekend before. [Laughter] These are the talks—like, the BSides Talks, basically for—

Shimel: Yes. Well, that’s how Security BSides started.

Sandall: Yeah, exactly. And so, there’s gonna be a session there with OPA content in it. So, yeah, it’s gonna be a great event.

Shimel: Excellent.

Sandall: And, of course, we’re gonna have a Styra booth at the event, so.

Shimel: So, we will have a, you know, Digital Anarchist is our video platform, and we’ll have a Digital Anarchist set there where we’ll be doing videos. So, be sure—we’ll talk offline, but we’ll get you guys in for a video. We’ll follow up more on that.

Sandall: Perfect! Yeah, looking forward to it.

Shimel: So, is there a timeline for graduation from incubation at CNCF, or that’s kinda open?

Sandall: It’s open. So, you know, they do a yearly review of the project, and it’s kind of up to, you know, the community and CNCF and everybody to kind of decide when that’s right. And so—yeah, so right now, one of the main criteria for graduation is around external contribution. And so, you know, over the next year, we’ll see how external contribution around OPA evolves and if it’s in the right place, then we’ll go ahead with that.

But we’re really happy right now just with the move to incubation because it brings more visibility to the project, it lends more credibility to the project—you know, in addition to all the people that are using it in production, having it more prominently represented within the CNCF is great. So, we’re really happy with where we are today.

Shimel: Fantastic, man. Hey, Torin, I had promised you we’ll do this in 15 minutes, and that was 25 minutes ago.

Sandall: [Laughter]

Shimel: So, I apologize for running over, but I thought we had a good conversation here.

Sandall: Yeah, yeah. Thanks a lot, Alan. Yeah, I appreciate the time to talk about OPA and Styra and I look forward to—

Shimel: Oh, it was really my pleasure. I’d like to—we’ll continue this at maybe KubeCon in May. But before we sign off—so, Styra is Styra.com, S-T-Y-R-A.com. The OPA project, right, is—

Sandall: Yep.

Shimel: —OpenPolicyAgent.org?

Sandall: That’s correct, yep.

Shimel: And, of course, you can find more information on it at the CNCF.io site, right?—

Sandall: Absolutely, yeah, and it’s on GitHub and we also have a blog if you go to blog.OpenPolicyAgent.org, you can find out more there. So, yeah, check it out, and—yeah.

Shimel: [Cross talk] It’s all good. Hey, Torin Sandall, co-founder of the OPA, Open Policy Agent project, which is now being incubated by Cloud Native Computing Foundation, as well as an employee at Styra—for my friend Bill Mann.

Sandall: [Laughter]

Shimel: So, good to have you on there. Say hello to Bill for me. Best of luck with OPA.

Sandall: Will do.

Shimel: And look forward to seeing you in May at KubeCon.

Sandall: Looking forward to it. Talk to you later. Bye.

Shimel: Alright Torin, thanks. Hey, this is Alan Shimel for devopsy.kinsta.cloud, Container Journal and Security Boulevard. You’ve just listened to another DevOps Chat.

— Alan Shimel

May 13, 2019