OPA to graduation


alexis richardson
 

Something something "doomed to reinvent lisp"...

+1, nb


On Mon, 28 Sep 2020, 20:14 Joe Beda, <jbeda@...> wrote:

+1 NB

 

Agree with Gareth that there is no silver bullet here.  Just like programming languages there are preferences and different needs and no one size fits all solution.

 

That being said, I think that OPA clearly hits a sweet spot and has a growing community. And the CNCF is welcoming to ~competing projects so graduating OPA doesn’t mean that other alternatives can’t also be supported and part of the CNCF umbrella.

 

One thing that I’d, personally, like to see is more standardization around the interfaces to these type of systems.  Is it possible to replace OPA with another similar system and not have to retool the APIs to the policy engine?  Would be interesting to standardize around some other interfaces to OPA too like the way that side-channel data is specified/presented and the way that decision information is surfaced back up to external monitoring/logging systems.  (I’ve passed this on to the OPA folks so it should be a surprise to them.)

 

Joe

 

From: cncf-toc@... <cncf-toc@...>
Date: Sunday, September 27, 2020 at 2:10 AM
To: gadi@... <gadi@...>
Cc: CNCF TOC <cncf-toc@...>
Subject: Re: [cncf-toc] OPA to graduation

+1 NB

I'm biased here, as one of the maintainers of the Conftest project
which is now part of OPA.

I wanted to address the point above about Rego.

I'm an unashamed DSL nerd. I was a user and contributor to Puppet and
then worked there. I was an early Docker user, gave talks about
Dockerfile and then worked at Docker. I originally built Conftest in
order to provide a better local developer experience to OPA because I
wanted to use Rego.

But, I'm also a fan of Chef. I spent last week putting together a
bunch of demos using Pulumi. I like general purpose programming
languages too.

Oh, and I like data as well. I contributed to Ansible. I wanted to
like Jsonnet, really like CUE, like aspects of YTT.

I can reason about the trade offs between these 3 different approaches
to configuration for what would be an unreasonable length of time for
most people. As a user and contributor I've been through a few
generations of tools in this space as a user and developer, and I
fully expect to see several more generations too. That's maddening to
some, and fun for me. I have strange hobbies.

The reality here is most end users have a strong preference for tools
in one of those groups at any given moment in time.
This isn't a new observation. It's worth reading the Configuration
Complexity Clock from back in 2012 as it's still as relevant here as
when it was written
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmikehadlow.blogspot.com%2F2012%2F05%2Fconfiguration-complexity-clock.html&amp;data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637367946286664027&amp;sdata=Xf4EZ22F0EdT7e3PHtmBQcNVhfZlmpU%2B0MvddJM8BhE%3D&amp;reserved=0

That is to say we'll likely see 3 distinct policy approaches over
time, one DSL, one data and one general purpose language.
In fact we already see projects like k-rail (using Go for authoring
policies https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcruise-automation%2Fk-rail&amp;data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637367946286664027&amp;sdata=S6iscJAvXQfHTLLDi6AIbWVwCi89SU3tjbfcAcM%2BzHI%3D&amp;reserved=0) and Kyverno
(using YAML for authoring https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnirmata%2Fkyverno&amp;data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637367946286664027&amp;sdata=54ow6wTL166eK19uxAi7%2BZZkJ1a3IahR4YKm0RmZGeI%3D&amp;reserved=0)

OPA today focuses on one of these approaches, my experience tells me
there will always be folks who prefer one of the others, and that's
fine. The CNCF shouldn't enforce one approach or another, but look at
usage.

