 Good morning everyone and thank you for coming to nurturing security permaculture. I'm Tabitha Sable. I'm one of the co-chairs of Kubernetes SIG Security. We are a horizontal SIG that works to improve the security of Kubernetes as a project overall by building community to bring together security expertise, new learners, and the maintainers who are working on and taking care of the code within the code base. So I and my fabulous colleagues here will be sharing a little bit about what we have been up to, how we do it and why, and how you can participate as well. So I will hand this off to Savita to tell us a little bit about what has been going on in Documentation Subproject. Thank you Tabitha. My name is Savita Raghunathan and I am the lead for the SIG Security Documentation Subproject. Kubernetes documentation is awesome and the purpose of this subproject is to make it more security aware. So in the past two and a half years we have made so many improvements and thereby achieving one of our, achieving and trying to continue to achieve one of our goals where we want to create security awareness through the documentation. So that is one of the major things that we focus on and also we want to make sure that it is a place for people to come learn and share. Their knowledge and also make Kubernetes website one stop shop for all things Kubernetes security. So that is also another major goal. Now that we have learned a little bit about why we are, we are there, what we are doing. I see like things that we are currently focusing on. The first up is the hardening guide. It is one of the biggest projects that we have undertaken. And right now it has a lot of independent smaller tasks available in the issue and we are focusing on one task at a time. So if you are an expert in the Kubernetes security and you want to pick up one of the tasks, you are, and if you have free time and you are willing to contribute to Kubernetes and you want to be a part of our SIG, so I would say that please go to the issue and come to one of our meetings, assign it to yourself and there are like many more ways to start contributing. If you are new and you just want to be like, oh, how does it feel to be a part of security? That is like an awesome place to start. And the next up is the confidential computing for Kubernetes blog post. So it is ready to be published and I think it's going to be soon available in the Kubernetes website. So if you are interested in checking it out, so please, once it's published, it will be posted in the Slack channels and then you can go to the Kubernetes website and check it out. Along with that, we also make continuous updates to the examples, the tutorials and whatnot. We all know we just copy paste the examples, right? If we want to like try something out, I do that, I am guilty of that and I'm not actually guilty of that. I can trust it, I know I can trust those examples, so I just copy paste, run it. So one of the things that we want to do is like make sure that it is secure enough that we can actually copy paste and run it. Also that I feel obligated to tell that that please don't blindly run it in production. Next slide please. Now that we have learned about the current work, let's talk a little bit about what we want to do in the future. I don't know if you all know that there is a Kubernetes security checklist that is available for the administrator and I want to thank Mahi for spearheading that project. So the future work is an extension. We want to make sure that we support the deployment, we support the developers who are developing the application and they have a place to go and have a checklist say like, oh, my app checks all these things. Okay, cool, cool, cool, and I can now deploy this application securely to Kubernetes, so that is one thing that we want to focus on. And we also want to improve on the RBAC concepts. So we want to have a tutorial which would make it easier for folks to understand and do awesome things. And as usual, so our project is actually looking for new contributors and like if you have spare time, if you're interested and if you want to know more about security and if docs is your thing and you want to like contribute, please stop by our Slack channel. It's a security docs on Kubernetes Slack and we also meet once a month. We are pretty much informal, so we do a lot of asynchronous updates. So the meeting time doesn't work for you. It's totally cool. Just hop onto the Slack channel and post away. So that is how we roll. Now that also one more thing. If you have any idea, just don't hesitate, post it on Slack thread or create an issue on the Kubernetes website. Tag it with security so that we know that there is something that we want to take care of. There is something that we need to attend to and that is also a valuable contribution. So if you don't have time, making an issue is like a great place to get started. So now that I have covered everything, I am going to pass it on to Tabitha for audit updates. I am happy to represent the folks who have been working on the third party security audit sub-project. The purpose of the third party security audit sub-project, as you may guess from the name, is to facilitate an ongoing series of regular expert audits by third party auditing firms in order to ensure that we are always continuing to improve the security of Kubernetes code and Kubernetes design. So the auditing of a code base as large as Kubernetes is a tremendously large undertaking, both for the audit firm and the folks who are working on the audit within the firm and for the folks who are coordinating the call for proposals process and the vendor selection and all of that. So it has been a very large effort and I am very happy to share as you likely heard during the keynotes this morning that the most recent audit report has been published and is now available for public reading. It's in the GitHub repo Kubernetes slash SIG security. There is a direct link in the QR code if you want to read the report yourself right now. The publication of the audit took some amount of time after the audit was complete because the security response committee and the SIGs that maintain the code that is affected by the findings worked together to address the findings in the report as appropriate before publishing it. So that means that there have been several of them that have fixes committed and there have been several others that have public issues opened to say, here is a known area for improvement and let's collaborate on how to make that improvement. So overall there were six medium level findings in this report. There were nine low level findings and then a few more informational ones which you can read all about in the PDF that is in the link. So I really want to say thank you very genuinely to the large team that was involved in this undertaking. All of the folks from NCC group who was the audit firm that performed the audit were wonderful to work with and brought fantastic expertise to bear. The folks from the third party security audit subproject did so much of just carrying the process along even coordinating the proposals from vendors was itself many, many, many hours of work and I'm so grateful to have been able to be a very small part of that. And also to the security response committee and the folks from the SIGs who worked quite quickly to address some of the most serious findings before we published the audit in public. Having shared that, I would love to hand it off now to Mahe who is going to share some of what's going on in the tooling subproject. Thank you. So I'm Mahe Tardy. I've been contributing to SIG Security for something like two or a few years now and I'm representing SIG Security Tooling Subproject because unfortunately Pushkar the lead could not attend today. So what does SIG Security Tooling Subproject do? Mainly we try to build and improve the security of the whole project working across SIGs and working with different people in the project and we try to create a space for new contributors to share and learn. So how did we do that? We basically meet twice a month. The first meeting is usually a working session when we go through issues and try to find new opportunities for newcomers and the second session of the month is usually a learning session. So that's where we invite members from the community to present their projects, their toolings to go through deep dives and such. It's really easy to add yourself to this list. You can just open an issue and try to schedule a presentation. So here this is like the six last presentation we had in the six last months. So we had many tools, a strat thread team, Eraser, Cube Audit Security Guards and COPA that you can check on YouTube if you have the recordings. Next slide please. So what do we do during our working session and what do we do in general? First thing is the CVE feed. So the CVE feed is the official way of fetching the new CVEs that just like appear, just where revealed on Kubernetes. So it was created by Six Security Tooling. And now it's compliant with JSON feed specification V11 so that you can use your favorite tool to actually fetch the feed and do whatever you like with it. And it now additionally supports RSS. I know it's something that people were interested about because Google Groups kind of abandoned RSS in 2021. And we added some metadata, so some stuff more. We have some issues on this thing, very specific ones on how to improve the feed if you want to participate. If you just want to check it out, please feel free to ask about new features that you would like to add. And on the CVE scanner, so we have been running the scanner on the package of Kubernetes and the image that are built from Kubernetes, Kubernetes repo. But we are mostly now looking for new contributors and new maintainers that are interested in this thing. We can provide mentorship if you want to try. Please just reach out to Kubernetes like Six Security Tooling Channel if you want to know more about that. So with that, now to Ala. Thank you, Mahe. All right, folks. I'm Ala Duberi. I'm a product line manager at VMware. And I'm going to talk to you about self-assessments, which is a sub-project I lead. Next slide, please. All right, so what is self-assessment? So for a single self-assessment, the goal is to answer two questions. What is the security posture of the workflow that we're looking at, or that we want to threat model, or that we do a threat model of? And how can we improve it? And then, of course, to capture vital next step, capture action items to actually close the gap between the security posture we have now and the security posture that we want to achieve. For the sub-project as a whole, it's really to do as many self-assessments in Kubernetes throughout the code base as possible. So, you know, the real kind of angle here is that the sub-project is here to educate people about how to do a self-assessment, how to draw a data flow diagram and to perform a threat model for a targeted workflow. We want to do as much of that as possible in the Kubernetes project. Next slide. Yeah, so why are self-assessments important? Well, it's all about positively augmenting the security posture of the code base. And we do that through knowledge sharing, so there are kind of two prongs to that. First is sharing knowledge of how do you do a self-assessment? How do you perform a threat model? It's simple, it's not easy, but it is, you know, a simple set of steps that if you know how to do them, you can get to a pretty great outcome. It's also knowledge sharing in terms of, you know, the exercise of drawing a data flow diagram and performing the threat model with a group of people is itself exchanging information between more people for how different parts of the project actually work. So the act of doing a threat model, the act of doing a self-assessment is meant to itself share knowledge and spread knowledge about how different parts of the code base work. And of course, all of these kind of efforts together are meant to build that security muscle in the Kubernetes community, which really gets to the title of this presentation, which is getting to that security permaculture. Next slide. So tactically, what we have been up to is the vSphere CSI driver self-assessment. So our first session is complete. We got pretty far along in drawing the data flow diagram you can see here. Next steps are to continue with some next workflows. So we started with the creation of a persistent volume and, you know, we're probably going to do, you know, read, update, delete, getting super creative here. And, you know, then it's about really labeling these diagrams. How is, you know, drawing arrows for how is data flowing between the components, you know, as these workflows progress, noting ports. And then once we have that in place, then we can apply the stride model, which for those of you who are familiar with it, then maybe for those of you who are not, is basically, I always forget what the acronym stands for, but basically it's a set of categories of attack types and you can go through once you have this information charted out in your data flow diagram for, okay, how could a hacker exploit this? It just gives you a systematic way to kind of walk through how a hacker might hack things. So from there, we're going to write up those findings, socialize them with many of the colleagues here, but also in other parts of the community, get that feedback and then publish that self-assessment. And then of course it's always about finding what is the next workflow, what is the next part of the code base that wants a self-assessment. So we're always looking for that. Next slide, please. All right, so like I said, the guiding metric for this subproject is to just fill our repo with as many self-assessments as possible. So if anyone here would like to do a self-assessment for the part of the project that you work on, please use that link and submit a request for a self-assessment. You can also feel free to join us and listen in on our vSphere CSI Driver Self-Assessments. Those meetings are ongoing. You can click the link right there in the vSphere CSI Driver Self-Assessment Slack to listen in on those meetings. And of course, you know, about nurturing permaculture, it's all about engaging the community. If you have experienced doing threat models and you want to help us do more of them, please by all means hit me up personally, DM on Kubernetes Slack. Also SIG-security, that's our Slack channel for the SIG as a whole, but also the self-assessment subproject Slack. Those are all great ways to get in touch. All right, so now I'm going to hand it over to Tabby to chat about security permaculture. Thank you very, very much. Having shared some of the things that have been going on, I'm really happy to kind of zoom out a little bit and think about why are we doing these things? What is guiding us and where are we trying to go with it? And so to kind of pivot into that, what is permaculture and what does it have to do with security? So permaculture is a set of thoughts about gardening or farming in a way that takes advantage of the ways that the different plantings can augment each other in order to nurture together a garden or a farm that is able to support itself with a minimum amount of external inputs like weeding or fertilizing by really taking advantage of the places where various plantings have strengths and limitations that complement each other and taking advantage of the local situation, you know, planting things that are happy in the environment where you want to be growing them, for example. And so this means that working on permaculture is doing things in a way that is very intentionally holistic using systematic thinking, finding the interconnections between the various parts and maximizing the way that those connections can support each other. And so that leads me to be thinking often like, what if security culture, which when I think of that phrase in those quotes like that, I'm imagining a very command and control sort of protecting people from their own badness kind of waddle. You know, what if we can replace that with something that is more like permaculture? What if we can replace security culture with a culture of mutual support? And so this is the way that we do things in SIG Security. And the way that we do that is by focusing on these sorts of values. So even from the first entry point into SIG Security, if you come to a meeting, one of the first things that you will see happen is the folks around the room will introduce themselves and do that in a way that is about who we are, why we are there, how we are hoping to be part of this group. And then when we're there, then we bring each of our experiences. Some of us are experts, some of us are new, some of us are very deep into application development, some of us are very deep into hacking or penetration testing, some of us are very deep into compliance and auditing and reports. And we bring all of those interests together, we bring all of those strengths together, and we bring the thoughts and concerns that we have for how to improve Kubernetes security. And we find the ways that we can support each other there. We make a space in time for ourselves and for each other to do the work together that we want to do. We make opportunities for ourselves and for each other to lead, to support each other, and to learn and grow. And we do this by taking our actions collectively. We make our decisions by bringing them to the group. And the group is the people who are showing up in order to participate in the group. So when we need to do something within SIG security, we talk about it, we talk about it in the meetings, we talk about it on Slack, it's in the meeting notes, and this means that when there is a suggestion for some good thing that could be done, sometimes there is a tremendous groundswell of interest in that thing, and it zooms off and it happens in a blink. And other times there are things that are very good ideas, and unfortunately there is no one to carry them at the time, and when that happens, those things simply aren't carried, but we have shared what they are. They are now part of the general pile of things, which are part of the knowledge of the folks in SIG security, and they come back later when there is time available, when someone new joins who has particular expertise in an area, that sort of thing, because what we do, we do together. And so by doing that we are building an environment that is based on supporting each other, supporting the rest of us who are maintainers, supporting the users who are using Kubernetes rather than coming at them with authority. Like we are very strongly of the opinion that there is no person, there is no group that can appoint themselves to be an authority and make Kubernetes secure. No one could make Kubernetes work on their own, no one can make Kubernetes secure on their own, but together we can improve it bit by bit, and every improvement makes the world a slightly better place. And so this means that while we own very, very little code, used to be able to say we don't own code, and then we created a CVE feed and there's code that generates that. So we own very little code, but we have thoughts and opinions and a desire to help across the massive code base that is Kubernetes, and it would not be appropriate for us to stomp in with our big feet because after the security people, we're going to improve things around here. No, but we can come and say we had this idea, we talked about it and we think this might be interesting to you. Are you interested in this? Does this sound like a good idea to you? And if it does, what can we do to help make it happen? Like a really recent example of this is the work that I started and several folks have been contributing to along with SIGOFF and maybe also API machinery, question mark, in order to deprecate and remove the built-in pod security context deny admission controller. So there's this admission controller from like back in the mists of history called security context deny, and if you enable it, the API server will not allow any pods that have a security context that sets any of the interesting fields. And there was a time when it was thought that that would be a sensible way to run a cluster that was a tight ship. But like folks have daemon sets that have needs, and so something that is unconfigurable and stops you from running anything with any fancy settings in it is it's a difficult sell these days. And so the idea was floated. Can we just make this go away? Can this code be removed and therefore ease a maintenance burden, ease a confusion burden for end users about whether or not they should be using it? And we discussed it within SIG Security, we discussed it in Slack, we discussed it on some of the meetings. We decided that we thought it was a good idea, but that's only the first step. You know, once we think something is a good idea, now we have to go and talk to the folks who actually own and maintain that thing to find out what they think and whether that's a thing that we can do together. And so Mahe and other folks worked with SIG-Auth and other folks who own that code. And I think there's a PR now that marks it deprecated? Yeah. And like this is how the process works. We have an idea and we talk with those who are affected and we work through things by having mutual consent. So that's where we're going and how we're hoping to continue to build this idea of improving Kubernetes security by mutual support so that we don't have to be involved. We are not involved in every security related thing in Kubernetes and that's good. Like folks are maintaining and building Kubernetes and they are good at it. We can help, but we are not the arbiters of everything. And so by taking these actions, we're continuing to set that standard. I'll give it to Savita to pull us on out of here. Thank you, Savita. So if you have followed along this far, you would have seen certain themes emerge. One of it is that SIG security isn't enabling SIG like we support. Other initiatives that we come up with, suggestions and we are there to help, not just, you know, stomp on everywhere and say like this is the right thing to do. We are there to like support. The second thing is we love to learn and share and to reiterate what my friends here said. If you are passionate about security, if you would like to learn and share and if you're looking for a group that is so welcoming, SIG security is the place and you can find this on SIG security channel on Kubernetes Slack. And we meet at 6 p.m. Central European summer time, which is 9 a.m. Pacific start time and 12 p.m. East standard time. So that's all the time zones that I can remember. And you can use the clock to convert. And we also have this mailing list. If you join that, you will get all the awesome automated invites to every meeting that we have. And you can pick and choose whatever that you interest you. And you can always stop by and say hi in our Slack. That's the end. And also the one final thing that I wanted to say, like even though I wasn't there yesterday and I was really sad for missing it, the additional perk of being a part of this group is you get to hang out with so many cool, awesome people. So that is one big thing that I really love about being a part of this SIG. And I bet all my friends can say that, say the same. So that's the end of it. And if you have any questions, I think we'll take them now. Yeah, thank you. Thank you all so much for coming.