Re: OPA to graduation


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




Join cncf-toc@lists.cncf.io to automatically receive all group messages.