Date   

Re: FOSS Governance Library

Chris Aniszczyk
 

This is great! 

Here's another solid resource that we put together last year that covers the "openness of projects" along with some criteria to look at.

On Tue, Sep 29, 2020 at 11:36 AM Matt Farina <matt@...> wrote:
Since we have been talking governance, I just noticed a new catalog of FOSS Governance documents launched. It's at https://fossgovernance.org/. It has pointers to many governance docs on many open source projects.

Cheers,
Matt



--
Chris Aniszczyk (@cra) | +1-512-961-6719


FOSS Governance Library

Matt Farina
 

Since we have been talking governance, I just noticed a new catalog of FOSS Governance documents launched. It's at https://fossgovernance.org/. It has pointers to many governance docs on many open source projects.

Cheers,
Matt


Re: OPA to graduation

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


Agenda for TOC meeting for 9/29

Amye Scavarda Perrin
 

Hi all, 
We'll be meeting tomorrow at 8am Pacific, discussing graduation requirements around maintainer diversity. 



Thanks! 
-- amye 
--
Amye Scavarda Perrin | Program Manager | amye@...


Re: OPA to graduation

alexis richardson
 

Something something "doomed to reinvent lisp"...

+1, nb


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

+1 NB

 

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

 

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

 

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

 

Joe

 

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

+1 NB

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

I wanted to address the point above about Rego.

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

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

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

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

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

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

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

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

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

Gareth





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





Re: [RESULT] Emily Fox approved as co-chair for SIG Security

Santiago Torres Arias <santiago@...>
 

Congratulations, Emily!

On Mon, Sep 28, 2020 at 08:00:00AM -0700, Amye Scavarda Perrin wrote:
Emily Fox for SIG Security Chair:
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5303&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=cvOXQnL0uHd74hDyDWOe0iZEsP9S1ZpVsppc8T3glVw&e=

+1 Binding
7/10
Justin Cormack: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5312&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=6KQ1-f9Qvp8lvp7Dnek3HBZstjYYKfStdGKl5o_i5Ok&e=
Michelle Noorali: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5315&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=04IZ3omAAWlw-JHaDqfsb4JdiqPMRaw3dC5ZlzuvsOE&e=
Liz Rice: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5318&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=9U4PNNfAolse9EAB8_omh3CquTnAwt3YcYPDYgHpW4k&e=
Alena Prokharchyk: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5319&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=zZKRzCO4AxhiTQp1jPX3pB-yRja2YHy7_JTEGAGf-a8&e=
Katie Gamanji: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5325&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=MWg6pjA2b84djDnWe8icF7t4cyk8_moubqjUDkwNWdY&e=
Saad Ali: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5326&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=6andbIBlUzi2azRgy9IMRV8XE0FThjPrtUtBxJVQRmo&e=
Matt Klein: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5327&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=wayaW7SMvyJSwgvdHEF2adUjgYcwY8GGeVyGj7BxMro&e=

+1 NB
Justin Cappos https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5304&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=VgDz3A2vY0X9uu-FtyYvpLLBu40Z1YyBFpT3gr5IYm0&e=
Brandon Lum: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5305&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=_NXLFJGgnHPNekVKtBnWJ-PyrVBPCZfv7V-tw_BreUs&e=
Chase Pettet:https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5306&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=rXQfIwsfZPgIL6W5QVunCwXtSCTTRFBCqoLzNo5AWac&e=
Paris Pittman: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5307&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=YhRp-Pnu64zHYnjyG7iu5sQVB5-94jE6gecu5V_WWtE&e=
John Hillegass: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5308&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=dKFlVv-NvximxcyfrSHllJUQDAE3SD6nYJKjVp_HKxs&e=
Sarah Allen: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5309&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=_ozh93VFV5t9upw3ZHWLOhy9EdXOU9Y19ghJIp_QgmE&e=
Gadi Naor: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5310&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=hEV8M6oi_ucj7LDSkLXqVa7xAk-psCTsJn-jTjMF8Jk&e=
Frederick Kautz: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5311&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=CZpg03KmYvGx4SZVmfa1q4ycqZtijdQVjn6rj6weWAE&e=
Santiago Torres Arias: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5313&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=3pqvOZcIYtQYTDNAlGW6cZDpD6BOcbjG7FECxDY4t_0&e=
Andrew Martin: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5314&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=zUdOgoorgfkYG_RU0grNuZ-FtUR7HmEQVYsg47ipKXc&e=
Ricardo Aravena: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5316&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=hAn7nQ66xhQo_9G7Ll9jmvp13aexdz43itWcNRpkHqE&e=
Siddharth Bhadri: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5320&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=DBmDhSYdY66kvFj0Sve0CJHprzNq4xvQ3TT6QylVgrU&e=
Ashutosh Narkar: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5321&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=gqSIjvPUb_Ul1jqaPQ4PrTrxW6Fo2MmqFrjAq67XEO8&e=
Andrés Vega: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_g_cncf-2Dtoc_message_5323&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=y-axRZJ21v7kTm0srYiRfw&m=q_tG37s6l_OJRv1yoLi6f1hQ5byOa0iW-1oe6m2Sp1c&s=WIKFfvVmV4Ftavv48jonyHUqj-fx0MOjgCByR1ldYRk&e=

