Tag-security: [Proposal] Pilot sec. assessment of a sub-project of a graduated 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
TO DO

• [x] SIG Representative: @rficcaglia cc @TheFoxAtWork
• [x] Project leader(s): @PushkarJ (common member of both SIG Security)
• [x] SIG-Cluster Lifecycle Representative: @randomvariable , @neolit123
• [x] SIG-Security Representative: @craiglpeters cc @tabbysable
• [x] 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 (Combined effort between k8s sig-security and k8s sig-cluster lifecycle ?)
• [ ] Perform joint review (Combined effort between CNCF SIG Security and K8s SIG Security ?)
• [ ] Optional: Third party security assessment of sub-project (CNCF SIG Security will be involved only tangentially on this one)
• [ ] Perform retrospective of the pilot
• [ ] Update security assessment guide based on outcome of pilot and retrospective

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: https://github.com/kubernetes-sigs/cluster-api/issues/4446

[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
https://github.com/cncf/tag-security/issues/603#issuecomment-849135413,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGENIQ4K654M4DHISDE3ZTTPVSMZANCNFSM43VUD6RA
.

[TheFoxAtWork]

Fantastic! Really looking forward to this!