 Are we on? Oh, yes, we are so on. Hello, folks, and welcome. This is the SIG Security Talk here on the maintainer track at KubeCon NA 2022. My name is Alah Dewberry. I am a product manager at VMware in the office of the CTO and subproject lead for the self-assessments subproject. Hi, everyone. My name is Savita Raghunathan. I am a senior software engineer at Red Hat. I am the subproject lead for SIG Security documentation. And hello, I'm Tabitha Sable. I'm one of the co-chairs of SIG Security. I'm also a member of the Kubernetes Security Response Committee and a staff engineer at Datadog, focusing on infrastructure security. So, click for me. So, yeah, thank you so much for coming to hear a little bit about SIG Security. I'm super happy to share it. We are a horizontal SIG that works with all of the other SIGs within Kubernetes to continually improve the security of the Kubernetes project, both the software and the user experience for our users and also things within the project. So, the way that we do this is really specific. We focus on building community. We focus on building relationships within Kubernetes and with folks out in the rest of the world because Kubernetes is a large and complex project, but even in something simpler, security is not the sort of topic that one person or one entity or one authority can assure for a project, for an organization, for anything. And so, since any contributor can potentially make the security of the project better or worse, we are focused on ensuring that everyone has the possibility to come together, learn, share what they know, and together improve the security of the project. So, we do this by making documentation, process, and feature improvements within Kubernetes. So, that means that sometimes some CEPs appear in a related SIG, and they say to themselves, this has security implications. Let's also go and talk with the SIG security folks about it. Sometimes, SIG security folks, I don't know, wake up or get out of the shower or whatever sort of thing gives you ideas. Sometimes, SIG security folks say, I wonder about, and then when that happens, we discuss it, everybody brings their thoughts, their experience, and sometimes those things go out to other SIGs, and we say, SIG security has been thinking about this. We wonder what you think about it. Is this something that you'd like to work on together? And then that happens, and then we see CEPs, we see improvements. And it's all based on talking to each other, sharing our learnings, and using consent with each other. So, we also provide some security-related services within Kubernetes. We'll hear a little bit more about that when we get to the tooling subproject. And we also serve as the public forum for the security response committee. Security response committee meetings are private due to the nature of the work, but as the SRC, it's our job to help and support Kubernetes, and that means that we need to be able to talk about some of our decision-making processes and things like that in a public forum, and SIG security provides that as well. So, that's what we are, and that's how we do. So, we will move on to Savita to hear about DAX subproject. Thank you, Tabi. So, Kubernetes website is awesome, right? We all have used it, and we still use it. Close to the SIG documentation folks, I know I see some of the faces here, and all the contributors who have contributed to make it awesome. What do we do here? So, we want to just enhance the documentation by creating a security awareness, and we do that by adding tutorials, security tutorials, and then, like, more security-related examples and keeping the things up-to-date, right? We don't want to have an outdated example. Then you just copy-paste it into a cluster, and then there you go. You just created a nightmare for yourself, on some other day, not on the same day. So, that is the major goal of this project, and some of the recent highlights of this project includes the most wanted feature, Kubernetes security list. So, we have recently published the Kubernetes security list, and all these are hyperlinks, so once the slide is available, you should be able to click on it. We recently published it. It's focused on the admins, and we are hoping to administrators and we are hoping to expand it to the application developers and whatnot. And the next one is that api-risk... api-server bypass-risk posed by Ruri, and there is also the historical context on PSP. So, we all talked about PSP for how long? Three, four releases, or more than that? And finally, the PSP is duplicated, and we want to know what was history of it, right? It's a nice little thing. It's like a trivia thing. So, one of the contributors, Mahe, published a post, and my favorite thing is the historical chart. If you go to the blog post link there, you can see the timeline, and that is my favorite part of the entire blog, in addition to all the years, of course. Can we move to the next slide? Thank you. So, what are we going to work on? So, we have some major goals, but the first up is the hardening guide. We have already had it, and then it kind of was a very big project, so it kind of died down, and it has been finally revived, and thanks, Kailin. So, this time we're going to do it a little different. So, we're going to divide it into multiple little tasks so that new contributors, existing contributors, whoever wants to contribute, can come in and take a piece and chip that into the project. So, that is the major idea of that one, and then we're going to add more tutorials, mainly our back, that is one of the goals, personal goals that I have. Hopefully, I'll get to that, or I'll let any of the awesome contributors get to that. And another thing that we have been talking about is the confidential Kubernetes. So, there is quite the buzz, and there are awesome contributors, and working on a blog post. So, look forward to that sometime in the quarter, next quarter, sometime next year, hopefully. So, we'll get that out. So, those are the interesting things that we are working on. We are also a need of contributors. So, if any of these things is interesting to you, just stop by our meeting and stop by our Slack channel. You can stop by and say hi and say security as well. So, that's all from docs. I want to pass it to Tabi for audits. Yeah, thank you so much. We have third-party audit, Subproject, which is organized by my fabulous colleague, Ray, who you may also know from the release team and SIG docs. And the third-party audit, Subproject, focuses, like you would guess from the name, on facilitating periodic professional external audits of the Kubernetes codebase. And this provides us a couple of different values. It helps to serve as a check for the work that all of the contributors and maintainers are doing all of the time to represent security needs within the work that they're doing every day. And it helps to discover new potential problems so that we can address them earlier before, hopefully, they are discovered in the wild for some kind of harmful purpose. Organizing a professional code audit of a large project like Kubernetes requires lots of logistics, requires a lot of communication with the selected vendor in order to help to guide them through an effective way to take a journey through the huge codebase. And the folks from the audit Subproject have done a great job of sharing their expertise with our vendor in order to get them into the right places and find things that might go bump in the night. They've recently published a blog post about a retrospective of the previous audit that completed in 2019. It is talking about the status of the various issues that were found in that audit. And so we want to thank Kaylin, Pushkar, and Rory for the work that they did getting that blog post together. The current audit that started in late 2021 has wrapped up and the results from it are being reviewed within the Security Response Committee. So we will see the full report from the auditors published as soon as the private response is completed. And they're making sure that what they learn from going through this process also gets shared back with the folks in the Security Self-Assessment Subproject and the folks in CNCF Tag Security in order to get all of the learnings shared around everywhere so that we can all continue to get better from each other's experience. So I'll give this back to Savita. No, we're done. I'm giving it to Ala. Oh, it is Savita for tooling. Thank you. All right. Thank you, Tabi. Thank you, Ray, for the audit project, leading the audit project in an amazing way. Next on to tooling. So this project is led by my cool friend and an awesome contributor, Pushkar Jogleger. And I'm going to talk on behalf of Pushkar. So what do we do here? We build and enhance security through code, and we do that by collaborating with various projects and various six in the Kubernetes. And the project meets every other week on Wednesdays and they alternate between a working session and then a learning session. The learning session is awesome, super cool. And if you are someone in the industry or someone like who is building and building Kubernetes security tools, you can sign up in the list and then come show off whatever that you have learned or whatever the tools that you have built or if you even find something like super cool that's related to Kubernetes security, you can just bring it here. And that is really awesome and that is one of the highlights of the tooling and so if you are like me, how many of you used to subscribe to the security announced mailing list and whenever there was a CV announced, you read through it and you are like, oh my god, I need to update this, I need to patch my servers, I need to do this. And then after two days, I have thousand emails shift delete or control delete. It's all gone. And then you cannot find the information in your mailbox and you have to go to the Google groups and what not. So the tooling people automated everything and it is available in a Kubernetes website that's linked. And we got amazing feedback from the community and the rest of the announcement is in KEP 3203 I hope I got it right, yeah. 3203, so if you are interested, you can go and check that out. If you have any feedback and input, they are all welcome. So that is like the major highlight that's been going on. And oh, we also have vulnerability scanning. So the Kubernetes CI which builds the images, content images and also the code itself. So there is this vulnerability scanner that has been attached to everything now so you can get the reports. And what else? Yeah. And then like we, as I told, as I said, we work with every project of security and also various things. That's all about tooling and I hope I did justice to the tooling project. Thank you. Next on to self-assessment from Allah. Mind if I scoot over here? Yeah. So hello, folks. And now for something completely different for those Monty Python fans out there. So self-assessments. What are we going to talk about? So first we're going to do a brief overview of some history in terms of the CAPTI self-assessment that was just completed and kind of how self-assessments came to be in Kubernetes. Then we're going to go through some tactical items like what is the goal of a self-assessment and how do you do it? And how does it also at a more strategic level, how does it empower through autonomy and then we'll talk about some roadmap. All right. So a little bit of history here. So in security we are big on the values of learning and consent. And that's definitely how this sub-project got started. So I'm going to look to push her and Tabby to keep me honest here because I wasn't here for this piece of history. But what has been recounted to me is that I'm looking for help realizing that there are a pretty important project in Kubernetes and if there were security vulnerabilities or issues with it that could be pretty catastrophic. So best to take a proactive stance to kind of uncovering that. So of course Pushkar jumped in with his experience from working in the CNCF Tag security self-assessments group and said, hey, you know, I'm going to rally the troops here to do a self-assessment in Kubernetes for Cappy and we're going to see how that works. And TLDR it was overall a positive experience and I think it was the first security meeting that I came on that we were talking about, hey, you know, this kind of needs to become a sub-project now, this was successful, this is a tool and a framework that we want to reuse in the Kubernetes community. So we're going to take a little bit of time to talk about this in honor of merging the Cappy self-assessment PR and yeah, so thanks again to Pushkar for, you know, just getting it started and organizing it and creating an opportunity also for someone new in the community to get involved. All right, so with some history out of the way, let's talk about some goals. So for an individual self-assessment it's basically what is the security posture of the work flow in the project that we've modeled and then how can we improve it. So pretty simple and then of course you capture the action items that you've done from the assessment and, you know, making sure that we take those actionable things and that we actually make the improvements. Now for the sub-project as a whole, my thinking in terms of a really good North Star and totally welcome for feedback on this from the community would be to fill our repo with self-assessments for all the projects and sub-projects in Kubernetes, I think that that would be so, so cool. But again, let's work on and iterate on that goal and that vision together. All right, so part one, how do you do a self-assessment? So just at a high level, a self-assessment is the process of just mapping out a targeted work flow in use by the community. That's step one. Then building a threat model for that workflow, sort of like given the scenarios, what could go wrong, what are the attack factors that could be exploited. And then of course evaluating the security posture of the workflow based on that threat model of the current day. So it's like what are the security controls that we have in place today and would they be effective against the scenarios that we have decided to model out. So that's really at a high level. But let's go a step deeper in terms of what this is here. So the first thing, the first sort of event that happens that tells us, hey, we need to do a self-assessment is that we receive a request. So we do have an intake system in GitHub set up so that you can go ahead and request Six Security to do a self-assessment. So that's the first thing. The next step is to find your people. So given the project or sub-project that wants and has requested a self-assessment the exercise becomes, alright we need folks who are experts in the who have deep knowledge of the project or sub-project itself, how it's architected. And then we need folks who have skills along the lines of being able to build threat models for stuff. So currently, right now the next self-assessment in the queue is for the vSphere CSI driver and I need to find Sheng at some point to start coordinating that process. But it's really building your team. Sort of what are the skill sets that you need to make this a successful use of everyone's time. So once you've got your people in place, the next step is to just map out the architecture of whatever it is you're building. So a lot of projects have this already mapped out. So this is usually a fairly easy step, but it's also a little bit easier to do. So let's go ahead and tackle this. We can't secure what we can't see, so let's do it. So with that architecture mapped out, then you can start to look at, okay, what are the sort of highest priority areas that we would want to do a threat model for? And this is generally, I actually asked this for the vSphere CSI driver, what's the priority? What's the used the most in the community? So we're going to do that first. Then it's just a question of mapping out that workflow. Sort of how does data move through that system? And what does that look like? Then based on that, building out your threat model, sort of how could someone who's a bit naughty exploit this and potentially make someone's day not awesome. And then to just evaluate the weaknesses based on sort of the worst things that you can think of that could happen. And then, of course, to capture and prioritize those action items. All right. So next question. How does this empower through autonomy? So the high-level answers here are to make security things that are accessible and repeatable and by virtue of doing that to federate knowledge. I think that at least for me when I got started in security at Veracode a few years back, there really is a lot to learn and while we need expertise and we need really deep and rich skill sets in security, I think that it's also really important to make sure that we take beginners along for the ride and we help people understand what the small and incremental things that we can do to be more secure and to make doing the secure thing relatively speaking the easy thing. So, you know, the framework and the process that I've mapped out are not inherently rocket science. It's really about getting the right people and the right skills together and then sharing knowledge with each other. I'm not a developer, but I'm super excited to work with people who hack on the vSphere CSI driver and to understand more about what that project does and how it does it and to enrich my learning really about just taking every opportunity that we can to federate security knowledge which is, you know, done by doing things like socializing this framework and socializing sort of the more human concepts of building your team, getting the right skill sets together for success. All right, so how are we going to keep empowering through autonomy? So by virtue of arming the community with a simple tool to, you know, raise the tide, so to speak in terms of our security posture, you know, it's really a question of socializing this tool. Who needs who would like a self-assessment? Who wants to learn about how to do one? Do you want to participate in one even if it's not your sub-project? It's about inviting people in for the journey. Of course, when you socialize things and you ask for feedback, you get feedback, which means that you can improve it or find it. What a concept. And then, of course, in a more tactical sense, like I've been saying, the vSphere CSI driver self-assessment is next. And my open invitation to everyone is to come join us. Actually, Savitha introduced me to someone who's in this audience right now, who's interested in getting started, and we're going to go on this learning journey together. And it's going to be great, so I'm really excited. And also, actually, this is I should almost cross this one off, complete the retro for the CAPI self-assessment. We actually, some of us got together in the speaker lounge and we chatted, we shared a bunch of things. I made a little stickies.io whiteboard and captured a bunch of stuff, so I'll be putting that in the CAPI self-assessment Slack channel, and I'll probably also put that in the SIG security channel too, just to share. Retroing is important. And then, of course, what could be more important than trading learnings with other fellow different peers, of course. So, of course, working with Pushkar and Robert Fikaglia and others in the CANCF TAG security to just make sure that we're keeping an open door in terms of sharing learnings as we both do things on the Kubernetes level and at the CNCF level. All right, folks, so come join the fun in SIG security. Again, I was like, I knew nothing about Kubernetes, and I argued that I still know very relatively speaking to many folks in this room, pretty not very much, but SIG security is a really wonderful, open and welcoming place, and if you want to learn more or you're curious or you have questions, come join the fun. We're open on 24-7, and that link is to our mailing list, and if you sign up for our mailing list, you get added to the bi-weekly meetings, which are 9 a.m. Pacific, 12 p.m. Eastern, every other Thursday. So, yeah, come join the fun. Come have a hunk with us, of course. And, yeah, thank you so much. It's been a real pleasure to do this with you all, and, yeah, I believe you have some time for questions. This is awesome. So, thank you very much for this. What do I sign up? Add Ingress Engine X to the list, because we need this. Besides running through the self-assessment and making sure you're doing that quarterly, what are some suggestions that you would have to help increase the security of a project? Because I know when I get a security release from you, Tabby, it's not fun, but what are some things we can do to help secure projects? I know it's a very general question, but it's a security is very general. Yeah, yeah. I'll start with the specific part first. You literally can sign up if you go to the Kubernetes slash SIG Security repo on GitHub. You can go to File & Issue, and there's an issue template for registering your subproject's interest in having help from SIG Security to go through the process of doing a self-assessment. More generally, at that level of generality, what I'll say is there is no substitute for caring. And so, by showing that you care like this, I would say you're already doing the single most fundamental thing, because all of the work that we do to develop or maintain software has the ability to improve or harm the overall security of the software. And so to whatever extent the expertise that you have allows, keep security topics in mind when you're doing the work. Ask yourself when you're designing a feature if I wanted to use this feature to harm someone, what could I do with it? And that can go into a lot of different ways. That can go into things like intentional misuse of features that can go into finding bugs, like finding parsing errors or type confusion errors in network protocols. It can, asking yourself that question, what harm could I do with this can lead to a lot of, can lead to a lot of places. And the other thing that I would say is to continue to stay curious. So that means asking folks that you know have more knowledge or experience than you, asking them for help when you can, reading about the topics either relevant to your imagination or relevant to the work that you're doing. I really see the role of a security professional as a helper role. Like I am able to spend all of my professional time learning cool, terrible things that you can do with software. But that means that I don't get to spend all of my time with anybody's particular piece of software with, you know, the, you know, with, with the Ingress Engine X controller, with the vSphere CSI driver. The folks who are doing the development they get to spend all of their time with that. And so then we can meet in the middle there where I can learn something about like what you're doing or you know what I'm trying to work with is doing. And they can learn something about more general security properties. And then we can leave having improved the project and also both learn something. So, yeah, I would say care at all which you're already doing great at do your best and be curious and keep learning. Yeah, I'd love to, I'd love to pass that along. Yeah, I just wanted to highlight like the part about getting social and, and like sharing sharing your curiosity, honestly and sharing, hey I'm thinking about security, I would love to get other folks' thoughts. You know, especially with you know, folks who are your peers, folks who are more junior to you too. It's really about bringing that security, like making it as incremental as we possibly can to be secure a little bit all the time. So to speak, that's where you're going to see the biggest gains because changes always happen at the margins in some way, shape or form and, but yeah, I think getting social, staying curious, but also like persisting and circulating your curiosity is so powerful. So I want to say one thing, if you are reviewing something, right, secure software development, if you are reviewing something, you have the slightest hint or like I think I need to get it signed off from a security person or like, I want them to take a look at this piece of code or piece of documentation that is also a great place to like get it done from the start in the right way because you know it's easier to find it, I mean it's not possible to find everything I'm not saying that we can do everything but sometimes it's easier because the third party will have the eyes for something that you missed and it would always be nice to get like another opinion. So that's all I want to add. On the NGENX Ingress Security kind of issue, we have some researchers that are working on actually looking at the runtime packets that are coming in, evaluating changes what's going on, this is a pattern that we think should be looked at deeper and then finding privacy information or whatever security kind of data that's being passed across the guy's name is David Hadass, he's putting together a presentation I believe for SIG Security and I think you guys could probably work together a little bit on that you might be interested, yeah he's got a blog post coming out he's working with Knative and the project is called SIG Guard and I believe there's a little bit, so yes social activity here having many summits maybe for security, for certain portions of the horizontal space I'm a maintainer for container D all the time coming up with security issues, it would be very nice, we could probably start doing some mini summits around right now we're just doing the user name space isolation sort of in our own little hovel it'd be nice if we could expand that out more public discussions I think yeah, any more questions? so I have a question about the self-assessment process in general given that you're doing things about security and there's always some concern that if you are leaking a potential vulnerability or if you discover what you think is a vulnerability during the assessment process, how do you ensure that as you're going through that we're protecting the end user community and that you don't expose something that could put people at risk without something that could at least mitigate the risk? I think that's security response yeah, those kinds of questions given the roles that I have both in the private space in security response committee and the public space in SIG Security those kinds of questions are always really in the front of my mind and the way that we deal with that is by trying to work as openly as we can while making sure that we aren't sharing things until we know what they mean because sometimes like you're saying sometimes as you're as you're working through threat modeling a system or a process you could find something that seems like a nice improvement and let's file an issue about that someday but you also might find things that keep you up at night and then in those cases the folks who are working on that know that they can contact the SRC and go through the existing private disclosure process for that like short circuit that it doesn't have to wait until the end of the life assessment. We have time for one more question.