--
Amye Scavarda Perrin | Program Manager | amye@linuxfoundation.org





[RESULT] Emily Fox approved as co-chair for SIG Security

Amye Scavarda Perrin
 


Re: OPA to graduation

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






Re: OPA to graduation

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


Re: OPA to graduation

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





CNCF Awards now open for nominations

Amye Scavarda Perrin
 

We're starting the nomination process for our ambassador, committer and community awards.


  • CNCF Top Ambassador: A champion for the cloud native space, this individual helps spread awareness of the CNCF (and its incubated projects). The CNCF Ambassador leverages multiple platforms, both online as well as speaking engagements, driving interest and excitement around the project.

  • CNCF Top Committer: This will recognize excellence in technical contributions to CNCF and its projects. The CNCF Top Committer has made key commits to projects and, more importantly, contributes in a way that benefits the project neutrally as a whole.

  • CNCF Chop Wood Carry Water: This is given to a community member who helps behind the scenes, dedicating countless hours of their time to open source projects + completing often thankless tasks for the ecosystem’s benefit. The winner of this award will be chosen by the TOC and CNCF Staff.


Nominations will open today, and close on October 16nd. We'll be announcing the awards at KubeCon + CloudNativeCon Virtual North America. Voting (open from October 19 through October 26th) will be performed using the CIVS tool, using emails from the CNCF database for the following groups:

CNCF Ambassadors are eligible to vote for the Top Ambassador
CNCF Maintainers are eligible to vote for the Top Committer


--
Amye Scavarda Perrin | Program Manager | amye@...


Re: [SIG-Security] Nomination of Emily Fox as co-chair

Matt Klein
 

+1

On Mon, Sep 21, 2020 at 4:13 PM Jeyappragash Jeyakeerthi <jj@...> wrote:

Dear Technical Oversight Committee,


Dan Shaw’s term as co-chair of SIG-Security has come to an end.  We would like to nominate Emily Fox as a new co-chair of SIG-Security  (requiring a 2/3rd vote in compliance with the cncf-sig elections process). 


Following are some of Emily’s accomplishments 


Thanks!

JJ in collaboration with other   SIG-Security co-chairs (Dan and Sarah) and TOC Liaisons Liz Rice & Justin Cormack



Re: [SIG-Security] Nomination of Emily Fox as co-chair

Saad Ali
 

+1 binding

Thank you for volunteering!


Re: [SIG-Security] Nomination of Emily Fox as co-chair

Katie Gamanji
 

+1 binding

Exciting times!


On Tue, 22 Sep 2020, 20:44 , <andresvega1@...> wrote:
+1

Emily has gone above and beyond to avail herself as a technical leader to the community. Among many other things, she was instrumental in the review of the SPIFFE/SPIRE security assessment. 

-Andres 


Re: Sandbox Projects included from September 8 TOC meeting

John Belamaric
 

We discussed this in the SIG Architecture meeting today. While generally workload controllers are within scope of the Kubernetes project, it is up to SIG Apps to decide if they are willing to take these on as SIG-sponsored projects. As Matt suggests, it's fine for these to exist as external workload controllers.

With respect to upstreaming, the preference of SIG Arch would be to see individual features move into existing workload controllers as they mature, rather than creation of whole new controllers. The goal here would be to avoid a proliferation of controllers that makes choices very difficult for consumers. Of course, if there is some fundamental difference between the new controller and all existing ones, then a new one may be warranted. But creation of a new one should be done with an abundance of caution. Again this would ultimately be the decision of SIG Apps.

Thanks,
John


On Mon, Sep 21, 2020 at 1:31 PM <szihaI@...> wrote:
The OpenKruise project agree with the Sig App's assessment completely. We, too, believe while up-streaming some of the features to the core workloads is possible, the majority of the controllers and features is best to remain as a separate project.

