 Good morning. Good morning. Good morning. I am so happy to see you all here. Thank you so much for coming so that we can share some of what's been going on with Kubernetes 6 Security. I'm Tabitha Sable. I'm the other co-chair of Kubernetes 6 Security, and it's always a delight to be able to help to make this space for us to be able to improve the safety of Kubernetes together. So, to get into what we've been doing, we should start with really, what are we? Who are we? And the answer to that is, we are the SIG with the extremely broad scope of improving security across the entire Kubernetes project for both end users and the project itself through building community action. So, we actively reject the idea that there is any one person or any one group that can set themselves up as a central authority that is capable of making Kubernetes secure. There's no one person that could build Kubernetes. There's no one person that can help to make Kubernetes better. And so, therefore, we have set ourselves up to be a group that brings everyone together to identify where there are places that things can be improved. Find the folks who can improve them. Find the folks who are able to improve them at the time. And we show up. We do the work. We do it together. We help each other grow. So, that means that we work on feature improvements. Like, for example, we were part of the group that got the replacement for pod security policy off the ground along with folks from SIG Auth and a lot of other folks from the Kubernetes community. We work on making process improvements. Like, for example, we are a way that the security response committee can bring things to the public when they need feedback on their processes and in general processes for Kubernetes as a project. And also helping with documentation improvements because having folks with a specialized security interest or specialized security experience together means that we can find folks who are able to contribute when there's documentation improvements that need to be made. We also offer security related services within the Kubernetes project. Like, for example, the third party security audit that is run periodically and the security self assessments, those like guided self assessments that can be done for other SIGs. We are here to help to make those happen. And, you know, like I alluded to before, the way that we do that is by building a community so that folks who have a security interest can come and they can bring their gifts. And so that means that sometimes we have very, very new people, people who are new to Kubernetes, people who are new to security, sometimes people who are new to both. They can come, they can listen, ask questions, and that is a meaningful way to contribute to the group. That is being part of the group. Some of the folks who attend, some of the folks who contribute are the very well known security experts that, you know, that you see in conference talks that you read the blog posts of and so on. And all of us in between because we all have something that we can bring. And also, that means that we do almost nothing all by ourselves because Kubernetes isn't built by any one particular person or group. And so therefore, a lot of the things that we do are working in collaboration with other SIGs in order to help those folks in the other SIGs feel more empowered, feel safer of discharging them. And also of discharging their responsibilities to make Kubernetes more secure in the areas that they maintain, like, you know, SIG auth, SIG node, all of those SIGs. So that's a fair bit about us as a general group and a fair amount of the work is also done in the subprojects and we will be hearing from our fabulous subproject owners today about them. So to get started on that, I'm going to give the mic to Ray. Hello, everyone, my name is Ray Lahano. I am the subproject owner or lead for the third party security audits, but you might see me in other parts of the project. I'm also the SIGDARTS co-chair and also the 123 release lead and the marriage advisor for 125. So the third party security audit subproject, our goal is to run regular third party security audits. They are overall goals to make the whole project more secure. But the last audit was ran in 2019, where there are 34 significant Kubernetes bones discovered, like credentials were exposed as environment variables and secure TLS by defaults, no set cup by defaults as of 2019, you can have set cup by defaults as well. There's many more. You can read about it in the findings that are published. So I want to announce that the third party security audit for this year is actually in progress. And thank you very much. And MCC group was selected to conduct the 2021-2022 audit. The RFP was released in 2021. We received four proposals for the RFP and the went through evaluation by security experts and also Kubernetes experts as well. You can read about the decision process on that. That's on a GitHub that's linked on the slides that are available. The audits will be based on Kubernetes 1.24, which was just released a few weeks ago. And there's a lot of changes from 2019 to 2022. So we are very mindful on the changes like dual stack, part security mission controller going to be that's in beta in 124 and PSP is being removed in 125. But so it's deprecated. There's lots of architectural change, lots of things that have gone GA since then like keep control, create token, etc. So we are very mindful cognizant of those changes for this audit. Next slide, please. So of course, the primary scope is going to be most of the core Kubernetes concepts that you see here, the API server, the scheduler, the control manager, Kubex, Kube proxy. One thing, one components that we did include that's in scope is the secret store secrets store CSI driver where you can store secrets externally and you can mount it in a pod and mount it as a volume. And they'll be in your container file system. We see this more widely used. So that's why we decided to be in the primary scope of the security audits. And secondary scope is of course at CD because it is another project, another separate project as well. And the cloud controller manager just because not every Kubernetes user will use the cloud controller manager as well. Next scope. Next slide. So what's next for the for this project, we're going to publish the findings. Also, the, this project, Kubernetes project is so large. There are 47 46 enhancements in 124 47 in 123 over 15 the last of the previous two. And the 115 there's only 25. So we see this velocity increase in almost double with each release. So also we released from four releases a year. Now three releases a year. So from 2019 to 2022. That's a lot of releases. So what we've done is that we created an audit roadmap. There are many components of Kubernetes. They're not in scope. So what we want to do is include these and runs a smaller scale security audits on these third party security audits and these. So we want to establish a roadmap. So things like cluster API will be included or when there's worker nodes will also be included as well in the near future. That's it. Next slide. So unfortunately, our fourth co speaker was not able to join us in person today, but he's able to join us through the magic of modern technology. So I'm going to hand it over to him. Hi, everyone. This is push cars over here. Unfortunately, I'm not able to join you in person this time, but I'm going to share what I wanted to share in person through this small set of videos. So tooling is one of our sub projects in six security. And like many other sub projects, we also work across the board, helping multiple teams and getting help from multiple teams at the same time. So let me share a bit about that in my video. So the main job for tooling is to build, enhance and improve security through code by working across six and other sub projects. And because the community saw some sometimes everything just aligns itself as magically as this picture where the clouds and the path are just aligned. And I was just walking across this place one day and I couldn't help myself in thinking about how this really represents how the community really works where each cloud could be one of the six that we work with. And right on the grasslands is security trying to find alignment and everyone coming together to make their dreams about Kubernetes security come true. So sometimes, although it can be a bit confusing, it can be a bit overwhelming as well to understand how do I even go about fixing things that are important for me in security. I was in a similar state and the best way I can explain it is by doubling down on our theme of oranges for this coupon and again showing you this. So let's assume this orange or mandarin or whatever your favorite citrus fruit is, is Kubernetes security and this is the cost of securing Kubernetes. So now the goal of us is to reduce the sticker price. But this Kubernetes security itself cannot be fixed by me or everyone else on the stage, but it needs everybody's help. So what do you have to do if you have to consume and make it easy and reduce the sticker price or want to make sure that it's worthwhile, you peel the orange. So let's peel it together. And when I started peeling the orange, just like I was trying to get myself familiar with the community, what I realized is, oh, look at that. It looks like one fruit, but if you see this orange really is made up of so many different things I can contribute at a time. So let's say this is one of the six, maybe sick release. This is one or other six, sick architecture. And then there are other six like sick contrabex, then we have sick kids and from all of them look similar. But until and unless they all come together, we can't really secure it and we can't really feel like we're there. So that's what I had to do, figuring out how to peel the orange, which is a community in this case and how to figure out a pathway where everyone can come together and make their dreams of Kubernetes security come true. So hopefully this helps. We and one of the things I also realized is not everyone is at the same expertise level as everybody else. So what we did as part of that was create a space for new contributors to share and learn. And what I realized is not only new and existing contributors who are interested, but they were excited to share about things they have learned, things they have been working on and get feedback from the community. So so far, we have had these learning sessions, we do it once every month, most of the times, unless people are not available. And we record it and people join in, people give feedback, people ask questions. And the best part is you too can be a part of this speaker list. All you have to do is hit the link in on the slides and then go there. Describe what you want to share with the rest of the group as long as it's not a sales pitch as long as not a vendor pitch. And it's related to security and Kubernetes community. We will be glad to host you in one of these learning sessions. Hi, everyone. So next thing I wanted to talk to you all about is a story of a raccoon and a turtle. So raccoon that I met recently has been a very knowledgeable raccoon who knows a bit or maybe a lot about security. And then there were a bunch of turtles stacked on top of each other who were doing great things and they were marching along towards great management of clusters. But they weren't sure or they needed help if they were in fact intelligent and brave enough to share that they needed help to secure what they were trying to build together. So the raccoon said, Hey, you know, I can actually help and I'd be happy to do it. But we need a meeting place because I know you like to be near water and I'm not really a water person. So that's where I came in and the story is raccoon who is the logo of our tax security at CNCF and turtles on stacked on top of turtles. Is the logo of cluster API were really two groups inside the community who are trying to come together. And I said, I'll host a space for you. And this is how security self assessments was born. So let's talk a bit about that. So this is CNCF tax security. Kubernetes security. That's us. And this is cluster API. So so far what we have done is we work together. We borrowed more many of the templates about doing the self assessment for that's focused on security from CNCF tax security. Right to apply what we could apply for cluster API and then wrote up a threat model or a self assessment doc, which basically was a combination of multiple meetings that and discussions and slack threats and mailing mailing list conversations that culminated into data flow diagrams, multiple threats that we have identified and things that we're going to work on. So now you can actually see our work, which is under review by hitting this link that will point you to a pull request that explains everything we have found out everything we're going to fix. And you can come in, contribute, take a look, read up on it and see if you can lend a helping hand to all of us. So that's about security self assessment. Hope you enjoyed and I'll hand it back over to the people on stage. Bye. My name is Savita Raghunathan and I am the lead for the six security documentation. The project. Can you hear me? Yeah. So there is this sick documentation folks who have been doing amazing job. There is one of the coach are here. Another one is just sitting there. Hi. What are we doing here at the six security sub project, right? Documentation sub project. We are here to support them and we are here to also achieve a goal that the communities documentation, the website is actually really, really great. And if you want to learn a product, if you want to implement, if you want to like break the product, all you have to do is like take a look at the documentation, right? And one of the things that we want to do is like make the communities website, the single stop for everything related to Kubernetes security. Now, if you go look at it, it's all over the place. And the documentation on security in some places are very thin. So that's what that's what we are working on. And as you know it, and if you have heard all my other coach leads in the chairs, talk, talk about our six security, you know, like we love collaborating and contributing together. And that's what we do in this project as well. So we want to like call all the beginners who want to learn about security. All you have to like bring to this group is that mindset have the security mentality that everything needs to be like security fault. It's not an afterthought and that's what we want and just a passion to learn and share knowledge. We love sharing and you saw Pushkar showing the like the two links of project how they are doing the demo videos and the stuff. So we love sharing. So that's what we do here. And while we do that, we also try and improve the existing examples and the documentation add new ones. And also we want to create a security awareness to everyone like again, when you are developing a product, submitting a project design or anything, you should always have security in your mind and your design and your product should include that it's not an afterthought. So that's what we want to create like when you look at Kubernetes, you need to know like it comes with security. So we are trying to create that awareness through this project that we have discussed a bit about like the project goals and we will actually in the session go much more deep dive into what we have been doing since the security, the group was started with respect to the documentation area. So we have a couple of current projects and one of them is one of them is a security checklist that amazing folks have been working on. And at first we're going to focus on the administrator perspective, the operator perspective, and we want to expand it to the application developer perspective that after that the next version would be for the application developer perspective. So why do we want to do this that the operator and the developer can print this sheet or like have it side by side and like check, check, check, check, and then go to bed with peace, you know, like, okay, my cluster is secure by default. To an extent, I'm not saying that this is the bullet proof list. You have to be also like very aware and like do the due diligence, but this gives you like a basic list of the things that's needed. And the next stop is going to be the PSP deprecation. And Ray talked about it, that it's going to be deprecated in 1.25. And what are we going to do? We are going to work with SIG auth and SIG documentation and support them, figure out how we can help, like updating the examples, making a transition plan, right, adding more blog posts, and so on. So that's the next project that's going to come up. This is like the main two for like next, for the next quarter or like four or five months. Next slide please. Yeah. So let's take a deep dive into like what we have been doing. So I have divided this into like three categories. One is the blogs. The next up is the tutorials and tasks and the next up is the papers and threat models. So let's look into blogs. The first one is about the NSA CISA Kubernetes hardening guide. You all would have seen it. The NSA and CISA people published the hardening guide in August 2021. They did publish the new version in March 2022. This blog post is a complimentary to that guide. If you haven't read it, you should read that. It's not like, like you can just read this one and like ignore. This is just going to be like highlighting the key takeaways and also like add alternate options that the version 1.0 might have missed, but the NSA CISA people were so kind. They included the co-authors of this blog. In their version we got one one to get our feedback. And this is what we talk about collaboration, right folks? Like it's just not about within the sake and like among communities sake or like within communities and CNCF tax security. It's about like everywhere. Like we love to collaborate with everyone and like we want to make security, community security a better in a community security in a better state. Like just like Pushkar described. I can't get that orange analogy out of my mind. I love oranges. And so that is the first blog in the second blog is about how we collaborate between the tag security, which is a CNCF group for security. It's like version of security. How we collaborate between those two groups and it highlights the white paper that was published. And recently there was the version 2 of the white paper that was published and that was led by Pushkar again. He was being the bridge between the two groups. And why I want to mention this is that like while we were doing some of the work and we found that there have been certain portion of the website that meets update. And it created opportunities for the new contributors who wanted to learn and like contribute more or like also the veterans who want to review and add their input and stuff like that. So like it was very awesome to see people come together from like different backgrounds and like different mindsets. I'm going to move on the next one that is the that is above the securing admission controllers. Right. You might have used authentication authorization and admission. Webhook is like another way to secure our security to our cluster. But if you what happens if you don't secure the deployment itself right like if you just give wrong permissions or like if it's not if there is a security loophole that you can go get in the entire cluster and then you can do like anything that the hacker not the right the bad guys can get in the cluster and can do anything that they want. So this post describes about the ways of best practices to deploy a admission controller. And it also talks about other things in addition to that. And I just add that like it talks about the privilege escalation and the denial of service risk associated like if you don't configure your deployment correctly. So give it a read if you haven't the final one is my favorite. Right. Whenever I think of our back I'm thinking of this code and I have mentioned this in the last time when I mentioned it again. And it's like we are all made up of stars but you're our back shouldn't be right like you shouldn't have like wide open permission and you don't know like if you haven't met Ian Coldwater. They are sitting right here. You can wave at them. They're awesome. So like this guide takes you through the best practices again like what you can do to secure secure your our back our back our back in your cluster. Okay. Next slide please. Yeah. So we'll move on to the tutorials and start task. So we talked about the part PSP deputations right. So the thing that is replacing the PSP is the part security standards. And these are the two examples. The first two are the tutorials that's going to walk you through how to apply them at the cluster level and the namespace level. All you need is kind and Cube CTL. I know one of the fellow contributor is also working on improving it by using container D and that's going to come out soon. Keep an eye out for that if you don't have Docker in your local system or at your work machine that some places that you cannot like with all the changes, recent changes. So if you have continuity, so someone is also working on or going to work on that. So when we have it, we will publish that as well. And the last one is my favorite like we love collaborating. So the security and the secret release collaborated on the supply chain security right that is the bus word for now, like everywhere it's there. And I think with the 1.24 1.25 the Kubernetes release team is aiming to make communities also level three with 1.24. They did release the container, the control pin container images that can be that are signed and you can verify it. There is little task in here. You can go and run like a few commands to see the verified signatures. So that that is pretty cool and neat, I think. And the next one, please. Thank you. So let's talk about the papers and threat models. Not only like we just focus. We don't just focus on the website. We also like try to add documentation about like print models and like white papers. And whatnot. The first one is again about the admission control. It talks about like the attack surface. If you deploy the admission control and not the secure way it takes you through the threats and it also has mitigations listed in that. And the next up is the policy management and that one talks about why do we need policy and how you can implement policy in your communities cluster. I think that's all the work that we have done so far and we have like many more to come. So if you're interested, right? This is where we need all your help. If you're interested, if you're an idea, if you want to like stop by and contribute, you don't need to have any experience. All you need to have is come at the mentality that you want to learn, share and grow and you think about security all the time. So please stop by the Slack channel. We meet once a month and we are not so particular about the meeting. If you cannot make it, we do a lot of asynchronous collaboration. I'm all in for that because sometimes there was a time that I didn't even know that meeting was happening and it dropped off my calendar and he couldn't make it. So like folks are so nice that we caught up on asynchronous Slack thread. So things happen and you cannot make it. We all can chat about it like in a thread publicly. So that's all from me. I'm going to pass it back to Tabby. Thank you. Thank you so, so much. I've been really happy to hear some of these updates and to be part of sharing them. Because of the way that we work on this basis of people showing up consensually and working together in the places where they can, really wanted to give credit to all of the folks who are involved. Like we do a lot to make that space and to make it so that there are these opportunities for us to be able to work together. But that's, you know, that's only the beginning of it. The fact that we all come together is where the magic there is, but really couldn't get everybody's name together on a slide. So like really shout out to everybody. We show up, we learn, grow, we do the work, we do it together. That's the way that we can make Kubernetes better. Can't really get everybody on the slide. Like we're now at almost a thousand people in the Slack channel and, you know, every couple of weeks we get together to address the things that are on our mind, the things that are in progress. And usually that's over a dozen folks who are sharing things and working things out together. So you can come and join us. You can be part of that. We have bi-weekly SIG meeting on Thursdays. It's at 9am Pacific. Slack is open 24-7. And, you know, you can find out more by looking at the official documentation in K-Community. The question is, what Slack is SIG Security in? That's a very good question. This is on Kubernetes Slack, Channel SIG Security. Thank you very much. So yeah, thank you. Thank you so much for coming. We have a couple of minutes if folks have questions. Thank you all so much. We have time for a question or two. Does anyone have a question or two for our presenters here? You in the back. The question is, what are some areas of the SIG that we would like to grow but wish that we had more help in it specifically? Should I give the... Yeah? To have more contributors coming and doing some security documentation. That is because I'm just selfish and I'm like leading that. But I'm also going to say, like, we could use the help and across the SIG, right? Like, there could be new, new things that we don't know or we are overseeing. Like, we know it, but we might not know that that's what the contributors and the people who are consuming might need it. So even if you, if anyone thinks about it and even if they, like, suggest it towards, that would be a big help, right? Like, if they want to see another self-assessment, security self-assessment and things like that. Yeah, I would say because of the way that we make decisions collectively, you know, we build consensus to make decisions, folks can help in part by coming and being part of that process. Because sometimes there are ideas that are there and are good ideas, but at the time there aren't, you know, there aren't folks who can work on it. And so if somebody comes and wants to contribute, you can come and ask and say, hey, what's going on? These are my interests and there's ideas. There are some issues there and also there are ideas that are in the meeting notes. So general contribution, like bring yourself and there are things that we can do together. Anything else? I'll repeat it. The question is something that CIG CLI was talking about growing more long-term contributors to the CIG and folks who have an ability to make a commitment and show up over time having access to mentorship opportunities and encouragement to climb the contributor ladder and is that similar? That is absolutely similar. Like, that is what we are built out of. The general process for where CIG security sub-projects come from is the confluence of an opportunity and folks who can be there to run with that. For example, with the security self-assessments, like Pushkar was describing, there was an initial request. Can we do this? We discussed it together and we realized that this was a service that we could offer. And so this first one is done by the folks who were there, like as a project that the CIG in general was taking care of and as that went through, there was the realization that that could be made into a process and there was an opportunity there to mentor someone into a sub-project owner role and that's happening now. That's how we live and grieve. Thank you. I want to say that. I can say that for most of the CIGs in Kubernetes that we welcome new folks to grow or to become maintainers, not just CIG security, but most of the CIGs. We are at time also because I literally cannot help myself and I'm the co-chair. If you are involved in other CIGs, we also encourage collaboration from other CIGs with us. So like come and talk to us at CIG security. If you have thoughts on security stuff, we'd love to work with you. We are at time. Thank you all so much for coming. I really appreciate you being here. Thank you all so much for presenting. I really appreciate you coming and talking here. And if you have questions for the presenters, come and talk to them. Thank you. Thank you. Also, lots of thanks to the fabulous AV folks who helped us out with the special needs that we had. Thank you.