[Pilot] Security Self-Assessment of a sub-project of a graduated CNCF project

[PushkarJ]

Description: Revisit security assessment process to include the assessment of sub-projects of graduated projects by using Cluster API sub-project of Kubernetes as a pilot

Impact: This will create precedence on what role CNCF SIG Security can play to perform a security evaluation of sub-projects of graduated projects where there may or may not be separate working group or a SIG focussed on the sub-project and security. For example in our pilot, cluster-api in k/k, we have a SIG cluster-lifecycle focussed on cluster-api project and sig-security focussed on overall security of kubernetes project.

Scope: Complete an end to end pilot, revise security assessment process after completion of pilot.

• SIG Representative: @rficcaglia cc @TheFoxAtWork
• Project leader(s): @PushkarJ (common member of both K8s SIG and CNCF TAG Security)
• SIG-Cluster Lifecycle Representative: @randomvariable , @neolit123,
• SIG-Security Representative: @aladewberry cc @tabbysable
• Define Roles and responsibilities of different SIGs involved in security evaluation
• Assess if conflict of interest policy needs revision
• Perform self-assessment of the sub-project: Cluster API Security Self Assessment kubernetes/sig-security#40
• Retrospective of the Security Self-Assessment Subproject Pilot #957
• Update security assessment guide based on outcome of pilot and retrospective

Optionally, Third party security assessment of sub-project (CNCF SIG Security will be involved only tangentially on this one) <-- this maybe scoped to a future kubernetes wide third party audit, but not scoped in kubernetes/sig-security#13

Previous examples of SIG Security assessments for (non-graduated at the time of review) CNCF projects: https://github.com/cncf/sig-security/tree/master/assessments/projects

Related:
Cluster API tracking issue: kubernetes-sigs/cluster-api#4446
SIG Security tracking issue: kubernetes/sig-security#8

[rficcaglia]

I reread the conflict policy and while it may be somewhat moot for an api sub-project, I think the basic scheme still has merit even for this effort, ie to identify whether someone has a bias that would artificially influence the review positively or negatively. probably more an issue in a case where someone disputed the output or process. That said, If however anyone feels it is too onerous to ask reviewers to complete, I think we should listen to that feedback!

some of the questions are probably in need of review though - being a user or contributor might be considered a good thing, ie I have a vested interest in making sure this project is indeed secure!

To kick things off here is mine:

Hard Conflicts	Y/N
Reviewer is a currently a maintainer of the project	N
Reviewer is direct report of/to a current maintainer of the project	N
Reviewer is paid to work on the project	N
Reviewer has significant financial interest directly ties to the success of the project	N

Soft Conflicts	Y/N
Reviewer belongs to the same company/organization of the project, but does not work on the project	N or (N/A?)
Reviewer uses the project in his/her work	N (not yet but very interested!)
Reviewer has contributed to the project	N (not yet but hope to!)

[rficcaglia]

this was discussed in the SIG call today April 28, 2021 - @pragashj noted that if we (CNCF sig-security) take this on, we may establish a precedent that any/all API sub-projects should/would/could want a similar review. The concern discussed was whether the CNCF sig could handle that load, and also that the CNCF sig mission is more aligned to respond to TOC requests vs. direct requests from projects/sub-projects.

what we discussed is that the materials and methods can easily be forked into Kubernetes sig-security (figuratively, and of course in github, literally!) and adopted as necessary for the Kubernetes sig to manage.

I (as participant in both sigs) see benefits to this approach. I see this SIG's (CNCF sig-security) scope as more high level cloud native, and naturally Kubernetes sig-security has a specific focus on only Kubernetes. Thus k8s sig seems the be an ideal place for api subproject assessments. Also I think the methodology of CNCF sig's assessments/reviews is now more focused on documentation review, which is a necessary and good first step, but the k8s api security needs are much more expansive and more in line with what you would get with a commercial code audit and assessment/pentest. By definition, that would necessarily require far more k8s detailed knowledge and focus.