Best regards,
Andy Shi 


Re: [SIG-Security] Nomination of Emily Fox as co-chair

Andrés Vega
 

+1

Emily has gone above and beyond to avail herself as a technical leader to the community. Among many other things, she was instrumental in the review of the SPIFFE/SPIRE security assessment. 

-Andres 


Keylime accepted into Sandbox

Amye Scavarda Perrin
 

At today's TOC meeting, Keylime passed with a majority of the TOC and is included into Sandbox. 
Welcome Keylime! 

Our next Sandbox review session is November 10th, we'll be reviewing all projects that applied after September 8th. 

--
Amye Scavarda Perrin | Program Manager | amye@...


Re: [SIG-Security] Nomination of Emily Fox as co-chair

Ashutosh Narkar
 

+1 nb, Emily is a great person and I believe she would be an excellent co-chair of Sig-Security.

Thanks
Ash




On Tue, Sep 22, 2020 at 9:01 AM Siddharth Bhadri <sbhadri@...> wrote:

+1 NB

 

Thanks & Regards,

Siddharth Bhadri
Software Engineer

Infoblox | Next Level Networking
sbhadri@...
  |  www.infoblox.com

signature_789707965

 

 

From: <cncf-toc@...> on behalf of "Alena Prokharchyk via lists.cncf.io" <aprokharchyk=apple.com@...>
Reply to: "aprokharchyk@..." <aprokharchyk@...>
Date: Tuesday, 22 September 2020 at 9:29 PM
To: Jeyappragash Jeyakeerthi <jj@...>
Cc: CNCF TOC <cncf-toc@...>
Subject: Re: [cncf-toc] [SIG-Security] Nomination of Emily Fox as co-chair

 

+1 binding, Emily is great! 

 

-alena.



On Sep 21, 2020, at 3:12 PM, Jeyappragash Jeyakeerthi <jj@...> wrote:

 

Dear Technical Oversight Committee,



Dan Shaw’s term as co-chair of SIG-Security has come to an end.  We would like to nominate Emily Fox as a new co-chair of SIG-Security  (requiring a 2/3rd vote in compliance with the cncf-sig elections process). 

 

Following are some of Emily’s accomplishments 

  • As a tech lead and a member of the SIG-Security
    • Cloud Native Security Day Lead (two successful events, upcoming CFP)
    • Defined categories for supply chain compromise catalog PR#304
  • Professional affiliations:
    • DevOps Security Lead, NSA 
  • CNCF Projects: n/a

 

Thanks!

JJ in collaboration with other   SIG-Security co-chairs (Dan and Sarah) and TOC Liaisons Liz Rice & Justin Cormack

 

 


Re: [SIG-Security] Nomination of Emily Fox as co-chair

Siddharth Bhadri
 

+1 NB

 

Thanks & Regards,

Siddharth Bhadri
Software Engineer

Infoblox | Next Level Networking
sbhadri@...
  |  www.infoblox.com

signature_789707965

 

 

From: <cncf-toc@...> on behalf of "Alena Prokharchyk via lists.cncf.io" <aprokharchyk=apple.com@...>
Reply to: "aprokharchyk@..." <aprokharchyk@...>
Date: Tuesday, 22 September 2020 at 9:29 PM
To: Jeyappragash Jeyakeerthi <jj@...>
Cc: CNCF TOC <cncf-toc@...>
Subject: Re: [cncf-toc] [SIG-Security] Nomination of Emily Fox as co-chair

 

+1 binding, Emily is great! 

 

-alena.



On Sep 21, 2020, at 3:12 PM, Jeyappragash Jeyakeerthi <jj@...> wrote:

 

Dear Technical Oversight Committee,



Dan Shaw’s term as co-chair of SIG-Security has come to an end.  We would like to nominate Emily Fox as a new co-chair of SIG-Security  (requiring a 2/3rd vote in compliance with the cncf-sig elections process). 

 

Following are some of Emily’s accomplishments 

  • As a tech lead and a member of the SIG-Security
    • Cloud Native Security Day Lead (two successful events, upcoming CFP)
    • Defined categories for supply chain compromise catalog PR#304
  • Professional affiliations:
    • DevOps Security Lead, NSA 
  • CNCF Projects: n/a

 

Thanks!

JJ in collaboration with other   SIG-Security co-chairs (Dan and Sarah) and TOC Liaisons Liz Rice & Justin Cormack

 

 

901 - 920 of 6235