 Y'all are awesome. We appreciate your patience and we appreciate you being here. This is Security Through Transparency, SIG Security Update in the Maintainer Track. If you are here for another talk, you're probably in the wrong room and that's okay, we can all hang out anyway. My name is Ian Coldwater and I am the co-chair of Kubernetes SIG Security and this is... I'm Savita. I lead the SIG Security Documentation Subproject and this is... Yeah, hi, my name is Ray Lohano. I am a field engineer with SUSE by Way Ranch Labs. I'm the sub-project owner for the third-party security audits. I'm also the 1.23 release lead coming out in December. Hi, I'm Pushkar Zobeykar. I am the lead for SIG Security Project Tooling and I work at VMware. So, what is SIG Security? SIG Security is a relatively new SIG in Kubernetes not to be confused with tag security out of the 3NCS and what we do is we are responsible for creating space for people who are interested in contributing to the security of the Kubernetes project to come and discuss security topics with each other, work on deciding the direction of security within the project, what our Kubernetes enhancement proposals will look like, what features go into alpha and beyond and also we help SIGs work together because we are all actually responsible for Kubernetes security and we help internal cross-project communication and we help external communication between the project and the larger community of either engineers, developers, the open-source world, whatever. And so, a lot of SIG Security's work is done by our sub-projects and our sub-project leads are going to tell you about it and I just got to say they are amazing. They are doing amazing work and I'm so excited to be on the stage with them and for y'all to hear from them. So, yeah. Thank you. Thank you for the in. I am so, so happy to share the stage with my fellow friend. I'm going to call them friends because we have grown together and I want to start with SIG Security Documentation Sub-Project. So, before I dive deep into what the project is, I want to take this opportunity to clear something. Like, everyone has some kind of question like, there is already a SIG for documentation. Why do we have another project for like security documentation? Well, the SIG documentation does a whole lot of things like they host the website, they take care of multiple Kubernetes version related documentation, they update the overall content and they also kind of like take care of the localization and they also do a little bit of security work. Whereas the Security Documentation Sub-Project has one and only focus which is like improving the security content of the Kubernetes website. The goal of the project is to make the Kubernetes website a one-stop shop for all information related to Kubernetes security. Right now, it's not the way that you have to look outside of the Kubernetes website to get many articles. I have stumbled upon a whole bunch of articles, some of them are outdated, some of them are not related to the current up-to-date release information. So that is the goal. Now that we are clear about that, I want to move a little into like what is all we do in this project. Say for an example, it's very, very simple and easy to misconfigure configuration and that could lead to like a lot of catastrophes and also several sleepless nights for the service provider because of a zero-day attack or some kind of vulnerability and so many things. And if they are a downstream upstream provider and someone is consuming their product, it's just like a chain of events. So we just want to provide them some kind of example or like a template in the documentation where they could use it to build their own configuration on top of it. I'm not saying that it's going to make everything super secure and just trust it blindly, which no one should and everyone should have security in their mind when they are doing things, but it'll actually provide some kind of like base secure template so they can just build on top of it. And that is one of the areas that we are working on, improving the examples, adding more examples, making sure the security context and those examples are right. In addition to that, we also add supplement that content with blog and tutorials, which we don't have that many. That is one thing that we are working on. What is that? What else is there? I'm pretty excited about. So I'm going to come to that. Thank you, Ian. And I want to give more of a glimpse of what we worked on for the past few months and what we are working on right now. So recently, we started working on the hardening guide and close to Rory McCune, who couldn't make it to the KubeCon here, but he is there with us all in spirits and he's an amazing person. And he has been behind the hardening guide. So we started working on it and the scope is so big and we couldn't finish it. But then before that, there was a blog post made by NSA and CISA regarding the Kubernetes hardening guide. So we did a review of the blog post and it is available in the Kubernetes website. So if you haven't had the chance to go take a look at it, please do. It's a complementary content. It's not something like a critic or review kind. It's more like you have to read the original guide and then we have additional things like some of the new features that went into the recent releases have not been covered in the guide, hardening guide. And that is what we have and links to the CAHPS and links to the blog post and related stuff. So that's one thing that we published recently. And then the next one that we are working on is a threat model for Kubernetes Admission Control. I got that right. Kubernetes Admission Control. So that is something that we are working on and it's going to be super useful for end users. So I was that admin who just deployed things blindly, everything with default config, which should never ever go into production ever. So this guide is going to have all the attack vectors and how to mitigate and more information about that. So that's going to come out and this month or next month in a couple months. So keep an eye out for that one. So now that I have provided what we are doing, what we have done, I also have, I want to take you all into the dream land of what's there in the upcoming year. Can we move on the next slide, please? What? Can we move on the next slide? Yeah, of course. Thank you. So we are working on two, we want to work on two major things. How many of you have had issues with our back? Right? Everyone, right? I could never find a documentation and I have never gotten it right in the first go at all. I know there are like multiple policy related things coming up. There are like services. I don't know if everyone is going to use them or not, but still our back is important. So that is the next project that we want to have, like have a decent RBG guide available on the Kubernetes website so that everyone has a baseline to deploy that. The next one is a security checklist, which is closer to my heart. I used to be a platform engineer and I would have loved to have a checklist when I deployed a cluster, like check, check, check. Oh, I have deployed a cluster, which is secure to an extent by default, right? So that is one of the projects. So this is where we need all your help. So if any of this is interesting, please feel free to stop by, say hi. If you're a new contributor who want to get into security, you are intermediate, you are like a seasoned expert, but you want to give back something to the open source community and you are looking to start. And this is where you can help us all. And you can make the dream come true together. So I'm pretty dreamy right now. So and so we need your help. So and we meet once every month on the first Thursday at 2 2pm Eastern. And we do most of the things and asynchronously, asynchronously on Slack. So if you cannot make it to the meeting time, that is totally fine. Go to the Slack channel. If you have a new idea post there and awesome folks from the security community will be there to jump in, shout out like plus one your ideas, add their comments. And every, like if you're looking for motivation, it's there. And if you're looking for collaboration, it's there. And I do have to tell one real thing quick. I missed something. I do realize that I asked for help. And these topics are really, really big. I know about the time commitment. And this is where collaboration comes into play. We in security love collaboration. We encourage collaborating with others. So you can pair up with other contributors, more contributors, break those things into chunks, ask for help. We are all here to work together and make it happen. That's all from me. I am going to give it to Ray, who is my awesome friend. I'm going to talk about audits. Thank you. Y'all got to say next slide when you want me to click a slide. Okay. All right. So hello. My name is Ray. I am the sub project owner of the third party security audits. So last third party security audits occurred in 2019. We released an RFP, which is now closed this year. We are currently in the process of selecting a vendor. So the audit goals, of course, is to find vulnerabilities, fix them, report them to the security response committee as well, get them out and get the fixes out. And so one of the new additions with the subprojects as well is an audit roadmap because the Kubernetes project is such a big project. I've been on the release team since 118 in 120. We had 42 enhancements, 121 we had 52, 122 we had 53, 54, 56. And then 123 we're tracking 57 pending code freeze in mid-December. So we're seeing a lot more enhancements go into the project every release. So we need a way to have external security audits for not just the core components. So in this year's security audit, we did include CSI secret store because we do see a lot more end users using CSI secret store, meaning that you could keep your secrets outside externally and the pod come out to them as a volume and use it. So that's also including all the core components of the Kubernetes project. Could you go next slide, please? So this is the current audit scope here. So as you see in the very bottom, we have the core components in the very bottom. We do have CSI secret store. So next slide as well. Sorry, that's too fast. So what's new with the security audit group as well is this roadmap because we do, since this project is continuing to grow, there are components like Cluster API. Now we can include in future audits and also we want to do more frequent security audits that are more focused as well. So part of this as well is that we've started doing self-assessments in which it's more about that later. And we could tie in some of the self-assessments into what is going to be included into the third party security audits. It's not required, but doing self-assessment helps strengthen your security posture so you'll get a better result out of a third party security audit. So that's it from me. So stay tuned and we will do a vendor announcement selection fairly soon and we should release the results of the audit fairly soon as well. Thank you. All right. Thank you, Ray. So the tooling project, sub-project rather is fairly new and we basically started gaining momentum for it sometime this year, but we have, I think made quite a bit of progress in the limited time we had. So few things that are done today are two pro jobs, which is our CI CD for Kubernetes, which run every six hours and detect any vulnerabilities that are part of build time dependencies of Kubernetes and images that Kubernetes releases as part of every Kubernetes version. Those are the things we are leading. We are also working on creating a CBA list that's accessible and programmatically accessible by maybe a code command in future. The other piece of tooling is also to help achieve dreams of other six, like SIG architecture, SIG release, and also helping SIG docs and third party audit. So some of the things that we have done there is helping on implementing the PSP replacement, the admission control. Then we have helped SIG release bump a few images and some build time dependencies. We've been able to remove some code that wasn't needed or was malicious. And we've also been hosting learning sessions in the last two, three months. So we have had Stephen join us talk about how the release image promotion cycle works. We have had Adolfo, who is our track host, join us for talking about S-bombs for Kubernetes. So we continue to do that every third Tuesday of the month. If you have a topic and want to present, reach out to me and we'll probably set up something for you. So this is what we have done so far. And next slide. Next slide is what we are going to do next. So the main thing that's coming soon is the triage policy. So we discussed that we have jobs running and there will be vulnerabilities sooner rather than later. How do you triage that with different SIGs and all of our SIG security friends? So that's an iterative process that we've been working on. The next one after that is trying to start a shadow triage program, learning from what SIG release has been doing with their shadow program, where we'll allow new newcomers and new contributors to join us and triage some of the vulnerabilities with us. And as they grow in their role, they become peer triagers. So that's coming up next. And then the whole idea for doing what we do today in terms of managing vulnerabilities is to reduce the gap where the detection time for any new vulnerability that is in Kubernetes code or in images could always be shortened and the remediation time could also be shortened. So that's what tooling eventually intends to do with the job that we are currently working on. And then the helping never ends. So we'll continue to help Adolfo and all the release engineering team on all the SBOM work, the Salsa compliance work they are doing. Really excited about how that's going to improve and strengthen Kubernetes as a whole. And then finally, as we discussed, we have 57 enhancement proposals for this release. And if the graph continues to go up and up, we'll probably have more next release. So we need more reviewers to look at that from a security perspective. And that's what we're going to do. So hit us up on SIG security tooling if you have questions. But I do want to also talk very quickly about self assessments and security self assessments. So couple of sessions back in this exact room, tax security talked about security assessments that they do for CNCF. And this is actually a collaboration between tax security and SIG security. And this is where the name being different actually helps a lot so that you know those are actually different groups, but they are all friends. So what we are going to do is adopt their practice and their workflow to apply to Kubernetes. And our first project for that next slide is cluster API. So we are going to review and do a self assessment with cluster API maintainers and look at it from a security perspective. Once we understand what really is going on, we'll write up a doc, we'll have data flow diagrams, all the good stuff with threat model. And once that is done, we'll ask for reviews, we'll open it up for public comment, we'll share with everyone of you and you can pitch in and give us your feedback. The next thing, fortunately, because seems like it's a good thing that's going on that other sub projects within Kubernetes are now saying, hey, we want to do a self assessment too. So now we are trying to create an intake form for everyone where everyone can join and say we want to do a self assessment, raise their hand, and then we'll join with them, partner with them and do something similar that we're doing for cluster API. And lastly, I'll pass it on back to Ian for wrapping up this session. Can I just take a moment to say that there are multiple people on the stage who this is their first KUKON presentation or at least their first recorded presentation or something, and that it's so awesome that there are a bunch of first time speakers here. That's like super exciting. And I'm so stoked for them. And I think one of the things that we do really well at SIG Security is create this sense of community and this welcoming place for new contributors to get involved and to grow as leaders. Because we are all responsible for the security of the Kubernetes projects, no matter where you are in your Kubernetes journey and creating that kind of welcoming environment and a community where people can feel safe and good to come in when they are learning and we're all learning really. And do stuff and help with the project and help secure it has been really, I think, successful. It's gone really well and it's been really amazing to see these new leaders grow and shine. So as got mentioned, we're all about collaboration here at SIG Security and we really like when new contributors get involved and also we would like new contributors to get involved. So if you are somebody who wants to contribute to the project or the security of the project, we are all super friendly. You can find us in meetings that are bi-weekly. They are Thursdays at 11 Pacific time. And also, we do a lot of business on Slack. So we have a SIG Security channel on Slack that you can come talk to us. As I said, we're all super friendly. And if you have ideas or things that you're thinking about or questions that you have or a cap that you want to bring up or a cap that you want to comment on, anything like that, we are a place that is like super open to that and excited about that. Because what this is is what people bring to it and the things that we cover and the things that we discuss and the ideas that we have are the ideas that you all come with. So come bring yourselves and your ideas and your lovely shining faces and your smart brains and we would love to talk to you and work with you because honestly, security is everyone's responsibility. And if we all work together, when we all work together, we can make the project better. So thank you all for coming to our SIG Security update. We really appreciate you and I hope you have a great KubeCon. Thank you.