the downside is of course you have 2 different sigs doing similar things and not collaborating closely. there are several members like myself that do crossover so I think this could be managed and mitigated via active communication across both groups. but there is necessarily going to be points of disjunction, as with all forks.

I invite the community to comment and register their ideas/thoughts/concerns!

[neolit123]

what we discussed is that the materials and methods can easily be forked into Kubernetes sig-security (figuratively, and of course in github, literally!) and adopted as necessary for the Kubernetes sig to manage.

i personally have no right to object to such a decision where the CNCF SIG delegates the Cluster API audit work entirely to the K8s SIG. so as long as the k8s SIG Security leads are in favor of this change and they think their SIG can manage this, SGTM as well.

Thus k8s sig seems the be an ideal place for api subproject assessments

in k8s we have a API Review group and we try to get involvement from them to review the API parts of Cluster API, occasionally.
the project name might be a bit misleading since it does include a number of components, including controllers and CLI tools, which might be the more interesting parts in a security audit.

[TheFoxAtWork]

If CNCF SIG-Security has cycles to support our colleagues and family in K8s SIG-Security as they determine the best path for k8s Sub-projects i think that would be ideal for everyone. If K8s SIG-Security would like to PR the results of their review/assessment to CNCF SIG-Security repo I don't see any issue with this.

Regarding more hands-on assessments - The current security review process listing for "joint-reviews" has a section for audit/pen-test/hands on testing results to go. We currently don't have any templates or instructions specific for executing this other than get consent. If K8s SIG-Security is interesting in testing this out as part of this or another review, we would be delighted to learn how it went and perhaps adopt the practice (provided we have community members who can support it).

I'm very excited about this partnership opportunity with our family SIG!

[rficcaglia]

in k8s we have a API Review group

Thanks @neolit123 Learn something new every day! https://github.com/kubernetes/community/blob/master/sig-architecture/api-review-process.md

[PushkarJ]

It seems there are three topics to get consensus on but largely everyone seems excited about breaking new ground here:

• Who participates in the security assessment? It feels intuitive and natural that folks like @rficcaglia, myself and others who are common members of both SIGs can take that mantle as it will allow for active information sharing / updates, cross pollination and people with deeper knowledge of the project and security in general reviewing it. This pattern also applies for any future such assessments. If other contributors who are not a common member in both Security SIGs would like to shadow / observe they are welcome to join.
• Where does the final artifact land while ensuring separation of duties? The project (e.g. Kubernetes) SIG Security could host the final assessment and cross link it to CNCF SIG repo. CNCF SIG repo can also create a simple markdown doc pointing to the assessment hosted in a project (e.g. kubernetes) SIG Security repo so that we have a single source of truth but people can find relevant info in both SIGs. As merging would need approval for either SIG repos, we will maintain the separation of duties
• Who would do an in-depth assessment including secure code reviews, pen tests, audit: Agree 100% that the project SIG can go deeper and create precedence for other project SIGs to follow. Whatever is the outcome of this exercise can be documented in CNCF SIG repo as a best practice.

Did I miss anything ?

[TheFoxAtWork]

Wanted to check in on where this was at/status

[PushkarJ]

@TheFoxAtWork glad you asked. We discussed briefly on the kubernetes sig-security call last week and are mostly in alignment with past discussions. Few key points:

• We will use kubernetes native mediums of collaboration i.e. slack (sig-security-assess-capi), github(kubernetes/community) repos. This is mainly for ease of use as majority participants are part of those mediums of communication and collaboration already
• The sec. assessment process for cluster api will be inherited from CNCF STAG's and we expect to make adjustments as appropriate and document those
• Final artifacts will reside in kubernetes/community/sig-security and we expect to cross-link these with cncf/tag-security/assessments to ensure appropriate citations are in place
• We also expect to share / present the outcome of this exercise in one of our CNCF STAG meetings for awareness and feedback, which could lead to a markdown report that will reside under this repo of the overall experience (to set precedent) for other graduated projects to follow.

