1. What work did the SIG do this year that should be highlighted?
-
At the time of the 2020 Annual Reports, SIG Security was a very new SIG, just establishing who we are as a group and starting to build a space for security to flourish as a community effort. In 2021, we have come into our own. Since the last annual report, SIG Security has doubled in size, established and matured subprojects that have become welcoming communities of their own, and grown new leaders who have come to lift up more new contributors themselves. We now have generations of contributors working, learning, and honking together.
Our Docs subproject has made Kubernetes security more approachable through blogs and tutorials such as A Closer Look at NSA/CISA Kubernetes Hardening Guidance, Securing Admission Controllers, Apply Pod Security Standards at the Cluster Level, and Apply Pod Security Standards at the Namespace Level.
Our Tooling subproject got off the ground in 2021 and is now flying high, standardizing Kubernetes CVE reporting, prototyping vulnerability scanning of Kubernetes artifacts, and hosting learning sessions which have been viewed hundreds of times.
SIG Security does things differently than a lot of other SIGs. We don’t own code. We work hard to cultivate and grow an inclusive, welcoming environment where everyone, from the newest contributor to the most experienced hacker, can come share their ideas and contribute to the security of the project. This is designed to ripple outward whether or not we are involved, encouraging and facilitating internal collaboration across SIGs and engagement with the external security community. We’re really proud of how far we’ve come, and we’re excited to continue leading by example into 2022 and beyond!
2. What initiatives are you working on that aren't being tracked in KEPs?
-
Most of our work is outside the scope of KEPs. Improving processes, providing ongoing services, and actively building collaboration within the Kubernetes project are all core to what we do. We operate on the basis of consent, communication, and participation–what gets done is based on who shows up, what ideas they bring, and how the rest of the community responds.
Security Self-assessments are a great example of how this works in practice. ClusterAPI maintainers were looking for guidance on evaluating and improving the security of ClusterAPI, and SIG Security members were enthusiastic about helping them. We collaborated with CNCF TAG Security to begin a guided self-assessment exercise for ClusterAPI, adapting TAG Security’s existing self-assessment workflow into a Kubernetes context. Through this process, the participants have gained confidence and experience, word has gotten around, and other Kubernetes subprojects have started asking about their own guided self-assessments. At the time of this writing, Security Self-Assessment is emerging as a likely new SIG Security subproject.
Our Tooling subproject is working to prototype, define policy for, and implement vulnerability scanning for build time dependencies and container images. This initiative involves collaborating with several other SIGs, applying SIG Security’s specialized experience with these tools to produce meaningful improvements without burying other SIGs in additional work.
Our Third-Party Audit subproject continues to administer their namesake initiative. In 2021 they published a Request for Proposals, evaluated the vendor responses, and began to negotiate contract terms with the selected vendor. As of this writing, they have announced the vendor selection and are making arrangements for work to begin.
Our Security Docs subproject works in collaboration with SIG Docs and others on its continuing initiatives: to improve security representation and content in Kubernetes documentation, to communicate information to help end users and others keep themselves safer, and to help foster and grow new contributors. They have been prolifically publishing useful information such as the blog posts shouted out in the beginning of this report, and highlighting good first issues for new contributors to start diving in.
3. KEP work in 2021 (1.21, 1.22, 1.23):
- Stable
- Beta
- Alpha
- Pre-alpha
1. What areas and/or subprojects does your group need the most help with?
- Our Docs subproject is always looking for security-minded contributors of all experience levels to share their learning and knowledge with the community! This subproject has consistently been a place where people merge their first Kubernetes PRs.There’s always room for continuous improvement in our documentation, and contributing to this provides an opportunity to learn more about Kubernetes security while helping everyone run their clusters more safely. We’re really proud of the way Docs encourages and welcomes new contributors, and we’d love to encourage you to become a part of it!
Any areas with 2 or fewer OWNERs? (link to more details)
- The nature of our work means we have little need for OWNERS files, compared to SIGs that ship code. We have two or more OWNERS in all areas, and our community focus helps ensure that when someone needs to scale back their involvement they will be well supported.
2. What metrics/community health stats does your group care about and/or measure?
-
We care about our people. We measure community health by looking at community participation, and seeing how people are feeling. Are people coming to meetings and talking to one another on Slack? How many people are engaged? Is anyone dominating the conversation? Are new contributors becoming involved? Are people coming back?
These types of concerns are notably hard to metricize, which we remain comfortable with.
3. Does your CONTRIBUTING.md help new contributors engage with your group specifically by pointing to activities or programs that provide useful context or allow easy participation?
- We have known for some time that SIG Security needs a CONTRIBUTING.MD document that more accurately reflects how we do things. SIG Security takes a community-building approach to improving Kubernetes security: we intentionally make a space where someone can begin contributing by sharing their thoughts and ideas in a meeting or Slack message. The CONTRIBUTING.MD document we have in progress reflects this. It encourages participation by showing up and links to the general Kubernetes contributor guides, which are still applicable.
4. If your group has special training, requirements for reviewers/approvers, or processes beyond the general contributor guide, does your CONTRIBUTING.md document those to help existing contributors grow throughout the contributor ladder?
- SIG Security does not have special training or requirements for reviewers/approvers. The nature of our cross-SIG work means that we have many fewer PRs, OWNERS files, and similar artifacts than many SIGs. The Kubernetes Contributor Ladder document as currently written focuses on scaling review of numerous code PRs. This limits its immediate applicability to our horizontal SIG, which does not own code and is intentionally built upon open, non-hierarchical community participation. We continue to learn through experience how best to utilize and evolve the contributor ladder to encourage and recognize our leading contributors.
5. Does the group have contributors from multiple companies/affiliations?
- Yes.
6. Are there ways end users/companies can contribute that they currently are not? If one of those ways is more full time support, what would they work on and why?
- End users and people who work at end user companies are contributing broadly within SIG Security today. There are so many possibilities of ways to contribute. As a community we continue to experiment and discover new ways, together. Bring your gifts; come share and learn with us!
- Primary slack channel member count: 890
- Subproject slack channel member counts:
- #sig-security-docs: 260
- #sig-security-tooling: 357
- Primary mailing list member count: 246
- Primary meeting attendee count (estimated, if needed): 13.8
- Primary meeting participant count (estimated, if needed): 13.8
Due to the way we conduct our meetings, at the majority of meetings, everyone participates.
- Unique reviewers for SIG-owned packages: N/A
- Unique approvers for SIG-owned packages: N/A
SIG Security does not own packages.
New in 2021:
Retired in 2021:
- none
Continuing:
New in 2021:
- none
Retired in 2021:
- none
Continuing:
- none
Operational tasks in sig-governance.md:
- README.md reviewed for accuracy and updated if needed
- CONTRIBUTING.md reviewed for accuracy and updated if needed (or created if missing and your contributor steps and experience are different or more in-depth than the documentation listed in the general contributor guide and devel folder.)
- Subprojects list and linked OWNERS files in sigs.yaml reviewed for accuracy and updated if needed
- SIG leaders (chairs, tech leads, and subproject owners) in sigs.yaml are accurate and active, and updated if needed
- Meeting notes and recordings for 2021 are linked from README.md and updated/uploaded if needed
- Did you have community-wide updates in 2021 (e.g. community meetings, kubecon, or kubernetes-dev@ emails)? Links to email, slides, or recordings: