 Hello, everyone. Time to get started here. So what are two things that go together well? I'll start. Beans and toast for the British people in the audience. Can I get some other ideas on things that go together well? Very good. One more example, maybe? Fish and chips. Excellent. All right. So how about security and Kubernetes? So my name is Ola Dewberry. I am the self-assessments subproject lead in SIG Security. So super happy to be at this delightful little unconference session here. So yeah, I just wanted to pull up the get repo. So like I said, we're part of SIG Security here. So today, what I wanted to do with this session, ooh, that looks very messy. Let's hit refresh on that and see what happens, is to just go through the progress that we've made so far with the vSphere CSI driver self-assessment. So just to back up for a second for folks who may not be familiar with the self-assessment subproject, in SIG Security, we are the lightweight threat modeling subproject started by Pushkar, who's amazing. Thank you for all that you do. And yeah, so to just really, oh yes, Justin. That is very accurate. And just for anyone who couldn't hear, this is as of now separate, but we are hoping to make it more related and more a part of what's going on in tag security and has definitely been, was originally an effort by Pushkar to bring the goodness of what's going on into tag security into Kubernetes. Did I get that right, Pushkar? Just going to add, like Justin is absolutely right. At least both the groups are not named SIG Security anymore, so that's a start. And I think tag security has been way ahead and started with assessments way long back. And this is relatively a very new subproject. We've done one self-assessment, basically trying to adopt whatever we can from the good assessments we have done in the past, and trying to utilize the huge number of contributors we have in Kubernetes so that we can be self-sustaining at the same time, having a link back to the mothership in some ways to security tag. And this is a good opportunity for all of us to kind of meet, kind of reassess where we are, see if Allah needs any help, and see where we can help her. So that's more to the context of where we are. Excellent, thank you. So yes, high level, we do need help, I need help. This is definitely a group effort here. So what I wanted to do really quick is to just, at a high level, look at the data flow diagrams that we have so far, because that is, of course, step one or two, depending on how you think about steps for the threat modeling process, is map the attack surface. So wanted to just dive in, review really fast here what we've done. And then from there, really thinking about, sort of, okay, how do we actually kick off the actual threat modeling process? My high level idea was to borrow the work that Andres and Justin have done that just dropped yesterday, which is amazing, and really look at their book and leverage the processes there because why bother reinventing the wheel when tag security has done such a great job of mapping out a course that we can follow. So with that, so the vSphere CSI driver is the container storage interface. You can see this is just a quick little snapshot of the main workflows that this piece of software embodies. And so you can see, going over here, we have taken these sequence diagrams and boiled them down into component diagrams. So without going super far into each one, it's all there, it's all mapped out. There's not really a ton more to say here. Actually, one thing to note is that Shang Yang, who is the SIG lead for SIG storage, I have worked closely with her. She does also happen to be a VMware employee, so it's been really fun collaborating with her on that. She has validated that all of these diagrams are accurate, so we are ready to roll in terms of like, we are done with this part of the process and we're now ready to start threat modeling. So a quick shout out to Grace here in the fourth row, who has done some really awesome work with helping get these diagrams together. So it really has been a community effort. A woman named Carol has also helped with these diagramming exercises. And again, like stepping a couple of steps back, wanting to take as much of the community along for this ride or these rides as it were as possible so that we're really sort of like federating and broadcasting the threat modeling skill set as possible into the community because it turns out that a lot of people having a small but very sort of confident amount of security knowledge goes a much longer way than a few people having a ton of security knowledge and that being it. So we need a little bit of both. I also have a mic so I can always walk to whoever wants to speak and that the main reason is because we are recording we don't want to want the people who watch the recording to miss any important things we say. So just raise your hand. I'm happy to run towards you, sorry. No, that really wraps up my prepared remarks is like we are ready to start. I wanna use and borrow from the, oh I think Justin wants to say something, from the work that's the course that's already been charted for us. So really what I would love in terms of like getting tactical, getting to action items for next week is having a kickoff call with like who is the team who wants to help us take the threat model, start it, get it done. And I'm always like as a product manager thinking about what's the outcome. Let's submit a talk for Paris like next week. I think the CFP is open. Let's write the talk and say this is the outcome that we wanna pursue. I could envision that talk being something like hey we test drove open and secure the book. This is how it went. These are lessons learned. Maybe we have a couple pull requests on the book cause we tried it out and it was amazing but we wanna get some feedback in there. So that's just an idea that I wanna throw out there as well. So thank you, Justin. Great, so that's all excellent. And you and Grace and everybody else have just done a lot of really good work here. And just getting this information down is one of the hardest parts of the assessment especially getting the buy in from the people who have the correct information to put down. So one thing I wanted to kind of like ask about and we could maybe talk a little bit about is once you get to the point where you sort of defined who the actors are in the system and the ways in which they interact it's also very common that it becomes like it is here where there's a ton of actors and tons of things in the system. So to simplify this we usually go through and figure out which interfaces and which actors are actually isolated from each other. So for instance if I'm going to run something in a commercial cloud provider the sorts of attacks that that commercial cloud provider could do if they were malicious are quite similar to ones that could happen if like Intel who had made the hardware was also malicious. And so we don't necessarily need to consider those as separate malicious potentially malicious actors or plane points in the system. And so I'm wondering if you have a thought here if you've looked at the boundaries between actors and you've looked at more of kind of the threat matrix work which by the way my PhD student Marina has done a lot of this kind of work for different projects and if you've had a chance to think about those. I have not had a chance to think about sort of the intricacies of like categories or how we might wanna simplify the categories of malicious actors. So I think that that's again like something that we could really use your help with in terms of like looking at the system looking at what the CSI driver does and figuring out what is the appropriate way to approach that that's definitely a place where we can use guidance. So I think the short answer to your question is no we have not started thinking about that. Thank you very much. I love the initiative. We do a lot of threat modeling as part of all our professional engagements and we have a little bit of a structure around it. So one of the things that we always of course have to do is identify what is being scoped and what is being de-scoped. And then also secondarily who kind of to your point who are the threat actors? Like do we care about, I mean everything from foreign intelligence services down to working inside a threat level that we assume the access has. Do you have any thoughts about how to do that? Do you want to throw out a spreadsheet or? You mean the scoping? Yeah, so it's kind of like extra pre-definition steps I guess. Again, no, that's not something that we've really dug into yet. I think that's again, I think a question that we're well positioned to start answering just because we've kind of we've done sort of the step zero of the homework. So again, that's a place where we can absolutely use guidance. Cool. And I also want to just note, you mentioned giving credit to us and I really do want to call out Pushkar for starting this initiative with CAPI and really bringing the goodness of tax security. And it's because of Pushkar's contributions that I was able to show up to my first ever security meeting and Pushkar was like, yeah, I think this might be, there might be a sub-project in here. Would anyone want to lead it? And I was like, it's my first meeting. And here we are. So I really want to emphasize Pushkar's contribution here. Good job sir. There's one more thing that might be of use and I haven't looked at these diagrams closely enough but something that was introduced by one of my colleagues into our process was the addition of connectivity matrices. So really low level detail on protocols, ports and data classifications as they travel. It just makes the embellishment of these diagrams but that embellishment makes things a little bit easier. So yeah, happy to jump in, like really excited about this. Yeah, well, no, but I think you're calling out something that I think, you know, this is great for sort of like high level data flow but I think we need maybe to beef up these diagrams a little bit more with some of that specificity. So I think that that's already something that maybe we could work on together and I can pull in Sheng as well. Because yeah, getting, again, it's like, you know, high level data, high level component diagrams are great but it's like, let's really get in like what is, what exactly is the nature of this traffic that's flowing between these components. So thank you. See, you guys are already helping. This is amazing. And I think these are all really good points like boundary scoping and thread metrics and so many things are useful in this. I almost wonder like, would it be easy or too much trouble to try one of these things in one of the diagrams and kind of explain everyone like how we could create boundaries, how we could scope something and say like, these things are out of scope. Would anyone wanna volunteer, like pick one of the diagrams and go from there? I'm definitely down if anyone else wants to do that. I think picking one of these and getting into it as an example and then figuring out what, how else we need to beef up the rest of the component diagrams I think is a great starting point. Especially if nobody has ever seen the diagram before, don't know what these fiercice drivers is, I think that would be the perfect person probably. Do you have a sense of what other Kubernetes subsystems you wanna work on next? Yes, so that's an excellent question. My short answer is Ray Lohano, who is the sub-project lead for the third-party audit in SIG Security, which is another sub-project. He has a roadmap for things that he wants, that are important components of Kubernetes that should be audited. And I was thinking that we could attach our roadmap to his roadmap and as a sort of due diligence exercise I guess you could say is going through and looking at his roadmap and threat modeling those components to prepare them better for a more detailed and deeper audit. So that's one idea I had. The other idea I had for sort of like prioritizing next steps is also just looking at the amount, you know, for the coding SIGs, sort of which SIGs have the most sub-projects because those are the likely, you know, a good indication of the most important ones. But also it's sort of like just stepping back and looking at, you know, Kubernetes as a whole. It's like, ah, you know what? SCD is kind of important. Maybe we should do that. And so those are some prioritizing sort of drivers that I've been considering. Yeah. Yeah, I think something I would add is third-party audit has a roadmap like she mentioned and when we were doing the third-party audit that published in April this year, one of the asks from the people who were selected to the audit was, can we please keep the scope limited because we can't do like the whole of Kubernetes? So I think we would end up doing something similar where we pick up some set of subsystems that are relevant and not covered before. And then anything else that is still important but cannot be covered is where maybe our last thing, our last sub-project could be helpful in. I wanna switch tracks a bit. Like just in mentioning a good topic about thread metrics and we have one of the world-leading experts on that. So it might be worth asking them to talk about that. So I'll pass it on to Marina. I think world-leading expert might be overstating it but I have done something. Yeah, so I've done some work on that. So basically the idea for folks who aren't familiar is you take the different elements of the system, kind of this stuff that you've already broken down and then look at everything that could be compromised. Basically anything could be compromised, right? That's the idea here. And then you talk, you look into what are the actual consequences of each of these things being compromised? And then more interestingly, every combination of like two systems, what happens if both of them are compromised? You can take this all the way down to like every single permutation depending on the scope and time. And just really look at like what goes wrong. And this kind of really helps focus like which of the pieces that are most important to focus on in making sure they don't get compromised or maybe mitigating impacts of compromise because they have the biggest impact. So that's just a little bit of background there. That sounds awesome. And I mean, that sounds like a great way to drive, just in terms of like this threat modeling exercise itself, like a way to prioritize efforts within this overall effort. Sort of like, okay, when these two systems are compromised, okay, we got to like, we should really kind of bite on this and pull the thread here. So that, I mean, yeah, that sounds like a very, very effective technique for prioritization. And I'm all about prioritization because I'm a product manager. So that's my jam. Any other questions? Yeah, go ahead. Let me wait for me. I said your comment about HCD is interesting because I always wondered about the API server and it had all the off and, you know, I think the PKI stuff's all in there. And yeah, I mean, it just seems like that's one of the most complex parts that we should be looking at. Yeah, that was just an offhanded comment, but if people want to take it seriously and we're like, that should be our next thing, then cool. Offhanded or not, I think it was accurate. Andy has something to say. Sorry to keep you running around. The HCD one is really interesting because there's a specific, that there's a specific won't fix to do with how clients are to use between nodes in the HCD itself. So that's pretty harrowing. If we could call that out and model that and present it back with, I mean, it's not even a recommended control, it's just use the thing. That would probably be useful for everybody. We were talking about maybe sort of kicking this off now. How much do we have enough time to zoom in on a diagram and just see if we can do something? Yeah, I mean, we can do it up here, but we could also jump out into the hall. I don't have anything. So one other thing to kind of mention here is, from the standpoint of the book, usually the things that you're building on or relying on, you can make fairly simple assumptions about. And one of the problems that you're gonna have with Kubernetes here is that there are many different attacker and failure modes for individual sub-components and some of them may have shared interactions with others. So let me give an example here for a minute. Let's say that you're making a car. Car has tires on it. You know that it's really unlikely that you're gonna have a nail that punctures a hole in the tire. It's really improbable. And you say, well, you know, the way that the braking system and things work in the car, even if one of the tires gets a puncture, we're gonna be okay, right? But then somebody happens to drive through a construction site where there's a whole bunch of nails everywhere or some other incident happens that is outside of that random scattering. These kind of correlated failures and problems might require you to peek down lower than the average group or team that's doing a security assessment according to our book. So this is all a very long-winded way of saying like definitely talk to us if there are parts that start to look onerous or other things because they were designed for, the book was written for the 99% of projects and Kubernetes is in that 1% that's gonna push a lot of these things to the boundaries. That's really good to know. And I think it's the nail that punctures, I mean, I've definitely had that happen to me before. So it's like, oh, I totally feel the burn of like that improbable thing that I've totally been screwed over by. So yep, you gotta be prepared. Does anyone else have any other comments, questions, cries of enthusiasm and joy that they want to help and participate? Yes, on this particular thing. Can you repeat the question? Are there any, oh, he was just saying is the scope of what I'm referring to specific to the specific effort, which is threat modeling the vSphere CSI driver. And I said yes. Yeah. One thing I was curious about, I'm looking at the diagrams for the first time as well. When we were doing cluster API, there were a bunch of different flows that the maintainers were talking about where it's like, okay, a new cluster is being spun up. We are doing node bootstrap. We're doing cluster bootstrap. We are removing a node, we are adding a node. Were there different flows identified in vSphere, related to vSphere CSI driver? That Shin was like, okay, I really worry about this particular flow more than the others. And that will help with your favorite thing of prioritizing which one to do first. So the answer is, yeah, these are all of the flows that we have diagrammed. So what I should do is I should send a message to Shin and say which one of these is the most heavily used or which one of these is the most that is, that you're most concerned about for whatever reason. So I think, yeah, from a prioritization and scoping perspective, I can work with her on that pretty easily to be like, all right, you know what? Creating a volume is the most hammered on workflow but let's start there. So I can get a prioritization call from her on that. I think that would be definitely helpful, but just in point. Sorry. Yeah, I started to just like snatch it out of your hand as you were still talking. I was just gonna say that you might actually get more bang for your buck by focusing on a component and all the things that a component can do, like focus on an actor and all the actions. And then understanding, because that will help you understand more about the isolation between them. And that would probably be the place I would start more rather than go deep into one end to end workflow across many components. Awesome, that's a really, really good tip because now I'm just looking at these diagrams and yeah, I think it's really, again, I think we need a shing to weigh in on sort of like, okay, cause you know, it's like the, you know, let's see the, I mean, there's several components in this, but it's like the driver itself, the external snapshotter, like I think so I think it's like coming, you know, asking her from, you know, either a workflow perspective or a component perspective, which do you think is the most useful place to start just based on your knowledge of the system? Great, and I would start with questions like, let's say that you compromise the external snapshotter, what could you and couldn't you do? And I say this a bit in the book, this analogy, but I often like to really start with, oh, well, you can't compromise the vSphere, see something server, you can't do that because, you know, it checks a signature on this and you know, that signature is stored in a key that's here and it's like, oh, but you know, so that means that if you were able to somehow compromise that key from, you know, your external snapshotter that you could do it and it turns out that that external snapshotter happens to have access to the file system where that key is stored. So therefore I've just learned that those two things are effectively the same actor in the system because once I compromise the external snapshotter, I get access to the other one. And I would start with trying to like see, you know, how strong of boundaries are there actually between these things? And even if you only do that for part of the diagram, you will instantly get things out of that exercise whereas going end to end, you'll miss a lot of that. Does that make sense? No, that makes a ton of sense. And again, this is all excellent feedback and input because yeah, like you said, it's like asking that one tiny question forces you to examine the context that a specific component is in and consider who's really interacting with it, either human or virtual, so to speak. Actually, question for you, Justin. So this is a lot of information already, right? With like you said, and this is such good work, like this is the hardest part most of the times. Is there anything else we can ask the maintainers that will probably benefit when we do threat model that maybe is not there? So I like this, but I would absolutely write it out also in the format that we say where you list actors and actions and describe separation between them and describe as I think it was Andy pointed out earlier, goals and non-goals very clearly. And that isn't a binary thing, it isn't that everything is a goal is the end of the world and everything that's a non-goal. You just don't care about it all, but you really want to think through those issues and that part of the writing will be kind of another way to help you visualize it, that'll be more closely aligned with what I was just saying about thinking about actors and how they're isolated from each other is, yeah. Because that lateral movement is a lot of the problem in the space because you kind of get the idea that, oh, if you break into a database, you're gonna get data out. If you break into a compute cluster, you can run a crypto miner, but people sort of miss like, oh, if you break into this one place, then all of a sudden you get access through 37 other parts of the system. Anything else that you thought we could ask the audience and maybe benefit from their guidance expertise? I don't have anything specific. I think I definitely need to read the book and look at it and absorb its contents and wisdom and just quick show of hands. If I threw a meeting on the calendar next week, who would want to attend as a participant in this exercise? I will be there. Grace, Andy. So I'm doing the security pal stuff with a hundred and something students going through assessments. So if you had done this a few weeks ago, I'd be happy to, but I'm sorry. No, no worries. We, you're there in spirit through your book, so it's all good. But I saw someone here in the, yeah, I will get at you at the end of this talk. But yeah, I mean, this is, I think for me, it's also, we don't want a group of 10 people. I think having a group of three to five is great. So it's really a question of like, let's drive that with the four of us. And then of course, we can always ask for a review and other eyes in the community. So Justin and Marina, if you two come up for air maybe in a couple months and we've generated some stuff and you have bandwidth to take a look, like that's another way that you can participate as well. Yeah, and in the normal process that we would go through in tag security, there is a naive questions phase. And once you've completed your self-assessment, which I will give you a spoiler, it will not be done. And you won't realize it until we ask naive questions. But once you've completed your assessment, then definitely reach out to us and we can start to get help through that naive questions phase. And he'll be like, oh, of course, like da da da da. And it will, it'll get refined quite a lot. And we're very happy to do that. I imagine that will be well after the security pal stuff is finished and we'll be excited to do so. Excellent. So one question for folks who are watching the recording, if they're like, I wish I was in the room, could raise my hand and say I want to participate. How can they reach out to you? Yeah, let me see. Let's see. So basically there are a couple of different Slack channels in Kubernetes that you can join. So SIG Security, SIG-security in Kubernetes is a great place. If you want to send me a DM, a la du berry, I'm in the Kubernetes Slack. Also, the SIG Security-assessments Slack channel is the sub project channel. And then the specific Slack channel for this effort is I think it's SIG Security-assessments, vSphere CSI driver. So those are always different Slack's that you can jump into. And yeah, one in doubt, just send me a DM if you want to get involved. Yeah. And if somebody watching is not part of Kubernetes Slack, go to slack.ks.io and then you can invite yourself from there and then join the different channels that I'll mention. So thank you again, Pushkar, for everything that you do and for putting this together and for accommodating my schedule change. And thank you again to Grace for all of your help with the diagrams. And thank you for just this conversation right now. I've already gotten a ton out of this and I'm feeling super excited and motivated to really get this rolling. So again, it takes a village and I'm just really appreciative of everyone who's helped us get this far. So thank you.