Hope this helps and let me or @rficcaglia know if you have any questions or concerns.

[rficcaglia]

No concerns! We discussed briefly on the kubernetes external audit call with Rey and Craig. Everyone excited to start!!

…

On Wed, May 26, 2021 at 2:34 PM Pushkar Joglekar ***@***.***> wrote: @TheFoxAtWork <https://github.com/TheFoxAtWork> glad you asked. We discussed briefly on the kubernetes sig-security call last week and are mostly in alignment with past discussions. Few key points: - We will use kubernetes native mediums of collaboration i.e. slack (sig-security-assess-capi), github(kubernetes/community) repos. This is mainly for ease of use as majority participants are part of those mediums of communication and collaboration already - The sec. assessment process for cluster api will be inherited from CNCF STAG's and we expect to make adjustments as appropriate and document those - Final artifacts will reside in kubernetes/community/sig-security and we expect to cross-link these with cncf/tag-security/assessments to ensure appropriate citations are in place - We also expect to share / present the outcome of this exercise in one of our CNCF STAG meetings for awareness and feedback, which could lead to a markdown report of the overall experience (to set precedent) for other graduated projects to follow that will reside under this repo. Hope this helps and let me or @rficcaglia <https://github.com/rficcaglia> know if you have any questions or concerns. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#603 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGENIQ4K654M4DHISDE3ZTTPVSMZANCNFSM43VUD6RA> .

[TheFoxAtWork]

Fantastic! Really looking forward to this!

[rficcaglia]

latest activity - not sure if this gets automatically cross-tracked by github so this might be superfluous

https://github.com/kubernetes/community/issues/5814#issuecomment-877692924

[TheFoxAtWork]

Folx - wanted to checkin here to see if we need to update the issue details, i saw the soft date of Jan 2022.
Couple items

1. does k8s sig-security propose changes to the conflict of interest based on feedback from earlier?
2. are there any initial insights/recommendations?

[sunstonesecure-robert]

we would need the chairs (@tabbysable) to weigh in on the conflict of interest declaration. since I added it into the original SAFE process way back when, I definitely like it :) I think it's good to be transparent.

re: 2 - nothing has kicked off as yet - unless you consider that we had a discussion today with a community member (mattias luft) @ Salesforce who presented their control plane audit which is highly reusable for the CAPI effort. Also @raesene 's presentation of attack trees using https://www.deciduous.app/ was great! I think we will use that! I had manually done something similar for cloud custodian, which I will never do manually again :)

[randomvariable]

(CAPI project contributor here)

On 2:
There was a kick off meeting a few weeks ago.

We're ( @Ankitasw and me) working on creating the documentation and data flow diagrams such that reviewers can be useful for an initial review in October.

[randomvariable]

On 1: I don't have any particular comments. It seems good to have that conflict of interest declaration. I think the only potential one is that @PushkarJ would count as:

Reviewer belongs to the same company/organization of the project, but does not work on the project

[PushkarJ]

My point of view on conflict of interest, is to classify this type of exercise that is done within the confines of a CNCF project, to be a self-assessment where reviewers/assessors partner with maintainers instead of two separate parties, the key word being "self".

A third party assessment like the one we do for Kubernetes project would be a logical next step for sub-projects after that, which of course will have stricter conflict of interest requirements. Hope that makes sense. Happy to discuss more here or in one of our CNCF weekly calls too :-)

[PushkarJ]

@rficcaglia and @randomvariable: Thank you for covering the current state already!!

[TheFoxAtWork]

@PushkarJ your call out on the self-assessment versus joint is a great one.

[PushkarJ]

Added a new issue #957 for retrospective as the pilot security self-assessment is now complete.

[anvega]

This project is coming to a conclusion as retrospective is currently being written.

[anvega]

kubernetes/sig-security#8 completed