CNCF SIG-Security charter and roles

[pragashj]

A new repo is created to reflect the work being done by the SIG-Security (previously SAFE)

• Update to reflect the new SIG process
• Governance docs in the in the sig-security repo

[caniszczyk]

Thanks @pragashj, RFC @cncf/toc, we will also cover it in today's TOC meeting

[ghost]

Security is a very broad topic. To help keep focus, I would suggest narrowing down, at least initially, to problem areas that are relatively specific to cloud-native architectures and environments. For example there are many aspects of Authentication, RBAC, ABAC, Confidentiality, Integrity etc that apply to most systems, whether or not they are cloud-native. Adding some references to generic treatments of those areas to your white papers is probably a good idea, but I would steer clear of debating or documenting those general areas in any detail, other than to the extent that traditional approaches might not apply, or not work well, in cloud-native environments.

[pragashj]

Thanks Quinton for the feedback. We will make this clear in the SAFE Charter <https://docs.google.com/document/d/1Yt5IPtN5Mc-FrQDFGUhLpBRePmMAZUA83NbENb69oLs/edit#heading=h.g5qinwik52a6> as well. If you have suggestions for how to word that, please drop a comment there as well.

…

On Tue, Aug 21, 2018 at 11:15 AM Quinton Hoole ***@***.***> wrote: Security is a very broad topic. To help keep focus, I would suggest narrowing down, at least initially, to problem areas that are relatively specific to cloud-native architectures and environments. For example there are many aspects of Authentication, RBAC, ABAC, Confidentiality, Integrity etc that apply to most systems, whether or not they are cloud-native. Adding some references to generic treatments of those areas to your white papers is probably a good idea, but I would steer clear of debating or documenting those general areas in any detail, other than to the extent that traditional approaches might not apply, or not work well, in cloud-native environments. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#146 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AdwPwCsr34j_d-oWcuwp2GsPnNSrRNNlks5uTE4rgaJpZM4WE7zW> .

[ultrasaurus]

I find the objective clarifies the scope of the security work:
"Secure Access for Everyone (SAFE) Working Group will explore secure access, policy control and safety for operators, administrators, developers, and end-users across the cloud native ecosystem."

In helping to draft this the focus is on:

• secure access rather than every possible security concern
• policy control is an attempt to clarify that this is not any kind of configuration, just policies needed to ensure system integrity
• safety is very broad, yet some group members felt strongly that we should strive to evaluate the implications on safety for operators, administrators, developers, and end-users, rather than just reducing risk as was also suggested as more comfortable alternative wording.

In general, I believe the modifier "for operators, administrators, developers, and end-users across the cloud native ecosystem" will help focus the group's work. We may address some concerns for on-prem systems, but only to the degree that is required because of interoperability needs with cloud native systems.

This work grew out of a need from many of us who work on software solutions that provide some key part of a secure system. Of course, there are a number of considerations required to create secure architecture and enforce appropriate controls. Right now the solution space is fragmented, and when we seek to create software that works well with existing and emerging systems, we sometimes need to fall back to pair-wise interoperability and we see opportunities to agree on some critical needs and define common ways to interoperate.

The approach of defining the landscape by listening to people who have cloud native deployments and solutions in this space seems slow to some, yet we have found that this approach helps with alignment by developing a common vocabulary and reference points for group members.

We've defined a some tangible initial output:

• Key Elements of a Trustworthy System
• Cloud Native Policy Architecture
• Container Policy Interface implementations

This reflects the combination of two efforts: the original SAFE community that was formed at KubeCon in Dec '17, and the group that proposed a CNCF Policy WG. We felt that our groups had such overlapping concerns that we needed to work together on this.

I find this group to be helpful to my work at Google, where I became involved in security policy via Firebase Rules, which contributes to OPA, and I also work on infrastructure that supports event-triggered Cloud Functions, helping start CloudEvents, initially as part of the CNCF Serverless WG. We have a lot of problems to solve and I think the SAFE WG will be a good addition to CNCF.

[ghost]

Just to be very clear, the term "cloud native" does not at all imply public cloud only, or exclude on-premise deployments, as is alluded to above by @ultrasaurus .

Here is the CNCF definition of "cloud native":

https://github.com/cncf/toc/blob/master/DEFINITION.md

The part I'm referring to is "... scalable applications in modern, dynamic environments such as public, private, and hybrid clouds".

[ghost]

I would like us to clearly agree upon the written proposed timeline for delivering artifacts (contained in the charter). Both the SAFE WG, and the Policy WG have been around for a year or more and to my knowledge produced very little yet in the form of concrete outputs (please correct me if I'm wrong here). So I think it is important to produce the proposed artifacts, specifically white papers, within the reasonable timeframe proposed (about a quarter per phase) starting now.

[ultrasaurus]

@quinton-hoole , good points,

Few things I think worth clarifying:

1. You are right in the sense that the security technologies aren't necessarily tied to cloud and that should be made clear in the proposal
2. Since we started meetings as a group in Feb of 2018, there have been a few outcomes from the team: use cases, terminologies in security, RBAC vs/and ABAC discussions, Administrators Bill of Rights, participation from NIST to bring in specification views. All these aren't explicitly documented and called out, and are still considered works-in-progress. We are absorbing, learning and contributing as we go. Everyone individually cares about this problem and understands the importance of working together as a group.
3. I agree that dates for deliverables are helpful. We have some in our roadmap and need to fold in new deliverables from merging with Policy WG. Group will pick this up as an activity to be done in the next meeting.

You can find most of our artifacts in the github repo: https://github.com/cn-security/safe, if you want to check out the progress we've made so far, and we're working on migrating various google docs to the repo so the content is a bit more discoverable.

Thanks so much for your feedback!

[hannibalhuang]

@quinton-hoole I think one of the main problem is that the outputs were scattered all over the place and it is hard to gather all at once except for those of us are familiar with it :P As @ultrasaurus mentioned we will try to migrate all the materials/outputs to a place that people would be easy to find. There are a lot of good stuff during almost a year's work :)

[ultrasaurus]

updated per new SIG process with all required documents in the sig-security repo governance docs with links here for CNCF approval

[caniszczyk]

+1 binding TOC votes (7/9):
Alexis: https://lists.cncf.io/g/cncf-toc/message/3304
Brendan: https://lists.cncf.io/g/cncf-toc/message/3315
Matt: https://lists.cncf.io/g/cncf-toc/message/3317
Xiang: https://lists.cncf.io/g/cncf-toc/message/3322
Liz: https://lists.cncf.io/g/cncf-toc/message/3327
Brian: https://lists.cncf.io/g/cncf-toc/message/3328
Joe: https://lists.cncf.io/g/cncf-toc/message/3365