The Open Policy Agent community in general has also been working on
lowering the barrier to learning Rego. The rego playground in
particular is invaluable https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplay.openpolicyagent.org%2F&amp;data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637367946286674021&amp;sdata=aZZEpTkffy3nbwbuz71hBtK42qAQJtLpssRKNuz2PcI%3D&amp;reserved=0. Rego
adoption has been growing rapidly, it's nature means most rego is
written behind private repos but
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgithub%2Flinguist%2Fissues%2F4219&amp;data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637367946286674021&amp;sdata=gbLcPvm0txcoE%2B8QXBl0Tp3cMdL8shHqZML%2FXSk9NbY%3D&amp;reserved=0 shows 296 rego files
publicly on GitHub in January 2019. Today there are more than 6000
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsearch%3Futf8%3D%25E2%259C%2593%26type%3DCode%26ref%3Dsearchresults%26q%3Dextension%3Arego%2Bpackage%2BNOT%2Bnothack&amp;data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637367946286674021&amp;sdata=dq2gMhiDLnfHxlG3MxDWmeq1DzHjckN%2FfAmoaEvfenQ%3D&amp;reserved=0.
There has also been work done around sharing, so many end users can
use Open Policy Agent without needing to write rego. For instance we
were one of the first communities to define OCI Artifact metadata
(https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopen-policy-agent%2Fopa%2Fissues%2F1413&amp;data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637367946286674021&amp;sdata=BZPQBu4p2GzC7XsfDkvWBH4syELw6eoFCHE581CgFYM%3D&amp;reserved=0) which then
powers features like
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Faws.amazon.com%2Fblogs%2Fcontainers%2Foci-artifact-support-in-amazon-ecr%2F&amp;data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637367946286674021&amp;sdata=7zQ7z6Zpz%2BFr0%2FEycFdgOMI5aijqgV7Lk8VHpecewoY%3D&amp;reserved=0.

Hopefully that's a useful viewpoint and addition to the conversation.

Gareth





Andrés Vega
 

Working in synchronicity from the authentication problem space adjacent to authorization, it has been fascinating to watch OPA evolve and grow in both adoption and maturity. 

In every SPIFFE and SPIRE conversation, OPA always surfaces as the best architectural fit for a comprehensive identity and authorization solution. While there is a learning curve to Rego, people do manage to wrap their heads around it as it pays dividends in return.

As Joe, I'd like to see overtime further standardization of the APIs. 

+1 NB


Andres


Liz Rice
 

I really like OPA, and the project is doing tons of things really well, but I am struggling to add a +1 on the voting thread for it. When we move something to graduation, the TOC is sending a strong message that we think it's ready for end users to run in production - but to me it's not exactly clear what we're recommending. Anecdotally it seems to me that for a lot of folks in our community, OPA is synonymous with Gatekeeper. And that's a really useful component, and I don't want to do a disservice to the great work being done on it, but I don't think it's necessarily true that webhook + Gatekeeper is a robust, scalable solution that end users can assume they can deploy today with little-to-no risk.  

I am very open to hearing why my concern is misplaced - for example am I missing messaging about other situations where OPA is being widely used, or how Gatekeeper is positioned? 


John Belamaric
 

+1 nb

On Mon, Sep 28, 2020 at 11:44 AM Andrés Vega <andresvega1@...> wrote:
Working in synchronicity from the authentication problem space adjacent to authorization, it has been fascinating to watch OPA evolve and grow in both adoption and maturity. 

In every SPIFFE and SPIRE conversation, OPA always surfaces as the best architectural fit for a comprehensive identity and authorization solution. While there is a learning curve to Rego, people do manage to wrap their heads around it as it pays dividends in return.

As Joe, I'd like to see overtime further standardization of the APIs. 

+1 NB


Andres


Joe Searcy
 

I can't speak for everyone, but we are, and have been for the last 2+ years, been making great use of OPA in production across our entire fleet of Kubernetes clusters and several other ecosystem components. While I do agree that some folks associate OPA with Gatekeeper, OPA is much more ubiquitous. The admission controller model with OPA is very popular, but other example of how we use it are:

- Custom authorization policies within Envoy/Gloo
- Generic RBAC for several in-house built tools/apps
- Custom Token validation
- Generic CI/CD conformance 
- Kubernetes Fleet conformance (cross-cluster policy)

We run 100's of OPA instances as both containers and as embedded libraries.

Use cases like Conftest come to mind as well.


Gareth Rushgrove
 

On Wed, 9 Dec 2020 at 19:11, Liz Rice <liz@...> wrote:

I really like OPA, and the project is doing tons of things really well, but I am struggling to add a +1 on the voting thread for it. When we move something to graduation, the TOC is sending a strong message that we think it's ready for end users to run in production - but to me it's not exactly clear what we're recommending. Anecdotally it seems to me that for a lot of folks in our community, OPA is synonymous with Gatekeeper. And that's a really useful component, and I don't want to do a disservice to the great work being done on it, but I don't think it's necessarily true that webhook + Gatekeeper is a robust, scalable solution that end users can assume they can deploy today with little-to-no risk.

I am very open to hearing why my concern is misplaced - for example am I missing messaging about other situations where OPA is being widely used, or how Gatekeeper is positioned?
I think Gatekeeper is interesting, but it's a sub-project of Open
Policy Agent, not the whole thing. Anecdotally I mainly talk to a lot
more folks using OPA outside Kubernetes than those just using it for
Kubernetes-related use cases. Download stats are imperfect, but do
bring some data points.

At least direct from GitHub, Conftest
(https://github.com/open-policy-agent/conftest/, another sub-project)
gets a lot more direct downloads than OPA. That's intentional (at
least to me, as the creator and one of the maintainers!) as it's
intended for local individual usage. It's developers downloading it to
their desktops, from homebrew or direct from GitHub.

The latest Conftest release has seen ~7000 downloads across platforms
(not including the container image) and was shipped <1 month ago (14th
November).

The Docker Hub published images tell the other part of the story

10M+
https://hub.docker.com/r/openpolicyagent/opa/

1M+
https://hub.docker.com/r/openpolicyagent/gatekeeper

100k+
https://hub.docker.com/r/openpolicyagent/conftest (formerly
https://hub.docker.com/r/instrumenta/conftest)

Gatekeeper here outstrips Conftest, given it's server vs local use
case. OPA itself is more popular still, because while Gatekeeper is
only for Kubernetes, OPA itself can be used with Kubernetes, but it's
also used for other generic policy use cases in the broader cloud
native ecosystem.

GitHub Stars (pah!) are interesting in microcosm here as well:

Conftest - 1.5k
Gatekeeper - 1.4k
OPA - 4.3k

But that's also just direct usage. OPA itself I'd argue is also partly
something others build on top of as a library. Others will have other
private and public examples, but for instance
https://forsetisecurity.org/docs/latest/configure/real-time-enforcer/opa-engine.html
or https://docs.ceph.com/en/latest/radosgw/opa/.

What ties all of those OPA-powered tools together is the Rego policy
language and I think that's an important aspect here with regards to
graduation. Another datapoint was there was enough Rego code on GitHub
for them to add support for code search and highlighting last year
https://github.com/github/linguist/pull/4371#issuecomment-533053406.
The amount of public Rego code has continued to grow as well
https://github.com/search?utf8=%E2%9C%93&type=Code&ref=searchresults&q=extension%3Arego+package,
from around 200 results a over a year ago to more than 7000 now. Note
as well most of the Rego written, by its nature, is going to be
private.

Hopefully that's useful context about the project and ecosystem. There
are likely some good user stories as well that others can share to
compliment my data deluge. The Gatekeeper folks can probably comment
on Gatekeeper specifically too, but Open Policy Agent is a bigger
project with a broader impact on the wider cloud native community I
feel.

Gareth



--
Gareth Rushgrove
@garethr

garethr.dev
devopsweekly.com


jkrach@...
 

We've also been using OPA in production for use cases such as:
1. microservice authorization policy
2. internal webapp authorization policies via Envoy filter
3. kafka authorization

We also spoke at Kubecon 2019 about some of our use cases, you can check it out here: https://www.youtube.com/watch?v=LhgxFICWsA8

Gatekeeper / K8S admission is actually one of the main use cases we still haven't fully integrated (in the works though)!


dpopes@...
 

+1

This is so great to hear! Congratulations to the OPA team!

I'm the Group Tech Lead for the Security Org at Yelp. I've found great utility from the OPA project. At the time of this writing, I've implemented authorization semantics using OPA across several different use cases:

- Service mesh authorization (via Envoy ext_authz filter)
- Linux authorization (via PAM module)
- Kubernetes Authorization (via Authorization Webhook)

In all these cases, OPA has been able to meet all security and operational requirements. 

My experience with the documentation, tooling, and support from the maintainers and the community has been really positive.

Daniel Popescu