|
+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
|
|
|
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=LhgxFICWsA8Gatekeeper / K8S admission is actually one of the main use cases we still haven't fully integrated (in the works though)!
|
|
|
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/gatekeeper100k+ 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.htmlor 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
toggle quoted message
Show quoted text
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
|
|
|
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?
|
|
|
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
|
|
|
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
+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&data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637367946286664027&sdata=Xf4EZ22F0EdT7e3PHtmBQcNVhfZlmpU%2B0MvddJM8BhE%3D&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&data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637367946286664027&sdata=S6iscJAvXQfHTLLDi6AIbWVwCi89SU3tjbfcAcM%2BzHI%3D&reserved=0)
and Kyverno
(using YAML for authoring
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnirmata%2Fkyverno&data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637367946286664027&sdata=54ow6wTL166eK19uxAi7%2BZZkJ1a3IahR4YKm0RmZGeI%3D&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&data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637367946286674021&sdata=aZZEpTkffy3nbwbuz71hBtK42qAQJtLpssRKNuz2PcI%3D&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&data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637367946286674021&sdata=gbLcPvm0txcoE%2B8QXBl0Tp3cMdL8shHqZML%2FXSk9NbY%3D&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&data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637367946286674021&sdata=dq2gMhiDLnfHxlG3MxDWmeq1DzHjckN%2FfAmoaEvfenQ%3D&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&data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637367946286674021&sdata=BZPQBu4p2GzC7XsfDkvWBH4syELw6eoFCHE581CgFYM%3D&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&data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637367946286674021&sdata=7zQ7z6Zpz%2BFr0%2FEycFdgOMI5aijqgV7Lk8VHpecewoY%3D&reserved=0.
Hopefully that's a useful viewpoint and addition to the conversation.
Gareth
|
|
|
+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&data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637367946286664027&sdata=Xf4EZ22F0EdT7e3PHtmBQcNVhfZlmpU%2B0MvddJM8BhE%3D&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&data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637367946286664027&sdata=S6iscJAvXQfHTLLDi6AIbWVwCi89SU3tjbfcAcM%2BzHI%3D&reserved=0)
and Kyverno
(using YAML for authoring
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnirmata%2Fkyverno&data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637367946286664027&sdata=54ow6wTL166eK19uxAi7%2BZZkJ1a3IahR4YKm0RmZGeI%3D&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&data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637367946286674021&sdata=aZZEpTkffy3nbwbuz71hBtK42qAQJtLpssRKNuz2PcI%3D&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&data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637367946286674021&sdata=gbLcPvm0txcoE%2B8QXBl0Tp3cMdL8shHqZML%2FXSk9NbY%3D&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&data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637367946286674021&sdata=dq2gMhiDLnfHxlG3MxDWmeq1DzHjckN%2FfAmoaEvfenQ%3D&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&data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637367946286674021&sdata=BZPQBu4p2GzC7XsfDkvWBH4syELw6eoFCHE581CgFYM%3D&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&data=02%7C01%7Cjbeda%40vmware.com%7Ced4284f658384fe66e9908d862c52c95%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637367946286674021&sdata=7zQ7z6Zpz%2BFr0%2FEycFdgOMI5aijqgV7Lk8VHpecewoY%3D&reserved=0.
Hopefully that's a useful viewpoint and addition to the conversation.
Gareth
|
|
|
+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,
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
|
|
|
+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.htmlThat 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
|
|
|
-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
I believe similar point about the core-project/heart-of-the-system maintainership is raised on the past graduation proposal
--
Securing Kubernetes & Service Mesh.
Anywhere. Bridging Security & DevOps.
|
|
|
I believe similar point about the core-project/heart-of-the-system maintainership is raised on the past graduation proposal
|
|
|
+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:
On Fri, Sep 18, 2020 at 4:18 PM Saad Ali < saadali@...> wrote: Thank you for the clarification Torin! 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." 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!
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.mdhttps://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:
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>
Folks
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
--
--
--
--
|
|
|
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:
On Fri, Sep 18, 2020 at 4:18 PM Saad Ali < saadali@...> wrote: Thank you for the clarification Torin! 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." 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!
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.mdhttps://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:
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>
Folks
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
--
--
--
--
|
|
|
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:
On Fri, Sep 18, 2020 at 4:18 PM Saad Ali < saadali@...> wrote: Thank you for the clarification Torin! 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." 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!
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.mdhttps://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:
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>
Folks
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
--
--
--
--
|
|
|
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:
On Fri, Sep 18, 2020 at 4:18 PM Saad Ali < saadali@...> wrote: Thank you for the clarification Torin! 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." 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!
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.mdhttps://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:
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>
Folks
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
--
--
--
--
|
|
|
toggle quoted message
Show quoted text
On Fri, Sep 18, 2020 at 4:18 PM Saad Ali < saadali@...> wrote: Thank you for the clarification Torin! 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." 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!
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.mdhttps://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:
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>
Folks
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
--
--
--
|
|
|
Thank you for the clarification Torin! 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." 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!
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.mdhttps://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:
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>
Folks
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
--
--
--
|
|
|
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!
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.mdhttps://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:
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>
Folks
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
--
--
|
|
|
