 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 KEPs 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 KEPs, 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 Docks 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 wanna just enhance the documentation by creating a security awareness. And we do that by adding tutorials, security tutorials, and then 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. Some other, 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 a 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, focused with 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. Like 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 gonna 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 are gonna do a little difference. So we're gonna divide it by into multiple little tasks so that new contributors, existing contributors who are wants to like contribute, can come in and take a piece and chipboard that into the project. So that is the major idea of that one. And then we're gonna add more tutorials, mainly our back, that is like one of the goals, personal goals that I have. Hopefully I'll get to that or like 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 we are, they're all like awesome contributors again 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 in 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 seek security as well. So that's all from docs. I'm gonna pass it to Tabi for audit. Yeah, thank you so much. We have third party audit sub project, 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 sub project focuses like you would guess from the name on facilitating periodic professional external audits of the Kubernetes code base. 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 and used 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 code base. And the folks from the audit sub project 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 wanna thank Kailin, 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 sub project 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 Allah. Oh, it is Savita for tooling. Thank you. All right. Thank you Tabi. Thank you Ray for the audit sub project, leading the audit sub 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 gonna 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 sub projects and other various six in the communities. And the project meets every other week on Wednesdays and they alternate between a working session and then a learning session. The learning session's awesome, super cool. And if you are someone in the industry or someone learning 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 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 project as well. So if you all like me, right? So 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 1000 emails, shift delete or control delete, right? It's all gone. And then you cannot find the information in your mailbox and you have to go to the Google groups and search through and whatnot. 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 KEP3203. I hope I got that right, yeah, 303. So like if you're interested, you can go and check that out. If you have any feedback and input, they're 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 the goal suggested that we work with every other subproject, every subproject of security and also various things. That's all about tooling and I hope I did justice to the tooling subproject. Thank you. Next on to self-assessment from Ala. Mind if I scooch over here? Yeah. So hello folks. So and now for something completely different for those Monty Python fans out there. All right, so self-assessments. What are we gonna talk about? So first we're gonna 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 gonna 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 of course I am a product manager so we're gonna talk about some roadmap. All right, so a little bit of history here. So in SIG Security we are big on the values of learning and consent and that's definitely how this subproject got started. So I'm gonna look to Pushkar 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 CAPTI reached out to SIG Security asking for help realizing that there are a pretty important project in Kubernetes and if there were security vulnerabilities or issues with it that 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, I'm gonna go ahead and rally the troops here to do a self-assessment in Kubernetes for CAPI and we're gonna see how that works. And TLDR, it was overall a positive experience and I think it was the first SIG Security meeting that I came on that we were talking about, hey, this kind of needs to become a subproject now, this was successful, this is a tool and a framework that we wanna reuse in the Kubernetes community and I had the amazing pleasure and honor of merging the CAPI self-assessment PR. And yeah, so thanks again to Pushkar for 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 there are two basic goals. So it's to answer two questions. So it's basically, what is the security posture of the workflow 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 making sure that we take those actionable things and that we actually make the improvements. Now for the subproject 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 subprojects in Kubernetes. I think that that would be so, so cool. But again, let's work on and iterate on that and 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 workflow 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 setup 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, all right, 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 good exercise that maybe if it's a little weak in some areas, 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? Because that represents the biggest attack surface. And as it turns out it's a vSphere CSI driver for vanilla Kubernetes, so we're gonna 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, you know 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 smalling 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 by virtue of that. So it's really about just taking every opportunity that we can to federate security knowledge which is 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 gonna keep empowering through autonomy? So by virtue of arming the community with a simple set of tools to 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 wanna participate in one even if it's not your sub-project? Those are, 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 and refine 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 is in this audience right now who's interested in getting started and we're gonna go on this learning journey together and it's gonna 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, you know, retro-ing is important. And then of course what could be more important than trading learnings with other fellow organists? Yeah, different peers, of course. So of course working with Pushkar and Robert Fikaglia and others in the CNCF 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, 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 Slack 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 we have some time for questions. This is awesome, so thank you very much for this. Where do I sign up? But 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 that we can do to help secure projects? I know it's a very general question, but it's a, security's 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 an 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 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 that are 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 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, whatever 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 pass that along. Yeah, I just wanted to highlight like the part about getting social and like sharing your curiosity honestly and sharing, hey, I'm thinking about security. I would love to get other folks's thoughts especially with 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 gonna 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 in circulating your curiosity is so powerful. So I wanna 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, get a sign 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 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 a, another opinion. So that's all I want to add. On the NGENX, you know, 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, you know, what's going on? Is this a pattern that we think, you know, should be looked at deeper and then finding, you know, privacy information or whatever, you know, security kind of data that's being passed across that. 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, so yes, the 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 if we could probably start doing some mini summits around, like right now we're just doing the username space isolation sort of in our own little, you know, hovel, it'd be nice if we could expand that out a little bit. More public discussions I think. Yeah. Any more? Questions? Adam? 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, that we're protecting the end user community and that we don't expose something that could put people at risk without something that can 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 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, yeah, like you're saying, sometimes 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 self-assessment. We have time for one more question.