OPA brewing made easy
In the last few years, the Open Policy Agent (OPA), an open source CNCF project, has gained immense popularity with developers. However, Rego, the language required to write OPA policies, can be a limitation for users who are now required to learn a new language. Today, we are excited to announce brewOPA, an extensible open-source framework that enables developers to easily brew OPA policies by writing them in the human-friendly YAML.
One of the reasons for OPA’s popularity is that it allows policy evaluation to be decoupled from the application’s core business logic — policy engine internals are abstracted out and easily reused across multiple components. Its lightweight design, general-purpose policy engine, and flexible deployability (as a sidecar, host-level daemon, or library) have led to extensive use for a number of security and resource management related purposes at Netflix, Intuit, Yelp, Pinterest and others. It has a vibrant community behind it supported by the great folks at Styra.
At Cyral, we incorporated OPA into our architecture early on as we started implementing a new data layer security model. One of our capabilities is that constraints may be placed on every individual access of every data endpoint. Constraints are expressed in the form of data being accessed, the identity of the accessor, scope of authorization, etc. and are designed to be at the same time expressive enough to cover all categories of accesses, and intuitive for DevOps and SecOps teams to think about data layer security. Policies are specified declaratively, may be updated at any time without recompiling or redeploying the service, and are enforced automatically.
OPA has helped us develop and scale the core product independently, even as our security policies became more sophisticated and comprehensive over time. Architecturally, our service delegates policy decisions to OPA by executing queries (in the form of REST APIs or library method calls) against it. OPA evaluates policies on the input data and produces evaluation results, which Cyral service then acts upon. Policies are written in a high-level JSON-friendly declarative language called Rego.
We initially exposed the OPA interface directly to our service users, which meant they could use our security model to write declarative policies in Rego. While this gave them the power to implement sophisticated policies, more often than not we ran into users that lacked the bandwidth to invest time in learning a new language. Quickly, it became apparent that a simplified interface to OPA was needed. So, we added the ability to accept policies specified in the widely used human friendly YAML format (example below). Internally, YAML policies get converted to Rego code in our product and are pushed to OPA which runs as a Golang library.
These YAML policies have been a particularly well-loved capability of our product from a user experience perspective. In practice, having these enables our service to get treated as part of our users’ infrastructure-as-code frameworks. All YAML policies are managed using a revision control system such as git allowing for collaboration through pull requests and reviews. Linters ensure that the policies are syntactically and semantically correct while webhooks are used to trigger policy updates.
Still in the early stages, I believe this project has a lot of potential to make it very easy for developers, DevOps and SecOps teams interface with policy engines of the future. Specifically, I see YAML interfaces evolving into intuitive domain specific languages (DSLs) for data security. While YAML is a human friendly format, it still has a lot of quirks around indentation and spacing. DSLs are more natural for expressing policy descriptions and are devoid of such issues.
With that in mind, today we are excited to share the policy engine component of our product with the entire open source community under the wonderful CNCF umbrella. The project is called brewOPA and can be found at https://github.com/cyralinc/brewOPA.
We welcome passionate open source developers to review brewOPA’s philosophy and charter, and start contributing to it. Many thanks to the OPA community for building an amazing product that has made this possible!
Building Documentation for an API-first Product
In this blog post our team shares their experience and design choices in building our documentation site from scratch using tools like Gatsby, Markdown, Docz, …
The Security Digest: Week 21
Hello and welcome to TSD, your regular blog post with top of mind security issues. TSD began as an internal newsletter that our Security Lead, …