 All right, can everyone hear me? Okay, cool. So we haven't been able to find Rob this morning, but I figured we got some folks here, so we might as well at least have a fireside chat type conversation. So obviously I don't have a deck or anything to share. He may have had some really good content. But yeah, so my name is Major Hayden. I work for Rackspace and I do a lot of security related work on our OpenStack deployments. And so I've worked a bit on the security guide, which is a big chunk of documentation that helps you deploy OpenStack in a secure way and also secure the OS that's underneath OpenStack. So there's some other projects within the security team, especially around Bandit. I don't know how many people have heard about Bandit. Okay, so long story short, Bandit gives you the ability to do basic checks on any OpenStack project. So if an OpenStack project is maybe importing a library that has CVEs or maybe it's importing a library that doesn't do things quite well, Bandit will give you feedback on that and you can use it to kill a gate job or something like that. It also looks for some basic things around, like if you're starting a shell improperly in Python or if you're taking variables and just dumping them straight into the shell, which is really bad to do, it'll look for those as well. And there's a few other projects that I'm not familiar with. If anybody knows of any, you can just shout them out or anybody, there's the other one that's Centrobos, Centrobos, I can't remember if anybody uses that one. So I figure we can have a little bit of a chat around OpenStack security. So we can pretty much open it for anything that anybody would like to discuss or I could try and go on about some of the other good things that I've seen lately. So there's been some developments as well in Keystone and I can't remember exactly what the part of Keystone is but there's almost like a little sanity checker in Keystone now that will look at your configuration and try and figure out, are you using tokens in a bad way? Are your configuration files or token files or anything like that are stored on the system with bad ownership or bad permissions and things like that. So I think if more projects could start to adopt that, it would be helpful. And I know within OpenStack Ansible, we've added that to our gate jobs. So if for any reason someone adjusts code and maybe it deploys Keystone configs with ownership set to 777 or something, it will kill our gate job. And so that way, none of that, hopefully less of that stuff will slip through. And so in the security panel the other day, we had a good discussion and some of the discussion there was around projects talking more about security and how they could work together on those things. So if you're a Nova developer, you might go to the Keystone team and say, hey, how do we use tokens better or how do we maybe check these tokens better or how do we find a way to get people authenticated more quickly or anything like that? So with that, what exactly would y'all like to talk about? Does anybody want to share anything or do you have questions about security within OpenStack? Oh, okay, so the question was, you're doing a lot of work at the Layer 2 level, like WAF, I'm just repeating it so make sure you get to the video. You're doing a lot of work at that later and you're wondering if there's OpenStack projects out there that are involved in security. So you're saying securing web servers that are inside of a VM, inside of a guest that a tenant is spinning up? Oh yeah. Yeah, so along the same thread of firewall as a service. That's a very good question. And that's something I know, there's been work done in Octavia around the load balancing to be able to handle some of the SSL offloading at that layer. So there's some there where you actually have something between the user and your actual web server on the backend, but I'm not really familiar with anything else. I do know that in the OpenStack Ansible realm, we have a security role that you could go ahead and use and apply to tenant VMs as well. So if you had a tenant that says, hey, I'm doing WordPress, you could say, okay, well, apply this role when you get done installing WordPress, you make sure you have those things covered. So that's a good point. So the comment was stacking different neutron networks so that way you can actually get a little bit, get something in between just doing some listening or ideas or yeah. I think that's one of the big challenges. I've constantly heard that one as well where it's like, I've got a tenant that has a myriad of VXLAN networks and how do you get in between some of those and make sure that when the web server's talking to the database server that those are the queries that you expect and they're coming through in the way that you expect watching out for SQL injection and probably your web server should never say select star from passwords. So you could always pick up some of that kind of stuff. Although it could do that but I don't know if it's a very well written application at that point. And a small plug if you wanna hear about the OpenStack Ansible security stuff, I'm doing a talk on that at 11. All right, what else, anything else? So one thing that did come up in the, we had a documentation fishbowl the other day and the security guide came up in there and I've also been talking with some of the folks from Red Hat about things that they wanna add to the security guide. So if you haven't checked out the security guide it's pretty awesome. It's in the main documentation repo and it talks to you about, hey, how do I set up Keystone tokens and what the heck is different between UID tokens and a Furnit token and which I've called Furnay forever and then I was told I'm not supposed to. And so you can go through there and it says, hey, when you're set up Nova here's how you set up your virtual machines and why should you enable SE Linux or App Armor which the answer is yes for all those. And it goes through how to set up all that. It goes through how to set up Neutron, how to be very careful about how you allocate networks and I know the folks at Red Hat are doing a lot of work on industry and government certification in the rail OSP cloud. So they're looking to find ways to not only use hardening standards to harden the OS that's underneath the cloud but then also almost create like a hardening standard for OpenStack proper more than just the OS. So how do you deploy Nova and Libvert and KVM and Neutron and all these things in a way that is secure. So if you haven't ever contributed the security guide that is an awesome place to get started because you may find some things in there where maybe there's an alternative way to do it or maybe you think, well, hey, no one's ever gone in here and talked about security for Trove or for databases. Okay, well then go in there and write it up. There's someone who's going to come along later and benefit from that. And then also speaking on behalf of the deployment projects like OpenStack Ansible and Cola and all the others, we use that guide as well to make sure we're adhering to the best standards out there. So yeah, the security guide needs some love in a few ways and there's one argument that we were having. I know the Red Hat folks and SUSE folks and I were talking about how do we get some more vendor specific information in the security guide? So how do we get it to, you know, this work that Red Hat is doing to go ahead and certify OpenStack and almost create a hardening standard for OpenStack? How do we actually get that into the security guide? It's going to be vendor specific, which is a little bit weird. So, you know, Red Hat would want the freedom to improve that but yet it's out in the open. Same with SUSE and I'm sure Canonical will be interested as well. Yeah, if you're just coming in, the main speaker's not here so I'm winging it. So if you want to have an active discussion in a fireside chat, yeah, he's like, no, I'm out. All right, so what else? Anything else security related? Does anybody want to know how to get more involved? So IRC is helpful. The OpenStack dev list, there is a security tag that's used on occasion. So that's a good place to get started. I think another thing is just be involved with the projects. So, you know, if you're really involved with Neutron or you're really involved with Keystone and you have a security mindset or security is a large part of your job, go to those meetings and just join in. And if someone suggests something, you think, man, there's like a better way to do this or there's a way to make it more secure or a way to make it where you may have a particular, you may have a particular development team that works at a pretty small shop. And if you work at an enterprise level, you might go in there and say, hey, wait a minute, at a small shop, that would work great. But if you go to an enterprise, it's a non-starter and here's why. So I think having those conversations is really good. And it really takes understanding how the projects are operating and where they're going. So, all right, I completely agree. So yeah, the comment was around more documentation and more help and understanding how to do key management and then do you pick BarberCan or do you pick Vault or do you pick both? And then depending on what you pick, how do you implement it? I think that'd be fantastic. And if you want, that would actually be a good documentation bug to open up for the security guide because if that's not already in there or if there's not already a link that goes to BarberCan's docs where it explains that in more detail, that would be awesome to have. Okay. Yeah, so the comment was around the project map that Terry was sharing. I can't pronounce Terry's name right, I try. I know, I'm from Texas, so I mispronounce everything. But yeah, no, I think if BarberCan's gonna be the de facto, then I think we've really gotta have some solid docs around that and solid implementation. And I think it's more than docs. I think it seems like for key management, it's so easy to do it wrong. There's like 1400 ways to do it wrong. There's like three ways to do it, right? So, and then of course any key is as good as your management of it. But yeah, I think that would be good. So you said the BarberCan session's coming up in like 20 or 30 minutes. So, Volvo versus BarberCan. That would be an interesting one to check out. I may have to add that to my schedule. So, I guess the question is like the assessment of multiple projects security-wise with the status update on that. So I don't have a status update on that. I'm sure Rob does. But we did talk about this a little bit at the panel the other day. And I think some of that is going forward and I think that's where some of that keystone where it came from, like that little sanity checker. But yeah, I think it's, there's got to be more conversations around it. There's got to be more cross-project involvement. And I think it's probably on some of the projects who are a little bit more security conscious. Well, not security conscious, but security focused like Keystone or BarberCan or something like that for those folks to reach out into the other communities and say, hey, we would love for you to change the way you do something and we'll come over here and help you do it and help you test it. I think that's really the big thing is people popping up out of the community that they normally work in and going into another one that is related and then saying, hey, look, we'd like to build a bridge and our bridge will be built on security. So I'll say within OpenStack Ansible that's been really helpful. Because we found like, what right before the OCOTA release came out, the NOVA team released the NOVA placement API and that was kind of a big surprise. And so we had to kind of join up with that team for a while and say, okay, like help us understand. What's this for? Where does it go? How do we secure it? What information does it hold? That kind of thing. So I think it really requires kind of reaching across the aisle and to those other groups. Anybody want to talk about Essie Linux? Well, I guess if there's nothing else, we could probably adjourn and my apologies to Rob for butchering the session. Anything else? All right. Well, it sounds like we should all probably head down to that barbecue and talk probably in the next 20 minutes or so. All right. Thank you all.