 Hello everyone, I'm Tabitha Sable from Kubernetes 6 Security. During the day, I work at Datadog. Hi, my name is Ian Coldwater, co-chair of Kubernetes 6 Security along with Tabitha. During the day, I work at Twilio. And we are the co-chairs of Kubernetes 6 Security, which is a new SIG to the Kubernetes project. We're new, we're super excited to be here, and we would like to tell you about us. So where did the SIG come from? What's up with this? Why now? What are we doing? Let's talk about it. So SIG security evolved from the third-party security audit working group. The original founders of the SIG, who were the people who ran the working group, recognized that more could be done to promote security in Kubernetes across the project and over time. So they decided that expanding the working group into a SIG would be one way to help them do that. So they wrote the charter, did all the applications and paperwork, and transitioned the working group into a SIG. They also recognized that it was really important to build community, to establish a successful cross-sig effort, as well as reach out to the external security community and get the external security community involved in the security of the Kubernetes project. They asked us to come help with that because we had experience building communities. We were super excited to do that. So we're here to help build community, hopefully with you. What does the SIG do? One thing we do is to try to foster security knowledge sharing in the Kubernetes project across SIGs and among contributors. We also want to encourage people from the external security community to come get involved in the security of the Kubernetes project. We want to make it a kind of coalition community building effort. And in pursuit of that, we've built our SIG as a community building effort. This is important, both because we think it's important and for historical reasons too. Historically, Kubernetes hasn't really had a place for people who are interested in helping with the security of the project to have a home. Security-minded contributors could traditionally go to SIGAuth or other SIG efforts that kind of had security involvement. And I think part of that was the thought that security affects all parts of the project. And that makes sense. But also that could leave newer contributors confused because they were like, where's the security place where I can go? So one thing SIG security does is helps provide that form for them. One thing Kubernetes has had, historically, is the Product Security Committee. But the Product Security Committee isn't public, so that wasn't really a place where they could go. I can't speak to the Product Security Committee, though, because I'm not on it, but Tadatha is. I'm delighted to report that another service that we can provide to the Kubernetes community is to offer up our Slack channels and scheduled meeting times and eyes and ears as a public forum for the Product Security Committee. So, of course, most of the work that's done day to day by the PSC has to be private by necessity because of the nature of the work. As the PSC, we are really here to serve Kubernetes as a community and as a software development project. And so while the work may be private, the planning that goes into how the work should be done, how the work should be prioritized, how we should interact with the rest of the project, really should be a community project. And before SIG Security, getting that sort of community input to drive the PSC's direction was a lot harder. But now, when the PSC has concerns, they can bring it to the broader part of the security community by coming to SIG Security. We believe that building community rather than being non-technical actually helps technical excellence because when people work better together, people can build better systems together. When people are communicating with one another, things that might be missed if people were in silos are more likely to be seen. So we've really built this SIG on purpose as a community forum, as a community building thing so that people can come together across SIGs and outside of the community and the project to be able to work together to help build Kubernetes up better. So we want to encourage SIGs and contributors to work together beyond security issues by security people because we don't actually think that those silos are what we need. We think that increased collaboration means a better outcome for everybody and that's a big reason of why we're here. And we have built our group that way on purpose. When there are issues that people see that they believe are security relevant within the Kubernetes project, they can come bring them to SIG Security and bring their ideas, bring themselves, bring their input, and then we can all look at it together as a community and try to figure out what we can do to help. We can also encourage SIGs to talk to one another. One example of this is our work with SIGAuth on the pod security policy replacement effort. Tabby, you want to talk more about that? Yeah, yeah, absolutely. So pod security policy has been a feature in Kubernetes for a very, very long time. If I remember correctly, it first had its alpha release in 1.3 and from the beginning, pod security policy evolved over time as Kubernetes evolved as the pod specification evolved. And so as that evolution happened, it became more and more apparent to users and to SIGAuth who were taking care of it that pod security policy needed some love. But it was really difficult for it to find the love that it needed and to really get a good concrete way to move it forward beyond these limitations. So we wanted to help with that. We brought ourselves to SIGAuth and we heard what their concerns were. And so then we applied the experience that we have as Kubernetes end users to writing a proposal for a replacement for pod security policy. Tim Alcler from SIGAuth wrote another proposal that was different but working to address the same kinds of concerns. Then together with Tim, we were able to bring both of those proposals to the community in SIG security, to the community in SIGAuth and really iterate on both of those proposals together with all of those community groups. You know, this resulted in the creation of a temporary spin-off meeting for iterating on these ideas. And people really responded wonderfully. The both proposals improved really dramatically as a result of the input that all of the folks from SIG security and SIGAuth and from the broader Kubernetes community put into them. Eventually, Jordan and Tim synthesized those two proposals into yet another proposal that combined the strengths of both with, you know, getting rid of most of the limitations of both as well. And that's the proposal that has moved forward into the cap that you're able to see today. And we think that that kind of collaboration between different groups of people was really key to how we were able to get from a difficult problem that had eluded us for quite a while to a concrete potential solution that addresses a lot of people's concerns in a relatively short period of time. We all focused our energy together on it. Speaking of doing things together, another thing that we do is we help encourage new leaders in Kubernetes by encouraging people to come with their ideas and start subgroups if there are people who are excited about implementing these ideas. Two subgroups that we have going, which are really awesome right now, are the subgroup for security docs and the subgroup for the security audit. And we're going to hear from two of the leaders of those subgroups talking about their work there. But first, I think Tabby wanted to talk a little bit about what's going on with security docs and some of the things that SIG Security is involved with helping them with too. Yeah, yeah, SIG Security docs has been doing some great work picking up some efforts that had been taking place previously in SIG docs and some other efforts that had really been a twinkle in various contributor's eyes by providing a place for all of those things to take care of. I think Savita will actually do a better job of explaining it than I will. So I'll leave it to her. My name is Savita and I am going to talk about the subproject SIG Security documentation today. So what do we do there? We work on improving the overall security documentation in the Kubernetes website and we do it by going through the existing content and adding supplementary security guides and tutorials. We look through the examples and make sure they have the right security context in them. If not, we create a PR and fix it. We also remove the old and deprecated security content from the website. One of the major goals of this subproject is to create a platform for new and existing contributors to come together and talk about their passionate security topics and share and learn together. The beauty of this subproject in creating all these guides, examples is that all the content spans around various special interest groups and thereby it brings people together. It creates a medium for collaboration and it also pays way for continuous improvement in the form of good reviews and feedback. This is also a good place for someone who is starting out who wants to know and learn about Kubernetes. They can do that slowly and steadily. For example, there is a new contributor who wants to improve an example in a persistent volume page. They can do that by start talking to six security, six documentation, six cloud provider, six storage mainly, and so on. There could be more six involved but these are just examples. They can, by doing this, they will get some more knowledge around this area and they can grow from there. If these things are interesting to you and you want to contribute here so you can do it, we are working on a Kubernetes hardening guide that is targeted towards the cluster operators and it will help them secure the cluster when they are provisioning it. This can be treated like a best practices guide. We have identified various subsections in this guide and we are looking for contributors who can pick a section or two and start discussions and eventually create a PR for their subsection. I want to give a special shout out to Rory and make him for putting this guide and the base structure together. Thank you, Rory. If you are a new contributor and want to learn and you want to participate in the discussions, you can do that by attending our meetings that happens every first and third Thursdays at 6 p.m. UTC that is 2 p.m. Eastern. And if this time is not right for you and you cannot make it for some reason, we also have a Slack channel say Security Dogs and we encourage asynchronous collaboration so you can stop by there. Say hi, post your topic and discuss away. If you have, there is also another place where you can start contributing to security stop by the Kubernetes website and you can filter through the issues and PRs based on the label security and you can pick an issue or you can review a PR whichever that interest you start discussions provide feedback and in case if you are going through the Kubernetes documentation for your work or for some exam or for your personal reading and you come across a page where security can be improved, we would request you to create a issue in the Kubernetes website tag it with security and if you're interested you can create a PR and someone or the other will be there to review and provide some feedback. This is how you can help us make the Kubernetes security better and better. Thank you everyone. Happy honking. Thanks, Samantha. I'm really excited about the things that our Dock sub-project is doing and I'm really excited about the way that we are all working together to help level up contributors. People who are newer people who are learning and people who want to come be future leaders in the project. I'm really excited that we're able to do this and with a security lens I think it's really great work and I'm so glad that it's happening. I'm really excited about the hardening guide too. So another thing that is happening on an ongoing basis is the third-party security audit. As we said earlier SIG Security came out of the third-party security working group and that is a thing that the CNCF is having happen on a cyclical ongoing basis. Right now, as a recording time we have a request for proposals open for vendors who want to be involved in that process but actually I bet I can't speak to this as well as Aaron can so I'm going to throw this to Aaron. Take it away. My name is Aaron Small. Ian and Tabitha asked me to join them and give a brief update on what's going on with the third-party security audit. So our job in short is to facilitate a third-party vendor to come in and perform a security assessment of Kubernetes, help them find vulnerabilities and get them fixed. We're also looking to find these horizontal architectural choices that exist across Kubernetes that may be hindering our security generically and get those fixed as well though those tend to resolve over much longer timelines. And finally we're looking to engage the broader security community. When you publish findings on an audit that's this large and this visible what can happen is what we're hoping happens is independent researchers around the world look at what you've done look at your findings and think to themselves I think I could have done better or I don't think you went far enough or I think you missed something really important and then we can take all that interest and all that excitement and we can funnel it right back into the public bug money program get those researchers paid and make Kubernetes more secure. So this year we're focusing all of our research on this list of components. The last audit we ran in 2019 spent a lot of energy on threat modeling and understanding the relationships between components and how threats might propagate through the environment. We've selected this list because we think they're really critical from a security standpoint and we didn't pick every component because we need to strike a balance between breadth and depth. If you don't go broad enough then you don't build confidence that you've looked in all the right places and if you don't go deep enough then you're not going to find the really critical stuff. You spend an hour looking at a component you might find a surface level vulnerability but if you spend much more time on that component you might find the one that is business ending for someone who uses Kubernetes. So we want to go deep enough to find the good stuff. As we go through the process of evaluating these components adjacent stuff is going to come up we're just going to use the public bug bounty program scope to determine if they're in or out. Rule of thumb would be if it's part of Kubernetes Kubernetes or one of the other repos it's probably in scope but if it's related to a specific deployment technology or related to a specific distribution it's probably out of scope. So as I mentioned before the first third party security out of Kubernetes finished in May of 2019 that audit generated a lot of excitement. We have a talk here people were very interested very engaged and we wanted to channel that into making these audits recurrent making it part of community's process. And we also lobbied for the creation of security which is now up and running and doing really great work. However 2020 was really hard on a lot of members of our community and it slowed us down but we did finally publish our first request for proposal for this audit on February of this year. However we've only received one proposal thus far so I don't think one proposal is sufficient for us to make a good assessment and pick one. So we're excited to relax our timelines a little bit wait for more proposals to come in because we want to focus on having a really high quality audit rather than one that turns around really fast. One of the reasons for this delay appears to be high demand right now in this space. Personally I can attest and other people on the subproject have mentioned that they're having a hard time getting a vendor engagement on audits even for smaller corporate projects. So we'll relax our dates we'll get in the proposals we'll select one our selection criteria by the way is all public as is our evaluation of the proposals from last audit and the final proposal that we did eventually accept all this is available on the GitHub repo. Anyway once the RFP closes and we select the proposal we're going to need to come back out to the community and ask for your help. So the reason we need your help is really simple communities is really big and moving really fast. We have 6.2 million lines of code when I ran that command right before I recorded this and also about 240 commits one week in February. That's big and that's fast and it's not reasonable for us to expect a vendor to come in and know right where to start and how to dive in. We are selecting for vendors that have experience in the space experience with Kubernetes experience with open source projects but we need more depth than that. So the subproject members will be facilitating interviews with leaders around the Kubernetes project. SIG owners people who have been here a long time anyone who knows where the bad code is we're going to want to talk to and point the researchers where their time is most valuable. After these interviews and potentially with some overlap they'll go about the process of building out an environment. They'll use this environment for dynamic analysis of a running Kubernetes cluster as well as the static analysis that they'll also do. As this process is ongoing vulnerabilities will start to come out and we're going to take these vulnerabilities and send them straight to the product security council following their standard disclosure process. We won't be disclosing them as they come out to the public though at the end of the audit we are going to take all of the findings all of the research and all of the the writings that come out of it and share them publicly just like we did last time. Though there may be some delay if there's a disclosure timeline we need to follow for the safety of Kubernetes. We're looking for more help we're looking for more engagement on this. Please come join us in the SIG Security Slack channel. You can also reach out to myself or Ray directly Ray is the chair of this sub project and he'd love to hear from you. I hope to see you there soon. Thank you so much for your time and I'll see you around. Thanks Erin. As Erin said one way that you can get involved with SIG Security is by helping point vendors to the third party security audit if you have relationships with anyone in that line of work and there are lots of other ways to get involved with SIG Security too. We really want you to come and bring yourselves your concerns your project ideas things you want to see happen whatever thoughts you've got to our meetings and to our Slack channel we would love to hear from you we would love to have you come get involved because security is everybody's responsibility and the more we work together the better we can make it together. Also while we're on the subject of sub projects our sub projects are born from ideas and people who come to us with these ideas and have people respond to them. Come show up come bring yourself come bring your ideas and come start it. The sky is the limit really security is an enormously wide field there's lots of opportunities for growth lots of work to do we would be so excited for you to come help us do it. Another way What else can we do Tabby? Sorry. Another way that you can that you can participate is with a simple slash command on GitHub. So if you apply the label SIG Security by typing slash SIG Security into an issue or a PR it will label that with our label and by doing that you'll get it on to the list that we review periodically before meetings and then those issues get brought up for the interest of the community and so sometimes that means that there is a huge level of interest and a great deal of attention that gets paid to that issue. So if you have something and you think this seems like it has a security smell to it if you aren't really sure what to do next there one thing that you can do with that is put the SIG Security label on it and I think Ian has something to add here. One thing to note though is if you have found a security vulnerability in in Kubernetes you should not come and bring it to a public GitHub issue or necessarily a public meeting that is what the product security committee is for. We do have a security disclosure process and above bounty so I recommend taking a look at that but if you have kind of security topics that can be spoken about publicly we would love to have you come and speak about them and we would love to hear from you. We're really excited to see you come and get involved come and bring yourself come bring your ideas we want to hear them thanks. Thank you so much for coming and sharing bye. Bye.