OPA to graduation


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


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)!


Gareth Rushgrove
 

On Wed, 9 Dec 2020 at 19:11, Liz Rice <liz@lizrice.com> 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


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.


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


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? 


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


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





Joe Beda <jbeda@...>
 

+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





Jim Bugwadia
 

+1 NB

I am a maintainer of Kyverno (https://github.com/nirmata/kyverno/blob/master/README.md), which as mentioned above is an alternative to OPA/Gatekeeper. We believe that policies are essential to wider (and safer) enterprise adoption of Kubernetes, which is why we built Kyverno to be easy to use and maintain for all Kubernetes users.

I agree with all the points above on the steep learning curve and ongoing challenges of managing OPA policies in Rego. However, my understanding of the incubating-to-graduation requirements is that they are based on project usage and maturity. 

Assuming OPA meets all listed graduation requirements, and assuming that there will be other alternatives like Kyverno, etc. that will ideally become part of the CNCF ecosystem (Kyverno is planning sandbox submission), I see overall value and benefits in OPA graduating to help promote one available approach for managing policies in Kubernetes.

Regards,

Jim

On Sun, Sep 27, 2020 at 2:10 AM Gareth Rushgrove <gareth@...> wrote:
+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://mikehadlow.blogspot.com/2012/05/configuration-complexity-clock.html

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://github.com/cruise-automation/k-rail) and Kyverno
(using YAML for authoring https://github.com/nirmata/kyverno)

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://play.openpolicyagent.org/. Rego
adoption has been growing rapidly, it's nature means most rego is
written behind private repos but
https://github.com/github/linguist/issues/4219 shows 296 rego files
publicly on GitHub in January 2019. Today there are more than 6000
https://github.com/search?utf8=%E2%9C%93&type=Code&ref=searchresults&q=extension%3Arego+package+NOT+nothack.
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://github.com/open-policy-agent/opa/issues/1413) which then
powers features like
https://aws.amazon.com/blogs/containers/oci-artifact-support-in-amazon-ecr/.

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

Gareth






Gareth Rushgrove
 

+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://mikehadlow.blogspot.com/2012/05/configuration-complexity-clock.html

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://github.com/cruise-automation/k-rail) and Kyverno
(using YAML for authoring https://github.com/nirmata/kyverno)

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://play.openpolicyagent.org/. Rego
adoption has been growing rapidly, it's nature means most rego is
written behind private repos but
https://github.com/github/linguist/issues/4219 shows 296 rego files
publicly on GitHub in January 2019. Today there are more than 6000
https://github.com/search?utf8=%E2%9C%93&type=Code&ref=searchresults&q=extension%3Arego+package+NOT+nothack.
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://github.com/open-policy-agent/opa/issues/1413) which then
powers features like
https://aws.amazon.com/blogs/containers/oci-artifact-support-in-amazon-ecr/.

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

Gareth


Gadi Naor
 

-1 NB 

The community around this project is great and there is a consensus on problem space.

Having the benefit of solving and working with customers on Kubernetes security compliance and authorization challenges for quite some time, and integrating OPA as part of our engine - I've witnessed unanimous feedback that OPA REGO has a steep learning curve, and high touch ongoing costs.

Nowadays with building blocks such as WASM, and motion around IaC that use real programming languages (Pulumi & CDK) I believe the ecosystem should strive to make the life of engineering teams easier, possibly in their comfort zone programming language (hey, Go, JS ... can work fine on documents) rather than introducing a new, none intuitive, high touch programming language.

Also, with regards to OPA applications such as Gatekeeper , Kafka Authorizer, conftest and others - Are those OPA applications proposed for graduation? 
Gatekeeper constraints and templates is gr8 - and I'd vote to graduate Gatekeeper with at least none REGO working PoC.

Gadi


On Sat, Sep 19, 2020 at 7:49 PM <nuhamind2@...> wrote:
I believe similar point about the core-project/heart-of-the-system maintainership is raised on the past graduation proposal



--
Gadi NaorCTO

US.   2443 Fillmore St, San Francisco, CA, 94115
IL.    5 Miconis St, Tel Aviv, 6777214   
M. +972-52-6618811
Web.      www.alcide.io
GitHub. github.com/alcideio

Follow us on LinkedInFollow us on Twitter 


Securing Kubernetes & Service Mesh.
Anywhere.
Bridging Security & DevOps.

Cloud Native Virtual Summit is October 6-8.    Register HERE





nuhamind2@...
 

I believe similar point about the core-project/heart-of-the-system maintainership is raised on the past graduation proposal


Liz Rice
 

+1 thanks Torin 

(TOC folks - this seems an interesting model we should think about in the broader discussion of governance models / steering committees)


On Fri, 18 Sep 2020 at 22:28, Saad Ali <saadali@...> wrote:
Great, thank you for the clarification!

On Fri, Sep 18, 2020 at 2:22 PM Torin Sandall <torin@...> wrote:
No, it’s an organization vote meaning each organization can only vote once.

On Fri, Sep 18, 2020 at 5:20 PM Saad Ali <saadali@...> wrote:
Got it. Since, 4/8 maintainers are from a single organization and changes require 2/3 majority, does that mean a single organization could effectively veto any changes?

On Fri, Sep 18, 2020 at 2:05 PM Torin Sandall <torin@...> wrote:




What does "all areas of expertise" mean? Does it mean all the folks in https://github.com/open-policy-agent/opa/blob/master/MAINTAINERS.md ?

Yes, any maintainer, regardless of their area of expertise (e.g., a specific repo or subtree) would vote.

On Fri, Sep 18, 2020 at 4:18 PM Saad Ali <saadali@...> wrote:
Thank you for the clarification Torin!

On Fri, Sep 18, 2020 at 11:41 AM Torin Sandall via lists.cncf.io <torin=styra.com@...> wrote:
Hi Liz,

To your comment, the OPA governance model protects against one organization unfairly controlling any part of the project (including the open-policy-agent/opa repository) by allowing any maintainer (from any repository) to call for an update to the model (this is covered by the "Changes in Governance" section).

The governance doc says "All changes in Governance require a 2/3 majority organization vote from all areas of expertise."
What does "all areas of expertise" mean? Does it mean all the folks in https://github.com/open-policy-agent/opa/blob/master/MAINTAINERS.md ?

 

The model we have in place balances (i) the desire for experts on a repository to make decisions for that repository and (ii) for the OPA contributor community to take action if one or more organizations starts misbehaving. Sustained contributors for each repository make decisions for what goes into that repository, but if those contributors begin making decisions that are not in the interest of the broader community, the OPA governance model allows maintainers from other repositories to step in and take corrective action. The model is based on the premise that maintainers are acting in the best interest of the community, but it recognizes that exceptions can occur and accounts for that.

https://github.com/open-policy-agent/opa/blob/master/GOVERNANCE.md#changes-in-governance

On Fri, Sep 18, 2020 at 3:27 AM Liz Rice <liz@...> wrote:
I am a big fan of OPA, and in general the project seems to be going well. But it does give me pause to see that open-policy-agent/opa (in particular) is controlled by one organisation 

Liz 

On Fri, 18 Sep 2020 at 00:42, Maor Goldberg <maor@...> wrote:
Thank you for the clarification Torin, appreciate it. 

My intention was to highlight the need and to hopefully encourage other organizations to join and help your team. 
We are participating in the community meetings for a long time now and can only applaud everything that Styra is doing. 

Congratulations and good luck!






On Sep 17, 2020, at 3:07 PM, Torin Sandall via lists.cncf.io <torin=styra.com@...> wrote:

Hi All,

Maor from apolicy.io sent a follow up email asking about organization responsibilities for different repos. This is all covered in the MAINTAINER.md file:
# Maintainers



The following table lists OPA project maintainers and areas of expertise in alphabetical order:



| Name | GitHub | Email | Organization | Repositories/Area of Expertise | Added/Renewed On |

| --- | --- | --- | --- | --- | --- |

| Ash Narkar | @ashutosh-narkar | anarkar4387@... | Styra | opa, opa-istio-plugin | 2020-04-14 |

| Craig Tabita | @ctab | ctab@... | Google | gatekeeper, gatekeeper-library | 2020-04-14 |

| Max Smythe | @maxsmythe | smythe@... | Google | frameworks/constraints, gatekeeper, gatekeeper-library | 2020-04-14 |

| Patrick East | @patrick-east | east.patrick@... | Styra | opa | 2020-04-14 |

| Rita Zhang | @ritazh | rita.z.zhang@... | Microsoft | frameworks/constraints, gatekeeper, gatekeeper-library | 2020-04-14 |

| Sertaç Özercan | @sozercan | sozercan@... | Microsoft | gatekeeper, gatekeeper-library | 2020-04-14 |

| Tim Hinrichs | @timothyhinrichs | timothy.l.hinrichs@... | Styra | all repositories | 2020-04-14 |

| Torin Sandall | @tsandall | torinsandall@... | Styra | all repositories | 2020-04-14 |

We also have non-voting folks w/ write access on certain repos, which is valuable for onboarding



new contributors to admin the project on a day-to-day basis w/o inheriting full voting rights that are essentially a conflict resolution mechanism for when other attempts to reach consensus fail. Here's a summary of contributor organizations w/ write across across major repos under the open-policy-agent org:

* open-policy-agent/conftest - DataWorkz, Plex, Red Hat,Snyk, Styra
* open-policy-agent/frameworks - Google, Microsoft, Styra
* open-policy-agent/gatekeeper - Google, Microsoft, Styra
* open-policy-agent/gatekeeper-library - Google, Microsoft, Styra
* open-policy-agent/opa - Styra
* open-policy-agent/opa-envoy-plugin - Styra

We're always looking for folks that are interested in making long-term sustained contributions. If you're interested, please get in touch.

On Wed, Sep 16, 2020 at 6:05 PM Torin Sandall <torin@...> wrote:
Hi Maor,

Gatekeeper is not a separate project--it's a part of the OPA project. Microsoft and Google are maintainers of Gatekeeper as well as OPA, meaning all three organizations have the voting rights that go along with maintainership as outlined in our MAINTAINERS.md and GOVERNANCE.md files:

https://github.com/open-policy-agent/opa/blob/master/GOVERNANCE.md
https://github.com/open-policy-agent/opa/blob/master/MAINTAINERS.md

As far as plans for more organizations go, we have a governance process defined that outlines how new maintainers can be added. It requires a proposal from an existing maintainer and a vote from the other maintainers. That would likely occur after someone has made sustained contributions over a period of time. Note, the governance model allows for individuals to be granted permission to admin repos on GitHub without being granted full voting rights to onboard external efforts within OPA (this is how open-policy-agent/conftest is currently managed.)

-Torin

On Wed, Sep 16, 2020 at 5:03 PM Maor Goldberg <maor@...> wrote:
Hey,

Great news and congratulations to the OPA team, great project and a cornerstone for the cloud native enterprise. 

Looking at the maintainer status on the project, I wonder if there’s a plan to add more organizations?
I believe there’s only one organization (Styra) with maintainer status on the OPA project while Google and Microsoft only maintain the Gatekeeper project (my understanding is that Gatekeeper is a separate project). 

I think it will be great to see more than one organization sharing responsibility and leadership for this important project.

Good luck,
Maor. 


<PastedGraphic-1.tiff>




On Sep 16, 2020, at 10:46 AM, Brendan Burns via lists.cncf.io <bburns=microsoft.com@...> wrote:

Folks

The OPA project has applied for graduation from incubation to graduated. (https://github.com/cncf/toc/pull/520)


The public comment period is now open for 2 weeks, and all SIGs, end users, TOC members, and community members are welcome to comment by replying to this thread.

Brendan Burns








--
-Torin




--
-Torin

























--
-Torin














--
-Torin




--
-Torin





Saad Ali
 

Great, thank you for the clarification!

On Fri, Sep 18, 2020 at 2:22 PM Torin Sandall <torin@...> wrote:
No, it’s an organization vote meaning each organization can only vote once.

On Fri, Sep 18, 2020 at 5:20 PM Saad Ali <saadali@...> wrote:
Got it. Since, 4/8 maintainers are from a single organization and changes require 2/3 majority, does that mean a single organization could effectively veto any changes?

On Fri, Sep 18, 2020 at 2:05 PM Torin Sandall <torin@...> wrote:




What does "all areas of expertise" mean? Does it mean all the folks in https://github.com/open-policy-agent/opa/blob/master/MAINTAINERS.md ?

Yes, any maintainer, regardless of their area of expertise (e.g., a specific repo or subtree) would vote.

On Fri, Sep 18, 2020 at 4:18 PM Saad Ali <saadali@...> wrote:
Thank you for the clarification Torin!

On Fri, Sep 18, 2020 at 11:41 AM Torin Sandall via lists.cncf.io <torin=styra.com@...> wrote:
Hi Liz,

To your comment, the OPA governance model protects against one organization unfairly controlling any part of the project (including the open-policy-agent/opa repository) by allowing any maintainer (from any repository) to call for an update to the model (this is covered by the "Changes in Governance" section).

The governance doc says "All changes in Governance require a 2/3 majority organization vote from all areas of expertise."
What does "all areas of expertise" mean? Does it mean all the folks in https://github.com/open-policy-agent/opa/blob/master/MAINTAINERS.md ?

 

The model we have in place balances (i) the desire for experts on a repository to make decisions for that repository and (ii) for the OPA contributor community to take action if one or more organizations starts misbehaving. Sustained contributors for each repository make decisions for what goes into that repository, but if those contributors begin making decisions that are not in the interest of the broader community, the OPA governance model allows maintainers from other repositories to step in and take corrective action. The model is based on the premise that maintainers are acting in the best interest of the community, but it recognizes that exceptions can occur and accounts for that.

https://github.com/open-policy-agent/opa/blob/master/GOVERNANCE.md#changes-in-governance

On Fri, Sep 18, 2020 at 3:27 AM Liz Rice <liz@...> wrote:
I am a big fan of OPA, and in general the project seems to be going well. But it does give me pause to see that open-policy-agent/opa (in particular) is controlled by one organisation 

Liz 

On Fri, 18 Sep 2020 at 00:42, Maor Goldberg <maor@...> wrote:
Thank you for the clarification Torin, appreciate it. 

My intention was to highlight the need and to hopefully encourage other organizations to join and help your team. 
We are participating in the community meetings for a long time now and can only applaud everything that Styra is doing. 

Congratulations and good luck!






On Sep 17, 2020, at 3:07 PM, Torin Sandall via lists.cncf.io <torin=styra.com@...> wrote:

Hi All,

Maor from apolicy.io sent a follow up email asking about organization responsibilities for different repos. This is all covered in the MAINTAINER.md file:
# Maintainers



The following table lists OPA project maintainers and areas of expertise in alphabetical order:



| Name | GitHub | Email | Organization | Repositories/Area of Expertise | Added/Renewed On |

| --- | --- | --- | --- | --- | --- |

| Ash Narkar | @ashutosh-narkar | anarkar4387@... | Styra | opa, opa-istio-plugin | 2020-04-14 |

| Craig Tabita | @ctab | ctab@... | Google | gatekeeper, gatekeeper-library | 2020-04-14 |

| Max Smythe | @maxsmythe | smythe@... | Google | frameworks/constraints, gatekeeper, gatekeeper-library | 2020-04-14 |

| Patrick East | @patrick-east | east.patrick@... | Styra | opa | 2020-04-14 |

| Rita Zhang | @ritazh | rita.z.zhang@... | Microsoft | frameworks/constraints, gatekeeper, gatekeeper-library | 2020-04-14 |

| Sertaç Özercan | @sozercan | sozercan@... | Microsoft | gatekeeper, gatekeeper-library | 2020-04-14 |

| Tim Hinrichs | @timothyhinrichs | timothy.l.hinrichs@... | Styra | all repositories | 2020-04-14 |

| Torin Sandall | @tsandall | torinsandall@... | Styra | all repositories | 2020-04-14 |

We also have non-voting folks w/ write access on certain repos, which is valuable for onboarding



new contributors to admin the project on a day-to-day basis w/o inheriting full voting rights that are essentially a conflict resolution mechanism for when other attempts to reach consensus fail. Here's a summary of contributor organizations w/ write across across major repos under the open-policy-agent org:

* open-policy-agent/conftest - DataWorkz, Plex, Red Hat,Snyk, Styra
* open-policy-agent/frameworks - Google, Microsoft, Styra
* open-policy-agent/gatekeeper - Google, Microsoft, Styra
* open-policy-agent/gatekeeper-library - Google, Microsoft, Styra
* open-policy-agent/opa - Styra
* open-policy-agent/opa-envoy-plugin - Styra

We're always looking for folks that are interested in making long-term sustained contributions. If you're interested, please get in touch.

On Wed, Sep 16, 2020 at 6:05 PM Torin Sandall <torin@...> wrote:
Hi Maor,

Gatekeeper is not a separate project--it's a part of the OPA project. Microsoft and Google are maintainers of Gatekeeper as well as OPA, meaning all three organizations have the voting rights that go along with maintainership as outlined in our MAINTAINERS.md and GOVERNANCE.md files:

https://github.com/open-policy-agent/opa/blob/master/GOVERNANCE.md
https://github.com/open-policy-agent/opa/blob/master/MAINTAINERS.md

As far as plans for more organizations go, we have a governance process defined that outlines how new maintainers can be added. It requires a proposal from an existing maintainer and a vote from the other maintainers. That would likely occur after someone has made sustained contributions over a period of time. Note, the governance model allows for individuals to be granted permission to admin repos on GitHub without being granted full voting rights to onboard external efforts within OPA (this is how open-policy-agent/conftest is currently managed.)

-Torin

On Wed, Sep 16, 2020 at 5:03 PM Maor Goldberg <maor@...> wrote:
Hey,

Great news and congratulations to the OPA team, great project and a cornerstone for the cloud native enterprise. 

Looking at the maintainer status on the project, I wonder if there’s a plan to add more organizations?
I believe there’s only one organization (Styra) with maintainer status on the OPA project while Google and Microsoft only maintain the Gatekeeper project (my understanding is that Gatekeeper is a separate project). 

I think it will be great to see more than one organization sharing responsibility and leadership for this important project.

Good luck,
Maor. 


<PastedGraphic-1.tiff>




On Sep 16, 2020, at 10:46 AM, Brendan Burns via lists.cncf.io <bburns=microsoft.com@...> wrote:

Folks

The OPA project has applied for graduation from incubation to graduated. (https://github.com/cncf/toc/pull/520)


The public comment period is now open for 2 weeks, and all SIGs, end users, TOC members, and community members are welcome to comment by replying to this thread.

Brendan Burns








--
-Torin




--
-Torin

























--
-Torin














--
-Torin




--
-Torin


Torin Sandall
 

No, it’s an organization vote meaning each organization can only vote once.

On Fri, Sep 18, 2020 at 5:20 PM Saad Ali <saadali@...> wrote:
Got it. Since, 4/8 maintainers are from a single organization and changes require 2/3 majority, does that mean a single organization could effectively veto any changes?

On Fri, Sep 18, 2020 at 2:05 PM Torin Sandall <torin@...> wrote:




What does "all areas of expertise" mean? Does it mean all the folks in https://github.com/open-policy-agent/opa/blob/master/MAINTAINERS.md ?

Yes, any maintainer, regardless of their area of expertise (e.g., a specific repo or subtree) would vote.

On Fri, Sep 18, 2020 at 4:18 PM Saad Ali <saadali@...> wrote:
Thank you for the clarification Torin!

On Fri, Sep 18, 2020 at 11:41 AM Torin Sandall via lists.cncf.io <torin=styra.com@...> wrote:
Hi Liz,

To your comment, the OPA governance model protects against one organization unfairly controlling any part of the project (including the open-policy-agent/opa repository) by allowing any maintainer (from any repository) to call for an update to the model (this is covered by the "Changes in Governance" section).

The governance doc says "All changes in Governance require a 2/3 majority organization vote from all areas of expertise."
What does "all areas of expertise" mean? Does it mean all the folks in https://github.com/open-policy-agent/opa/blob/master/MAINTAINERS.md ?

 

The model we have in place balances (i) the desire for experts on a repository to make decisions for that repository and (ii) for the OPA contributor community to take action if one or more organizations starts misbehaving. Sustained contributors for each repository make decisions for what goes into that repository, but if those contributors begin making decisions that are not in the interest of the broader community, the OPA governance model allows maintainers from other repositories to step in and take corrective action. The model is based on the premise that maintainers are acting in the best interest of the community, but it recognizes that exceptions can occur and accounts for that.

https://github.com/open-policy-agent/opa/blob/master/GOVERNANCE.md#changes-in-governance

On Fri, Sep 18, 2020 at 3:27 AM Liz Rice <liz@...> wrote:
I am a big fan of OPA, and in general the project seems to be going well. But it does give me pause to see that open-policy-agent/opa (in particular) is controlled by one organisation 

Liz 

On Fri, 18 Sep 2020 at 00:42, Maor Goldberg <maor@...> wrote:
Thank you for the clarification Torin, appreciate it. 

My intention was to highlight the need and to hopefully encourage other organizations to join and help your team. 
We are participating in the community meetings for a long time now and can only applaud everything that Styra is doing. 

Congratulations and good luck!






On Sep 17, 2020, at 3:07 PM, Torin Sandall via lists.cncf.io <torin=styra.com@...> wrote:

Hi All,

Maor from apolicy.io sent a follow up email asking about organization responsibilities for different repos. This is all covered in the MAINTAINER.md file:
# Maintainers



The following table lists OPA project maintainers and areas of expertise in alphabetical order:



| Name | GitHub | Email | Organization | Repositories/Area of Expertise | Added/Renewed On |

| --- | --- | --- | --- | --- | --- |

| Ash Narkar | @ashutosh-narkar | anarkar4387@... | Styra | opa, opa-istio-plugin | 2020-04-14 |

| Craig Tabita | @ctab | ctab@... | Google | gatekeeper, gatekeeper-library | 2020-04-14 |

| Max Smythe | @maxsmythe | smythe@... | Google | frameworks/constraints, gatekeeper, gatekeeper-library | 2020-04-14 |

| Patrick East | @patrick-east | east.patrick@... | Styra | opa | 2020-04-14 |

| Rita Zhang | @ritazh | rita.z.zhang@... | Microsoft | frameworks/constraints, gatekeeper, gatekeeper-library | 2020-04-14 |

| Sertaç Özercan | @sozercan | sozercan@... | Microsoft | gatekeeper, gatekeeper-library | 2020-04-14 |

| Tim Hinrichs | @timothyhinrichs | timothy.l.hinrichs@... | Styra | all repositories | 2020-04-14 |

| Torin Sandall | @tsandall | torinsandall@... | Styra | all repositories | 2020-04-14 |

We also have non-voting folks w/ write access on certain repos, which is valuable for onboarding



new contributors to admin the project on a day-to-day basis w/o inheriting full voting rights that are essentially a conflict resolution mechanism for when other attempts to reach consensus fail. Here's a summary of contributor organizations w/ write across across major repos under the open-policy-agent org:

* open-policy-agent/conftest - DataWorkz, Plex, Red Hat,Snyk, Styra
* open-policy-agent/frameworks - Google, Microsoft, Styra
* open-policy-agent/gatekeeper - Google, Microsoft, Styra
* open-policy-agent/gatekeeper-library - Google, Microsoft, Styra
* open-policy-agent/opa - Styra
* open-policy-agent/opa-envoy-plugin - Styra

We're always looking for folks that are interested in making long-term sustained contributions. If you're interested, please get in touch.

On Wed, Sep 16, 2020 at 6:05 PM Torin Sandall <torin@...> wrote:
Hi Maor,

Gatekeeper is not a separate project--it's a part of the OPA project. Microsoft and Google are maintainers of Gatekeeper as well as OPA, meaning all three organizations have the voting rights that go along with maintainership as outlined in our MAINTAINERS.md and GOVERNANCE.md files:

https://github.com/open-policy-agent/opa/blob/master/GOVERNANCE.md
https://github.com/open-policy-agent/opa/blob/master/MAINTAINERS.md

As far as plans for more organizations go, we have a governance process defined that outlines how new maintainers can be added. It requires a proposal from an existing maintainer and a vote from the other maintainers. That would likely occur after someone has made sustained contributions over a period of time. Note, the governance model allows for individuals to be granted permission to admin repos on GitHub without being granted full voting rights to onboard external efforts within OPA (this is how open-policy-agent/conftest is currently managed.)

-Torin

On Wed, Sep 16, 2020 at 5:03 PM Maor Goldberg <maor@...> wrote:
Hey,

Great news and congratulations to the OPA team, great project and a cornerstone for the cloud native enterprise. 

Looking at the maintainer status on the project, I wonder if there’s a plan to add more organizations?
I believe there’s only one organization (Styra) with maintainer status on the OPA project while Google and Microsoft only maintain the Gatekeeper project (my understanding is that Gatekeeper is a separate project). 

I think it will be great to see more than one organization sharing responsibility and leadership for this important project.

Good luck,
Maor. 


<PastedGraphic-1.tiff>




On Sep 16, 2020, at 10:46 AM, Brendan Burns via lists.cncf.io <bburns=microsoft.com@...> wrote:

Folks

The OPA project has applied for graduation from incubation to graduated. (https://github.com/cncf/toc/pull/520)


The public comment period is now open for 2 weeks, and all SIGs, end users, TOC members, and community members are welcome to comment by replying to this thread.

Brendan Burns








--
-Torin




--
-Torin

























--
-Torin














--
-Torin




--
-Torin


Saad Ali
 

Got it. Since, 4/8 maintainers are from a single organization and changes require 2/3 majority, does that mean a single organization could effectively veto any changes?

On Fri, Sep 18, 2020 at 2:05 PM Torin Sandall <torin@...> wrote:
What does "all areas of expertise" mean? Does it mean all the folks in https://github.com/open-policy-agent/opa/blob/master/MAINTAINERS.md ?

Yes, any maintainer, regardless of their area of expertise (e.g., a specific repo or subtree) would vote.

On Fri, Sep 18, 2020 at 4:18 PM Saad Ali <saadali@...> wrote:
Thank you for the clarification Torin!

On Fri, Sep 18, 2020 at 11:41 AM Torin Sandall via lists.cncf.io <torin=styra.com@...> wrote:
Hi Liz,

To your comment, the OPA governance model protects against one organization unfairly controlling any part of the project (including the open-policy-agent/opa repository) by allowing any maintainer (from any repository) to call for an update to the model (this is covered by the "Changes in Governance" section).

The governance doc says "All changes in Governance require a 2/3 majority organization vote from all areas of expertise."
What does "all areas of expertise" mean? Does it mean all the folks in https://github.com/open-policy-agent/opa/blob/master/MAINTAINERS.md ?

 

The model we have in place balances (i) the desire for experts on a repository to make decisions for that repository and (ii) for the OPA contributor community to take action if one or more organizations starts misbehaving. Sustained contributors for each repository make decisions for what goes into that repository, but if those contributors begin making decisions that are not in the interest of the broader community, the OPA governance model allows maintainers from other repositories to step in and take corrective action. The model is based on the premise that maintainers are acting in the best interest of the community, but it recognizes that exceptions can occur and accounts for that.

https://github.com/open-policy-agent/opa/blob/master/GOVERNANCE.md#changes-in-governance

On Fri, Sep 18, 2020 at 3:27 AM Liz Rice <liz@...> wrote:
I am a big fan of OPA, and in general the project seems to be going well. But it does give me pause to see that open-policy-agent/opa (in particular) is controlled by one organisation 

Liz 

On Fri, 18 Sep 2020 at 00:42, Maor Goldberg <maor@...> wrote:
Thank you for the clarification Torin, appreciate it. 

My intention was to highlight the need and to hopefully encourage other organizations to join and help your team. 
We are participating in the community meetings for a long time now and can only applaud everything that Styra is doing. 

Congratulations and good luck!






On Sep 17, 2020, at 3:07 PM, Torin Sandall via lists.cncf.io <torin=styra.com@...> wrote:

Hi All,

Maor from apolicy.io sent a follow up email asking about organization responsibilities for different repos. This is all covered in the MAINTAINER.md file:
# Maintainers



The following table lists OPA project maintainers and areas of expertise in alphabetical order:



| Name | GitHub | Email | Organization | Repositories/Area of Expertise | Added/Renewed On |

| --- | --- | --- | --- | --- | --- |

| Ash Narkar | @ashutosh-narkar | anarkar4387@... | Styra | opa, opa-istio-plugin | 2020-04-14 |

| Craig Tabita | @ctab | ctab@... | Google | gatekeeper, gatekeeper-library | 2020-04-14 |

| Max Smythe | @maxsmythe | smythe@... | Google | frameworks/constraints, gatekeeper, gatekeeper-library | 2020-04-14 |

| Patrick East | @patrick-east | east.patrick@... | Styra | opa | 2020-04-14 |

| Rita Zhang | @ritazh | rita.z.zhang@... | Microsoft | frameworks/constraints, gatekeeper, gatekeeper-library | 2020-04-14 |

| Sertaç Özercan | @sozercan | sozercan@... | Microsoft | gatekeeper, gatekeeper-library | 2020-04-14 |

| Tim Hinrichs | @timothyhinrichs | timothy.l.hinrichs@... | Styra | all repositories | 2020-04-14 |

| Torin Sandall | @tsandall | torinsandall@... | Styra | all repositories | 2020-04-14 |

We also have non-voting folks w/ write access on certain repos, which is valuable for onboarding



new contributors to admin the project on a day-to-day basis w/o inheriting full voting rights that are essentially a conflict resolution mechanism for when other attempts to reach consensus fail. Here's a summary of contributor organizations w/ write across across major repos under the open-policy-agent org:

* open-policy-agent/conftest - DataWorkz, Plex, Red Hat,Snyk, Styra
* open-policy-agent/frameworks - Google, Microsoft, Styra
* open-policy-agent/gatekeeper - Google, Microsoft, Styra
* open-policy-agent/gatekeeper-library - Google, Microsoft, Styra
* open-policy-agent/opa - Styra
* open-policy-agent/opa-envoy-plugin - Styra

We're always looking for folks that are interested in making long-term sustained contributions. If you're interested, please get in touch.

On Wed, Sep 16, 2020 at 6:05 PM Torin Sandall <torin@...> wrote:
Hi Maor,

Gatekeeper is not a separate project--it's a part of the OPA project. Microsoft and Google are maintainers of Gatekeeper as well as OPA, meaning all three organizations have the voting rights that go along with maintainership as outlined in our MAINTAINERS.md and GOVERNANCE.md files:

https://github.com/open-policy-agent/opa/blob/master/GOVERNANCE.md
https://github.com/open-policy-agent/opa/blob/master/MAINTAINERS.md

As far as plans for more organizations go, we have a governance process defined that outlines how new maintainers can be added. It requires a proposal from an existing maintainer and a vote from the other maintainers. That would likely occur after someone has made sustained contributions over a period of time. Note, the governance model allows for individuals to be granted permission to admin repos on GitHub without being granted full voting rights to onboard external efforts within OPA (this is how open-policy-agent/conftest is currently managed.)

-Torin

On Wed, Sep 16, 2020 at 5:03 PM Maor Goldberg <maor@...> wrote:
Hey,

Great news and congratulations to the OPA team, great project and a cornerstone for the cloud native enterprise. 

Looking at the maintainer status on the project, I wonder if there’s a plan to add more organizations?
I believe there’s only one organization (Styra) with maintainer status on the OPA project while Google and Microsoft only maintain the Gatekeeper project (my understanding is that Gatekeeper is a separate project). 

I think it will be great to see more than one organization sharing responsibility and leadership for this important project.

Good luck,
Maor. 


<PastedGraphic-1.tiff>




On Sep 16, 2020, at 10:46 AM, Brendan Burns via lists.cncf.io <bburns=microsoft.com@...> wrote:

Folks

The OPA project has applied for graduation from incubation to graduated. (https://github.com/cncf/toc/pull/520)


The public comment period is now open for 2 weeks, and all SIGs, end users, TOC members, and community members are welcome to comment by replying to this thread.

Brendan Burns








--
-Torin




--
-Torin























--
-Torin



--
-Torin


Torin Sandall
 

What does "all areas of expertise" mean? Does it mean all the folks in https://github.com/open-policy-agent/opa/blob/master/MAINTAINERS.md ?

Yes, any maintainer, regardless of their area of expertise (e.g., a specific repo or subtree) would vote.


On Fri, Sep 18, 2020 at 4:18 PM Saad Ali <saadali@...> wrote:
Thank you for the clarification Torin!

On Fri, Sep 18, 2020 at 11:41 AM Torin Sandall via lists.cncf.io <torin=styra.com@...> wrote:
Hi Liz,

To your comment, the OPA governance model protects against one organization unfairly controlling any part of the project (including the open-policy-agent/opa repository) by allowing any maintainer (from any repository) to call for an update to the model (this is covered by the "Changes in Governance" section).

The governance doc says "All changes in Governance require a 2/3 majority organization vote from all areas of expertise."
What does "all areas of expertise" mean? Does it mean all the folks in https://github.com/open-policy-agent/opa/blob/master/MAINTAINERS.md ?

 

The model we have in place balances (i) the desire for experts on a repository to make decisions for that repository and (ii) for the OPA contributor community to take action if one or more organizations starts misbehaving. Sustained contributors for each repository make decisions for what goes into that repository, but if those contributors begin making decisions that are not in the interest of the broader community, the OPA governance model allows maintainers from other repositories to step in and take corrective action. The model is based on the premise that maintainers are acting in the best interest of the community, but it recognizes that exceptions can occur and accounts for that.

https://github.com/open-policy-agent/opa/blob/master/GOVERNANCE.md#changes-in-governance

On Fri, Sep 18, 2020 at 3:27 AM Liz Rice <liz@...> wrote:
I am a big fan of OPA, and in general the project seems to be going well. But it does give me pause to see that open-policy-agent/opa (in particular) is controlled by one organisation 

Liz 

On Fri, 18 Sep 2020 at 00:42, Maor Goldberg <maor@...> wrote:
Thank you for the clarification Torin, appreciate it. 

My intention was to highlight the need and to hopefully encourage other organizations to join and help your team. 
We are participating in the community meetings for a long time now and can only applaud everything that Styra is doing. 

Congratulations and good luck!






On Sep 17, 2020, at 3:07 PM, Torin Sandall via lists.cncf.io <torin=styra.com@...> wrote:

Hi All,

Maor from apolicy.io sent a follow up email asking about organization responsibilities for different repos. This is all covered in the MAINTAINER.md file:
# Maintainers



The following table lists OPA project maintainers and areas of expertise in alphabetical order:



| Name | GitHub | Email | Organization | Repositories/Area of Expertise | Added/Renewed On |

| --- | --- | --- | --- | --- | --- |

| Ash Narkar | @ashutosh-narkar | anarkar4387@... | Styra | opa, opa-istio-plugin | 2020-04-14 |

| Craig Tabita | @ctab | ctab@... | Google | gatekeeper, gatekeeper-library | 2020-04-14 |

| Max Smythe | @maxsmythe | smythe@... | Google | frameworks/constraints, gatekeeper, gatekeeper-library | 2020-04-14 |

| Patrick East | @patrick-east | east.patrick@... | Styra | opa | 2020-04-14 |

| Rita Zhang | @ritazh | rita.z.zhang@... | Microsoft | frameworks/constraints, gatekeeper, gatekeeper-library | 2020-04-14 |

| Sertaç Özercan | @sozercan | sozercan@... | Microsoft | gatekeeper, gatekeeper-library | 2020-04-14 |

| Tim Hinrichs | @timothyhinrichs | timothy.l.hinrichs@... | Styra | all repositories | 2020-04-14 |

| Torin Sandall | @tsandall | torinsandall@... | Styra | all repositories | 2020-04-14 |

We also have non-voting folks w/ write access on certain repos, which is valuable for onboarding



new contributors to admin the project on a day-to-day basis w/o inheriting full voting rights that are essentially a conflict resolution mechanism for when other attempts to reach consensus fail. Here's a summary of contributor organizations w/ write across across major repos under the open-policy-agent org:

* open-policy-agent/conftest - DataWorkz, Plex, Red Hat,Snyk, Styra
* open-policy-agent/frameworks - Google, Microsoft, Styra
* open-policy-agent/gatekeeper - Google, Microsoft, Styra
* open-policy-agent/gatekeeper-library - Google, Microsoft, Styra
* open-policy-agent/opa - Styra
* open-policy-agent/opa-envoy-plugin - Styra

We're always looking for folks that are interested in making long-term sustained contributions. If you're interested, please get in touch.

On Wed, Sep 16, 2020 at 6:05 PM Torin Sandall <torin@...> wrote:
Hi Maor,

Gatekeeper is not a separate project--it's a part of the OPA project. Microsoft and Google are maintainers of Gatekeeper as well as OPA, meaning all three organizations have the voting rights that go along with maintainership as outlined in our MAINTAINERS.md and GOVERNANCE.md files:

https://github.com/open-policy-agent/opa/blob/master/GOVERNANCE.md
https://github.com/open-policy-agent/opa/blob/master/MAINTAINERS.md

As far as plans for more organizations go, we have a governance process defined that outlines how new maintainers can be added. It requires a proposal from an existing maintainer and a vote from the other maintainers. That would likely occur after someone has made sustained contributions over a period of time. Note, the governance model allows for individuals to be granted permission to admin repos on GitHub without being granted full voting rights to onboard external efforts within OPA (this is how open-policy-agent/conftest is currently managed.)

-Torin

On Wed, Sep 16, 2020 at 5:03 PM Maor Goldberg <maor@...> wrote:
Hey,

Great news and congratulations to the OPA team, great project and a cornerstone for the cloud native enterprise. 

Looking at the maintainer status on the project, I wonder if there’s a plan to add more organizations?
I believe there’s only one organization (Styra) with maintainer status on the OPA project while Google and Microsoft only maintain the Gatekeeper project (my understanding is that Gatekeeper is a separate project). 

I think it will be great to see more than one organization sharing responsibility and leadership for this important project.

Good luck,
Maor. 


<PastedGraphic-1.tiff>




On Sep 16, 2020, at 10:46 AM, Brendan Burns via lists.cncf.io <bburns=microsoft.com@...> wrote:

Folks

The OPA project has applied for graduation from incubation to graduated. (https://github.com/cncf/toc/pull/520)


The public comment period is now open for 2 weeks, and all SIGs, end users, TOC members, and community members are welcome to comment by replying to this thread.

Brendan Burns








--
-Torin




--
-Torin























--
-Torin



--
-Torin


Saad Ali
 

Thank you for the clarification Torin!

On Fri, Sep 18, 2020 at 11:41 AM Torin Sandall via lists.cncf.io <torin=styra.com@...> wrote:
Hi Liz,

To your comment, the OPA governance model protects against one organization unfairly controlling any part of the project (including the open-policy-agent/opa repository) by allowing any maintainer (from any repository) to call for an update to the model (this is covered by the "Changes in Governance" section).

The governance doc says "All changes in Governance require a 2/3 majority organization vote from all areas of expertise."
What does "all areas of expertise" mean? Does it mean all the folks in https://github.com/open-policy-agent/opa/blob/master/MAINTAINERS.md ?

 

The model we have in place balances (i) the desire for experts on a repository to make decisions for that repository and (ii) for the OPA contributor community to take action if one or more organizations starts misbehaving. Sustained contributors for each repository make decisions for what goes into that repository, but if those contributors begin making decisions that are not in the interest of the broader community, the OPA governance model allows maintainers from other repositories to step in and take corrective action. The model is based on the premise that maintainers are acting in the best interest of the community, but it recognizes that exceptions can occur and accounts for that.

https://github.com/open-policy-agent/opa/blob/master/GOVERNANCE.md#changes-in-governance

On Fri, Sep 18, 2020 at 3:27 AM Liz Rice <liz@...> wrote:
I am a big fan of OPA, and in general the project seems to be going well. But it does give me pause to see that open-policy-agent/opa (in particular) is controlled by one organisation 

Liz 

On Fri, 18 Sep 2020 at 00:42, Maor Goldberg <maor@...> wrote:
Thank you for the clarification Torin, appreciate it. 

My intention was to highlight the need and to hopefully encourage other organizations to join and help your team. 
We are participating in the community meetings for a long time now and can only applaud everything that Styra is doing. 

Congratulations and good luck!






On Sep 17, 2020, at 3:07 PM, Torin Sandall via lists.cncf.io <torin=styra.com@...> wrote:

Hi All,

Maor from apolicy.io sent a follow up email asking about organization responsibilities for different repos. This is all covered in the MAINTAINER.md file:
# Maintainers



The following table lists OPA project maintainers and areas of expertise in alphabetical order:



| Name | GitHub | Email | Organization | Repositories/Area of Expertise | Added/Renewed On |

| --- | --- | --- | --- | --- | --- |

| Ash Narkar | @ashutosh-narkar | anarkar4387@... | Styra | opa, opa-istio-plugin | 2020-04-14 |

| Craig Tabita | @ctab | ctab@... | Google | gatekeeper, gatekeeper-library | 2020-04-14 |

| Max Smythe | @maxsmythe | smythe@... | Google | frameworks/constraints, gatekeeper, gatekeeper-library | 2020-04-14 |

| Patrick East | @patrick-east | east.patrick@... | Styra | opa | 2020-04-14 |

| Rita Zhang | @ritazh | rita.z.zhang@... | Microsoft | frameworks/constraints, gatekeeper, gatekeeper-library | 2020-04-14 |

| Sertaç Özercan | @sozercan | sozercan@... | Microsoft | gatekeeper, gatekeeper-library | 2020-04-14 |

| Tim Hinrichs | @timothyhinrichs | timothy.l.hinrichs@... | Styra | all repositories | 2020-04-14 |

| Torin Sandall | @tsandall | torinsandall@... | Styra | all repositories | 2020-04-14 |

We also have non-voting folks w/ write access on certain repos, which is valuable for onboarding



new contributors to admin the project on a day-to-day basis w/o inheriting full voting rights that are essentially a conflict resolution mechanism for when other attempts to reach consensus fail. Here's a summary of contributor organizations w/ write across across major repos under the open-policy-agent org:

* open-policy-agent/conftest - DataWorkz, Plex, Red Hat,Snyk, Styra
* open-policy-agent/frameworks - Google, Microsoft, Styra
* open-policy-agent/gatekeeper - Google, Microsoft, Styra
* open-policy-agent/gatekeeper-library - Google, Microsoft, Styra
* open-policy-agent/opa - Styra
* open-policy-agent/opa-envoy-plugin - Styra

We're always looking for folks that are interested in making long-term sustained contributions. If you're interested, please get in touch.

On Wed, Sep 16, 2020 at 6:05 PM Torin Sandall <torin@...> wrote:
Hi Maor,

Gatekeeper is not a separate project--it's a part of the OPA project. Microsoft and Google are maintainers of Gatekeeper as well as OPA, meaning all three organizations have the voting rights that go along with maintainership as outlined in our MAINTAINERS.md and GOVERNANCE.md files:

https://github.com/open-policy-agent/opa/blob/master/GOVERNANCE.md
https://github.com/open-policy-agent/opa/blob/master/MAINTAINERS.md

As far as plans for more organizations go, we have a governance process defined that outlines how new maintainers can be added. It requires a proposal from an existing maintainer and a vote from the other maintainers. That would likely occur after someone has made sustained contributions over a period of time. Note, the governance model allows for individuals to be granted permission to admin repos on GitHub without being granted full voting rights to onboard external efforts within OPA (this is how open-policy-agent/conftest is currently managed.)

-Torin

On Wed, Sep 16, 2020 at 5:03 PM Maor Goldberg <maor@...> wrote:
Hey,

Great news and congratulations to the OPA team, great project and a cornerstone for the cloud native enterprise. 

Looking at the maintainer status on the project, I wonder if there’s a plan to add more organizations?
I believe there’s only one organization (Styra) with maintainer status on the OPA project while Google and Microsoft only maintain the Gatekeeper project (my understanding is that Gatekeeper is a separate project). 

I think it will be great to see more than one organization sharing responsibility and leadership for this important project.

Good luck,
Maor. 


<PastedGraphic-1.tiff>




On Sep 16, 2020, at 10:46 AM, Brendan Burns via lists.cncf.io <bburns=microsoft.com@...> wrote:

Folks

The OPA project has applied for graduation from incubation to graduated. (https://github.com/cncf/toc/pull/520)


The public comment period is now open for 2 weeks, and all SIGs, end users, TOC members, and community members are welcome to comment by replying to this thread.

Brendan Burns








--
-Torin




--
-Torin























--
-Torin


Torin Sandall
 

Hi Liz,

To your comment, the OPA governance model protects against one organization unfairly controlling any part of the project (including the open-policy-agent/opa repository) by allowing any maintainer (from any repository) to call for an update to the model (this is covered by the "Changes in Governance" section).

The model we have in place balances (i) the desire for experts on a repository to make decisions for that repository and (ii) for the OPA contributor community to take action if one or more organizations starts misbehaving. Sustained contributors for each repository make decisions for what goes into that repository, but if those contributors begin making decisions that are not in the interest of the broader community, the OPA governance model allows maintainers from other repositories to step in and take corrective action. The model is based on the premise that maintainers are acting in the best interest of the community, but it recognizes that exceptions can occur and accounts for that.

https://github.com/open-policy-agent/opa/blob/master/GOVERNANCE.md#changes-in-governance


On Fri, Sep 18, 2020 at 3:27 AM Liz Rice <liz@...> wrote:
I am a big fan of OPA, and in general the project seems to be going well. But it does give me pause to see that open-policy-agent/opa (in particular) is controlled by one organisation 

Liz 

On Fri, 18 Sep 2020 at 00:42, Maor Goldberg <maor@...> wrote:
Thank you for the clarification Torin, appreciate it. 

My intention was to highlight the need and to hopefully encourage other organizations to join and help your team. 
We are participating in the community meetings for a long time now and can only applaud everything that Styra is doing. 

Congratulations and good luck!






On Sep 17, 2020, at 3:07 PM, Torin Sandall via lists.cncf.io <torin=styra.com@...> wrote:

Hi All,

Maor from apolicy.io sent a follow up email asking about organization responsibilities for different repos. This is all covered in the MAINTAINER.md file:
# Maintainers



The following table lists OPA project maintainers and areas of expertise in alphabetical order:



| Name | GitHub | Email | Organization | Repositories/Area of Expertise | Added/Renewed On |

| --- | --- | --- | --- | --- | --- |

| Ash Narkar | @ashutosh-narkar | anarkar4387@... | Styra | opa, opa-istio-plugin | 2020-04-14 |

| Craig Tabita | @ctab | ctab@... | Google | gatekeeper, gatekeeper-library | 2020-04-14 |

| Max Smythe | @maxsmythe | smythe@... | Google | frameworks/constraints, gatekeeper, gatekeeper-library | 2020-04-14 |

| Patrick East | @patrick-east | east.patrick@... | Styra | opa | 2020-04-14 |

| Rita Zhang | @ritazh | rita.z.zhang@... | Microsoft | frameworks/constraints, gatekeeper, gatekeeper-library | 2020-04-14 |

| Sertaç Özercan | @sozercan | sozercan@... | Microsoft | gatekeeper, gatekeeper-library | 2020-04-14 |

| Tim Hinrichs | @timothyhinrichs | timothy.l.hinrichs@... | Styra | all repositories | 2020-04-14 |

| Torin Sandall | @tsandall | torinsandall@... | Styra | all repositories | 2020-04-14 |

We also have non-voting folks w/ write access on certain repos, which is valuable for onboarding



new contributors to admin the project on a day-to-day basis w/o inheriting full voting rights that are essentially a conflict resolution mechanism for when other attempts to reach consensus fail. Here's a summary of contributor organizations w/ write across across major repos under the open-policy-agent org:

* open-policy-agent/conftest - DataWorkz, Plex, Red Hat,Snyk, Styra
* open-policy-agent/frameworks - Google, Microsoft, Styra
* open-policy-agent/gatekeeper - Google, Microsoft, Styra
* open-policy-agent/gatekeeper-library - Google, Microsoft, Styra
* open-policy-agent/opa - Styra
* open-policy-agent/opa-envoy-plugin - Styra

We're always looking for folks that are interested in making long-term sustained contributions. If you're interested, please get in touch.

On Wed, Sep 16, 2020 at 6:05 PM Torin Sandall <torin@...> wrote:
Hi Maor,

Gatekeeper is not a separate project--it's a part of the OPA project. Microsoft and Google are maintainers of Gatekeeper as well as OPA, meaning all three organizations have the voting rights that go along with maintainership as outlined in our MAINTAINERS.md and GOVERNANCE.md files:

https://github.com/open-policy-agent/opa/blob/master/GOVERNANCE.md
https://github.com/open-policy-agent/opa/blob/master/MAINTAINERS.md

As far as plans for more organizations go, we have a governance process defined that outlines how new maintainers can be added. It requires a proposal from an existing maintainer and a vote from the other maintainers. That would likely occur after someone has made sustained contributions over a period of time. Note, the governance model allows for individuals to be granted permission to admin repos on GitHub without being granted full voting rights to onboard external efforts within OPA (this is how open-policy-agent/conftest is currently managed.)

-Torin

On Wed, Sep 16, 2020 at 5:03 PM Maor Goldberg <maor@...> wrote:
Hey,

Great news and congratulations to the OPA team, great project and a cornerstone for the cloud native enterprise. 

Looking at the maintainer status on the project, I wonder if there’s a plan to add more organizations?
I believe there’s only one organization (Styra) with maintainer status on the OPA project while Google and Microsoft only maintain the Gatekeeper project (my understanding is that Gatekeeper is a separate project). 

I think it will be great to see more than one organization sharing responsibility and leadership for this important project.

Good luck,
Maor. 


<PastedGraphic-1.tiff>




On Sep 16, 2020, at 10:46 AM, Brendan Burns via lists.cncf.io <bburns=microsoft.com@...> wrote:

Folks

The OPA project has applied for graduation from incubation to graduated. (https://github.com/cncf/toc/pull/520)


The public comment period is now open for 2 weeks, and all SIGs, end users, TOC members, and community members are welcome to comment by replying to this thread.

Brendan Burns








--
-Torin




--
-Torin























--
-Torin