toggle quoted messageShow quoted text
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.
On Sun, Sep 27, 2020 at 2:10 AM Gareth Rushgrove <gareth@...
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
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
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
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
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
Hopefully that's a useful viewpoint and addition to the conversation.