 Good morning. Good afternoon. Good evening wherever you're handling from welcome to the season two premiere of in the clouds I am joined by the one and only Kirsten newcomer security extraordinary to the stars is what I'm going to call you Kirsten The the welcome to the new season of in the clouds as you can see we've you know kind of spruced up the place. Thanks to our Marketing communications team and our new media initiatives team thank you very much for all the graphics and work that we put into this and You know with that. Let's get started with the show today. We're talking about DevSecOps or shifting left or you know improving security posture However, you want to phrase it in your organization It's kind of the way we're going to talk about it And this is a subject close to my heart, but it's much closer to Kirsten's hearts Kirsten Would you like to introduce yourself and tell us how you got involved with DevSecOps? Sure, so Kirsten newcomer director of security strategy for the cloud platforms BU here at Red Hat I actually it's it's been kind of a winding trajectory for DevSecOps I actually have been in the software field for longer than I care to admit. I Have been a system admin a quality engineers a managed a release engineering team done program management product management and Kind of that combination You know and all of that sort of leading into a focus on security and that combination means that I also I spent time at Rational software working on developer tools. I'm now we're here at Red Hat really focused more on infrastructure, but also platforms that support the developer and I worked at Black Duck software for a while, which is all about Securing the application bits and the pre-deployment and so DevOps and DevSecOps has has been something I've been, you know, interested in and watching for a time And and so we'll talk about why DevOps versus DevSecOps phrasing maybe a little bit later as we go along Sure, that makes perfect sense So folks out there in TV land How are you going to refer to whatever the streaming thing is you're watching right now? please feel free to ask questions and Contribute to the discussion. We have no problem answering any questions You may have related to security or shifting left or a culture change in that regard So First question kind of a you know break the ice question is Cheesecake a cake or a pie? Just I just love that So My mother's cheesecake has always been a pie. It is cooked in a pie It has a layer of sour cream cooked on top of it. Oh, wow You know, it's about an inch two inches high at the most now if it's four inches high or more That's a cake. So A waffle answer No, that's not a waffle answer like that actually helps us get to the root of the question, right? Like if it's four inches or higher, it is now a cake, right? Like this is discussions that we don't normally have right? So it's good to know that we can safely land on if it's four inches or higher Got it. All right. Actually cheesecake is literally the only cake I will eat. It's my favorite thing and good stuff that's great stuff So More serious note one thing I've kind of learned along the way Here at Red Hat is that it's rare that coming to work at Red Hat is the first time you've worked with a Red Hat product or Technology or even project? How did you get first introduced to Red Hat itself? Honestly, it really started with my introduction to open source which which goes back to my time at at rational in fact Rational software and developer tools rational used to consider itself the Switzerland between IBM and Microsoft when it came to developer tools And one of the things that Kind of our partnership with IBM led to was an engagement with the eclipse foundation and eclipse IDEs and starting to deliver developer tools built with and for eclipse And and that was my first exposure to open source and it was Fascinating to see how it changed the market, right? It really shifted from proprietary IDEs to open source And then from there it kind of moved into, you know, Linux as the open source platform and Actually, you know rational had been running on Linux for a long time And then just sort of at Blackduck software one of the things that I really enjoyed Blackduck, which is now part of synopsis had a solution for discovering and identifying open source licenses in software packages as well as then eventually they added on open source Vulnerabilities, and I just loved the combination of the technical challenge of how do you identify the software? Combined with all the complexity of open-source licenses, which are just so funky including like there's the beer license Which you know anybody who uses this software, you know must, you know contribute a six pack of beer somewhere somehow So there's just I just love that stuff and and And then also honestly at when I was at Blackduck Tim Yeaton was our CEO For a while and Tim now runs, you know, he'd been at Red Hat previously. He came back to Red Hat and so just had a great exposure to kind of you know, both the Community open source and then what does it mean to kind of actually productize open source and make it ready for enterprise use? interesting awesome, but the the When did you join Red Hat I guess It's funny that you mentioned you work at Blackduck because Blackduck used to give away when we were traveling and going to like trade shows and such And a literal black little rubber duck rubber ducky, right? And so my son's favorite Shower bath toy is the Blackduck. Yeah rubber ducky right now Yeah, so I have a whole bunch of them in my cube in Westford where I can't go right now Good fun. Yeah, the whole office thing. Yeah, so speaking of you know You know offices and such security has classically been siloed, right? Like I remember our security person at one company like literally was in an office in the back of the data center where no one ever ever Walked or went unless it was to go to the bathroom. So yeah, like that's how I've seen You know security kind of classically been treated It's like divorced from the software development process and it's very much like the last checkbox and Maybe it's a good check or maybe it's a go back and do everything again check So why are we changing things now is the big question? I have a couple of couple of things around that and I think you're right, right? So the security professionals have typically been Siloed from the development teams in particular. They may be more connected to operations, but even there kind of it's been more about Defining policies that then the ops team has to implement as procedures and make sure that they meet and when when DevOps first became a thing and in many ways, you know DevOps is a follow on to agile development methodology, right? Kind of trying to again apply some of those same principles, not just to the development cycle But but getting that code released early and often also right DevOps is is about that Security was always intended to be part of that melding between development and production But it did get overlooked in many cases when teams started doing DevOps and Even today in some cases DevOps is seen as something that belongs more to the application team Even though it's it's intended to include ops And so I tend to talk about DevSecOps Because I want to explicitly call out that teams need to integrate security thinking into their DevOps lifecycle So just as the developer the app dev teams need to talk to ops to figure out in that DevOps process How do they ensure they're meeting the resiliency requirements that ops has? You know various configuration regulatory requirements They also need to be sure that they're meeting the security requirements Some of those security requirements are regulatory some of them are internally driven and are about policy And so in addition to shifting security left, right? You mentioned how security often comes at the at the end There's nothing worse for a development team Then getting that security analysis and check at the point at which they're ready to deploy their code And learning that they have to go back and and start over. I mean nobody nobody wants that Yeah, and some of those cycles right like your deployment cycle could be a quarter So code you wrote three months ago. Yeah, could be re-evaluated and you have no idea why you wrote it that way, you know And you know no good for anybody, right? Or there's a you know a vulnerabilities with scan Scan was run and you discover one of your packages has that scan and now you have to upgrade that package It has that vulnerability if upgrade that package to the newer version But that package has dependencies on other packages and so you're not necessarily just updating one package in your application You may wind up updating five of them. And so you wind up having to you know, check your code retest, etc And so it's really like one of the simple useful things folks can do is do Vulnerability analysis scanning in their CI right during their build process Also, even better, right is if you use something like the ID plugins that red hat provides where you can do dependency analysis and Security and get security data in your IDE real time, right? So that even before you check in you can decide you can learn whether there's something that maybe needs to be fixed But at minimum doing it during that build process, right? We always used to talk about the stats, right? How much time does it take to fix a bug that's found in production versus one that's found in test and And this is the same kind of thing, right? Let's fix find and fix security issues as far left in the process as we can Right so like understanding the importance of having a software pipeline is huge, right? Like it's not just handing code off to the next team It's you want some automation between that handoff, right? Absolutely, especially when it comes to cloud native, but not just for cloud native But when we think about containers and kubernetes, right? Best practice is you never patch a running container And why is that? Because a container orchestration solution is designed so that if a running instance of your application goes down A new instance will automatically be deployed from the container image from the pod So if you've patched a running a running instance And not rebuilt your image you lose that fix As soon as the redeploy happens Right So you need your pipeline that dev ops that dev sec ops pipeline to have as much automation as possible So that you can respond quickly when new issues are found at whatever layer of your application they're in Are they in the base image? Are they in your runtime? Are they in the custom code that you're writing the code that's key for your app? You need Automation for building and ideally, you know and again for for security testing But also ideally for you know, qe testing for you, you know user experience testing That's a challenge for some organizations, right? How much test automation they can get in place That can be easier for greenfield apps than it is for legacy apps right Yeah, it's it's hard to put The legacy process into the pipeline, but it is more than worth it. Absolutely can then do What brings us to our first question for the audience is in your opinion Like what is the right order of static analysis dynamic analysis, you know open source There's all these different kinds of scanning tools that are out there now that cover like all these different parts of the pipeline Is there a right order? I mean, is there a preferred order of the way you do your, you know, dev sec ops or is it really up to the team That's it's a really interesting question. So some Kinds of scans make more sense in different places, right? So So that dependency analysis If you can find a tool that will give you dependency info In your ide That's a big win. Um, huge one. Yeah, that's that's big value same for vulnerability analysis But most phones vulnerability scanners, which sometimes are also software config Um, analysis scanners, right? They figure out what packages what what code is in the The blob that you're analyzing And they tell you what those packages are and then they map to known vulnerabilities Those are best run either In your in your artifact repo your container repository, right as soon as you're down Especially if you're using external content as soon as you pull it down scan it Yeah, that includes content from red hat. We'll tell you if we know about vulnerabilities But you should you should do the belt and suspenders scan it anyway. Yeah, right Crossbow verify, right? Exactly. Exactly. So and then those scanners are typically good in the build process, right? So if you can do dependency analysis solutions like sneak in the ide That's a that's that's a great starting point Um, if you and then build vulnerability analysis any type of static analysis scanners have pros and cons, right? There are things like covariate Other solutions that that kind of analyze your code for the quality Sonar cube, you know, what's what's the quality are there things like cross-site scripting? Risks in your code You want to do those as early as possible too and most of those scanners require some tuning So yeah, because yeah, you wind up with false positives, etc So those ideally would be kind of in that ci process as well And then you want for runtime, you know for for dynamic analysis That's in your test environment, right? You're doing you're testing your application As it runs. So so You also in any dev ops pipeline dev sec ops pipeline You want to be sure that you've got a test environment that is What what exact, you know as close as possible to your production environment and that, you know, if you're going to do Dynamic analysis you do that in that test environment along with any automated User acceptance tests things like that and and again one of the values of containers and kubernetes, right is that you can Do some you can have an open shift cluster that looks just like your production cluster your development team your user acceptance team They can have the same environment The same constraints you've got all your system dependencies packaged with your container image And so this simplifies the debug process If something slips through in in your testing and hits in production, but you also you've got that that same deployed environment Um, and then finally you really want to add like oftentimes And I feel like in our conversation. I've been guilty of this when we talk shift left We talk dev sec ops. We think about it as dev sec That is what are the security tools that are useful to the developer And I think that's partly because that's the area that's been neglected But dev sec ops means also sec ops, right? So what are the security tools that are useful in operations For container and kubernetes, right? So you want runtime behavioral analysis. You want things like Uh pod security policies or security context constraints admission control policies that help you control what whether What privileges a container is given when it's launched And also you want processes and gates in place that ensure you're only pulling approved images onto your production cluster So it really is the full life cycle that you want to be thinking about Right, which you know kind of takes us down to You know, how do you bridge that dev sec and that sec ops? mentality together and having them work in you know, perfect harmony in tandem and and I think you know That's a place that is where where things are still um Where the the the community the the software community is still working I think but it's also one of the reasons I'm really excited by red hats recent acquisition of stack rocks Because they have the ability to leverage data collected during the build process right during that they do both Vulnerability analysis, but app config analysis, which is also important, right? Is the Is the metadata, you know for your for your container and your pod or they are are they asking for privs? Do they have embedded secrets that data can be you know, that content can be analyzed and the data collected during the build process and then it can be used to Buy an admission controller That's deployed on the cluster and where you get to say, you know, okay Any pods that have these characteristics may not be deployed to my cluster So that's one of the ways that you you we really want tooling that leverages The data collected early that wasn't you know, if it wasn't fixed Let's use let's make sure that informs our policy for deployment And and kind of have that full circle Yes, exactly. So, you know, we know dev sec ops is important. We know that we want to bridge the divide. How do we Make that divide bridged in the kind of the the cloud native and kubernetes environment, right? Because it's a very fast moving right like if you look at some of the reports from the last couple years, right? Like the average lifetime of a container is measured in seconds Yeah, that kind of thing right like it's almost like containers are reaching serverless. Yeah, kind of like, you know paradigms How do we do that? Like yeah, so what is the good practice there for Making that happen efficiently and I think I have to answer both on the tooling and the people side But also, yeah, certainly there's been some interesting reports about You know that have been published about what's the length of time that that containers run I mean sys dig did a really interesting analysis And I think that they're their average time for the majority of containers In their in their analysis was five minutes. Wow. So at least it wasn't five seconds right I look at that though, and I wonder how many of those are in it containers or You know, how much do and it containers and sidecars affect that average time span? And and I don't think we know yet at least I don't know I'd love to to have a conversation with that team and learn more about the data behind You know that that they collected um That said right we should be assuming that a container can go down and be replaced at any point, right? So One of the things that's really important to think about when it comes to cloud native workloads is to assume that They are largely ephemeral And that means right that when you think about the traditional methods Of securing your environment You you need to think about having both your platform And your applications your workloads be Close to being born secure as born secure as possible And you need to have enough automation in place that when problems crop up because they will You are able to respond quickly and that automation needs to be in place both for the application So the cicd pipeline for your for your app But also in place for your platform, right? How are you managing deployment of your kube cluster? And are you prepared to redeploy at any moment should? Cryptominers be discovered on your platform for example, right? So you really want to take that dev ops approach That is understood to be useful for apps. You want to do that For your platform too. So you want to think about it in a get ops like way Right. Everything should be infrastructure as code. It should be monitored It should be assessed and evaluated and then once it's approved and signed off on I should be able to deploy As you know anytime I want And and so sort of that's the tooling side right and your tooling can be there a range of tools that can help you there You know, there's there's for the apps. There's things like Jenkins and tecton the new, you know, kind of more cloud native pipeline for your operations, you know ansible terraform all sorts of different things And argocd actually is a really interesting new player that kind of spans both of those For a kube environment and so Leveraging argocd is a great way to go to but but store your infrastructure treat your code your configs Treat it as if it is source code, right version it manage it automate automate all of that And then on the people side Back to your silo point We Collectively including kind of the you know, there's the bottoms up in the top down thing and and people Behave in the way they're motivated, right? So how do you help? That security team that has been siloed To become partners In the process of building Your devops pipeline for both apps and infrastructure And one of my favorite customer examples here is a is a team in the federal sector Who their chief of cyber security decided that his team Of security architects Needed to learn the development process and something about the tools that the developers use And that if he couldn't and if and that until they learned that they couldn't be effective advocates for Helping get the process into a place that worked for everybody They they really needed to shift their thinking and and that takes Incentives right for a culture to make that kind of for an organization to make that kind of cultural change You have to have somebody who's willing to support that And help the team be rewarded for for making those kinds of shifts Uh, yeah questions just came in like what tools would you recommend? You know that kind of thing and i'm just going to drop a link just for you know full posterity To the cncf landscape that specific security compliance category Um But what what do you think you know are good tools to run against like prod for example Uh, okay, so I actually i'm gonna um hit this from a and and um You know so so one of the things we do at red hat is is we work closely with our partners to ensure that um The solutions are are certified to run against open shift right and You know and that includes the ecosystem of Security isv partners right and so Um when we think about it, uh, there's there's a lot of different categories to look at And in and and so one thing to consider is um, you know value for your buck right can you get Uh a solution a tool that helps you both with the pipeline and at runtime um, and there are a number of of our partners who who do that Certified partners, you know in addition to stack rocks, which is is gonna is being rebranded as red hat advanced cluster security We also have partners like cystic Palo Alto Prisma cloud solution aqua security pretty much all of those partners have solutions that at a minimum you can use vulnerability scanning in In the pipeline as well as in a running cluster and And many of them have image assurance capabilities just like stack rocks does And then you really want to be looking for i'm going to share for a minute. You want to be looking for Uh runtime analysis capabilities right behavioral runtime analysis Is a great win um open shift out of the box uses security context constraints So we have this built-in protection that prevents privileged containers from being deployed to worker nodes by default But runtime behavioral analysis is a great addition For the production environment And and then you know are there solutions that help you do more with network controls, right? So kubernetes has network policies Um, you have to figure out how to configure your environment appropriately for that There are solutions that can auto suggest network policies to you For you and and that's another way you can also bridge The dev and the production environment, right? If you're running in a in a test cluster And you try out some of those suggested policies that gives you an idea of what do you want to actually deploy with? Um, and then deep audit and monitoring is key, right? So out of the box open shift includes You know auditing is on at the host level api server auditing is on for kube But many of these solutions also add deeper data collection And correlation and and so you can kind of get an idea here Of the partners that we work with the partners that and and again You know the ones i'm going to know about are the ones that are certified to work with open shift But most of them work with other kube distros as well Yeah, that's great. Yeah, we we love the uh tools that work with kubernetes. Absolutely So, you know, I see stack rocks all over the place. I know that there was a Technical briefing this morning about it. Is there anything you want to mention specifically about stack rocks that you think make? Said it apart or it's called red hat advanced cluster security now. Yeah, I I mean Go ahead. Yeah, one of the things I like about it again is that you can see that it's showing up In multiple boxes here Um, and and so we're really looking forward to so it does that deeper data collection Um, it does the auto suggest for network policies. It gives you a visualization of the network policy layer Open shift service mesh visualizes layer seven With with service mesh policies, but with stack rocks you get that network policy layer visualization as well I'm really looking forward to what we're going to be able to do With service mesh and stack rocks together. We get behavioral analysis, but you can see right? We show it We we tick a lot of these boxes Um, and so when we think about that, uh, you know, infinity Arc that that that you see for dev ops or dev sec ops We really feel like stack rocks helps with that and and we're also really excited about the shift left elements Right that we can do that early analysis leverage that data for the the admission control policies And we're going to continue to work with all of the partners here, right? So sneak does the dependency analysis Again, as I mentioned, there are other partners who show up in a number of these boxes And so it's it's not just about what we offer from red hat. We genuinely do believe in choice So, you know, look look across what's available and see what suits you best and some of our customers have Relationships with some of these partners and they're going to want to continue that We also really expect right? We're gonna we're gonna get a lot of value from being able to tightly integrate The red hat acs stack rock solution in with open shift Just because we're now part of the same company that we can do that Yeah, and I have to say that like when I heard the news that red hat was acquiring stack rocks It was a huge relief because I've worked with you know, the various cube contests whatever with a bunch of people for Uh You know that worked at stack rocks and they all seem to be great people So it's not yeah, we're the technology is great and the people are great So it's a one-two punch win kind of thing for red hat. I feel like yeah Let's touch on like How can a developer? You know kind of get buy-in or you know some kind of leadership buy-in that's always hard And I want to touch on that before we jump into the next Section here. That's a it's a great question. I think that You know, you really want That it's it's about the success of the business Right, and so the business cares about getting Capabilities getting new solutions differentiating Innovated solutions out to the market as quickly as possible and ensuring customer satisfaction along the way right, so When you think about Meeting those goals security has to be part of that and the sooner that you can Help the organization address their concern security concerns The faster you can deliver and the better you can you can address customer satisfaction, right customers don't want to have to Update because of vulnerability that has been known for four years, right is present in something you just shipped Right, they understand if it's a newly discovered vulnerability that happens everybody understands that but if you know if the work wasn't done early to assess for Vulnerabilities that have been around for a while and that can happen We've we've seen breaches that have been due to situations like that. There's a fix for the vulnerability. It wasn't applied So It's all about value to the business value to the end user and the customer And if you can help your management Understand if you yourself it helps if you believe it too, right as a developer You believe this is going to make your life easier You're going to deliver more quickly if you have this ability That helps a lot. I I did this was a number of years ago now But I did talk to a customer who The gentleman he's in the development team. He would have loved to do Vulnerability analysis early in his pipeline and his security team was holding on tight They didn't want to give the app dev team access to their security tools That was a really interesting one and so it's like so you so thinking in terms of not just technical But a combination of technical and business value Right helping and helping convince your management and then get your management enlisted to help convince other players That this is the right thing for the business You know it's interesting you mentioned that that case of like the security team wouldn't let them in because that has actually happened to me Like working in the dev ops space, right? Like trying to secure Systems and networks and everything is like well if if you have the nest scanner And I have to come submit a ticket and it takes a couple days for you to get back to me on any fixes I get in can I just get access to the nest of scanners? So I mean like we had licenses Whoa, there's no, you know technical reason to keep me away from them other than You know like separation of responsibilities or duties or something but it's not like Yeah, there's always that like aspect of no, this is this is security's job and no, it's everybody's job Right, so you have to crack open that that culture of security tools or for security people Or you have to crack open your pipeline and tell them insert themselves into the pipeline in certain places And and honestly the kind of thing you're describing is partly why containers became so popular Right with developers Exactly It's like how many weeks does it take me to get a VM configured so that I can do my work and no, they're one of our regulars is You know experience the same thing Is is going around them kind of deal. Yeah Yeah So so what we see our customers doing to deal with that silo scenario typically sometimes it requires executive support Um, but the best thing, you know the most successful teams find a team that they can pilot these changes with Um, and so that they have an opportunity to iterate on the changes work together So you got it ideally you'd find somebody on that security team who's willing to work with you or Maybe you have to you know, bring somebody in to the app dev team who has security background Um, and they can work with you and you do a pilot and you demonstrate the value through the pilot And then you just advertise the heck out of it internally right It's funny, you know, technically I work in you know a marketing kind of function but it's more like a like an ops advocate if you think of like developer advocates It's like I'm an ops advocate kind of deal and I can't express enough how important it is to like Market what you've done better right like I tell people all the time There's a lot that dev ops can teach marketing and there's a lot marketing can teach dev ops because there's so many things And I'm actually doing a talk on it with a couple other folks from the community Like how to market your thing Be it open source or you know, whatever it is you're doing To other people in a better way right like so that you can show people that your pilot is successful In an effective way right like look at actual numbers and metrics and how this could change Velocity or improve user experience right like things that you know leadership is going to care about That's what you should be focused on as far as making sure that You know, you've got that buy-in and then I'd be remiss if I didn't also mention though that Some use some security language right security teams think about reducing risk Right and and so how can shifting security left reduce risk for the organization? Right, we're balancing business value against risk all the time every day and nobody, you know, no ceo. No cso You know no vp nobody in your management chain Wants their company splashed on the front page of the newspaper Right Like that should be a bullet point like we're not going to be on the front page of the newspaper You know like put that in your presentation. Sure. Yeah That's what's going to give vp's attention, you know Yeah, and tony tv points out like language is a barrier of some time So you have to kind of adapt yourself to the language of the people you're talking to That's one of the biggest things I learned when I was on the ansible team on the product marketing side was You know adapting yourself to the persona you're talking to is very important Yeah, it's that that's and and we really kind of had to think about that, you know, as we were kind of re Recrafting a bit of our language You know around how we go to market with our security story Partly due to the stack rocks acquisition, right? We wanted to do that build deploy and run As a key message, but those words, you know, they're great for a dev ops team But the security team is thinking how do I detect problems? How do I protect my environment? How do I respond to an incident? So absolutely language is is a key element and and risk management is another another term They another way that team thinks right they think all about risk management. Absolutely So there's a a change occurring in the security landscape inside kubernetes, uh, and you know, this is kind of a A hot button topic for me right now because we're trying to work on the blog post for this and It's kind of a nightmare. Um, so You know like pod security policies are getting deprecated in kubernetes 1.21 And they'll be fully, you know out of the system out of kubernetes completely pod securities will be gone pod security policies will be gone from kubernetes in 1.25, which should be next year sometime or Yeah, hopefully mid next year What do we do? You know, there's all these You know things that we have to worry about right like but there are solutions here to folks using pod security policies today Yeah, that can put in place now and work on moving psps over into them Yeah, and and I want to start by being clear that the community the kubernetes community Is actively thinking about alternatives, right? pod security policies are not going to go away until Even even though that's the we've got a timeline in front of us They will go away, but with a replacement And so for anybody who's interested there have been conversations happening. There's um, I'll try I might have the link up to the Uh to some of the proposals. There are a couple of if I if I can find it. I'll post it. Um There are a couple of proposals in place for Ways to To replace there's something called pod security plus plus and there's something called The bare minimum pod security policy So I would like the bare minimum pod security Fault to be honest with you And I think that that's that's partly where the community is is thinking right is that so pod security policies are great and open shift uses, you know The uh open shift uses security context constraints, which were kind of the predecessor to pod security policies right pod security policies never fully took off and and the truth is that Both uh that that both scc's and psps have a require a degree of understanding And they have a level of complexity that can create frustration. So they they create this great default protection Angie really kind of have to understand a lot about How you know pod the the security context that a pod can request and you Maybe need to understand Linux capabilities and there's and you know, you know prioritization of these and and so it's it's not simple great protection and and we leverage it It is on by default an open shift. You can't turn it off. Yeah So the community, you know kind of is is leaning towards the concept at least and and by the way sig off Or sig security if you want to participate in the conversation Hopefully, um, you can share the the links that I put awesome to the two different proposals active discussion going on and and Kind of the thinking is that around, you know, we might land on something that says you have at minimum three policies available to you Kind of a red yellow green, right green means that it's the most secure Um, and and maybe that's what's on by by default or but you have the option to use a less secure that would be yellow And a very permissive which might be red, right? And we're also seeing Kind of the rise of an increasing interest in opa gatekeeper as a way to write complex policies And so kind of there's there's the conversation has been about okay a default Built-in set of capabilities that are perhaps simpler and easier to use than the current pod security policies Similar but but simpler and then for complex use cases opa gatekeeper Or something comparable would be the way to go And then there's a debate about can those be used together? Would you use one instead of the other? Assuming we have these default policies. Can we make it Easy for those to be represented in something like opa gatekeeper in case you want to switch to a more complex environment Right, how do you do all of this in a way that doesn't break? What you're already doing or there's there's going to be a migration right no question But but let's say once we've migrated and you're up and running With say the new defaults and now you need something more complex How do you do that? Without losing the protection you've already got and and so there's all this thinking going on about Again, do we you know make it easy to to deliver the same thing in the default as it as also in opa gatekeeper or You know one of the other solutions like caverno is also out there looking at at policy management Um, so the community is thinking really hard about this, right? They don't they don't want to leave anybody behind And they want to reduce complexity for the end user and and the consumer while still offering The ability to secure the environment Yeah, so Please contribute, you know anybody who's interested. Yeah, anybody who's interested. Let me draw up the link to caverno in here, too Come on you can do it the mouse I believe in you Um, cool. So, you know the The the Linux Colonel capabilities of namespaces and all the the fun network ports and file systems everything else you have to manage that To along with the platform Um, there's a question in here. Do you believe that distributions like db and rel have uh A monopoly on the best audits today. I wouldn't say it's monopoly on the best audits um But there's definitely more of them for those two distros right like rel based ones and deviant based ones as opposed to some other ones And and i'm not sure what's meant by audit in this case audit by whom or audit capabilities in in the product right, um, so You know, maybe we'll hear back from the the questioner. Fabio, uh, You know what what you're digging for exactly and and in the meantime, I can riff a little bit So so certainly, you know, I would expect that any of these So first of all one of the cool things about pod security policies and secs is it gives the cluster admin A way to manage access to linux capabilities host network, etc without them having to be linux admins They might need to learn about these things, but they never have to work at the os layer To protect the host because they can prevent access to the host network the host file system with a psp right I think it's important that we maintain some of that basic set of capabilities in the replacement solution We need to give we need to give coob users a way to continue to do that And and again, maybe it's just not going to be as many different factors that can be tweaked In in the replacement, right And then go ahead. There's many levers and all of this, right? That's the only thing I was going to say, but go ahead right and and then the runtime comes into play, right? Are you is the runtime? You know running unconfined or is there a sec comp policy? applied to the runtime That comes into play. That's something that is still separate. I believe from the replacement It's I'm going to make myself a note to ask In our next conversation, you know, how they view sec comp in fact Around all of this and then in terms of the audit capabilities, right? So and and I I just I know well better than debian So it's a combination for me of ensuring that se linux is on And I I would assert that se linux has a broader range of capabilities than app armor, for example So the isolation and the protection provided by se linux is key and again That's not something that has to be managed at the kub layer. No And then, you know, how do you audit the host operating system? Again, it you know openshift 4 works with rel core os which is a container optimized os Does only has the packages needed to run openshift audit d is on by default But yeah, yeah And you can do deeper auditing and so some of those partners that we talked about earlier including stack rocks cystig palo aqua, they deploy Uh an additional capability that does deeper data collection And and some of the solutions do correlation, which is really critical for a container environment where things are coming and going Right. You can't just that that process that was running a few minutes ago might You know might have died as we were saying earlier, right and you've collected data on that process How do you associate that with the name of a deployed pod or a service? So that you know, you know, what's relevant and and that correlation really really matters um And and i'm sorry. I can't say much about debian. I don't know if that's something you can opine on I mean debian has a a good set of auditing capabilities. It's You know, it to me the difference, you know coming from my, you know Linux admin Moving into red hat kind of area, right? Like I've always felt like sc linux has always been there for me if that makes sense Right, like where app armor is a little newer. Um You know, I I remember reading about sc linux, you know, I'm like the year 2000 so um, it's been, you know developed rather heavily by a lot of people at this point and I think uh You know given that we're on a red hat channel, you know, where else probably going to be the better choice Uh for everybody In my opinion, um, that's just my opinion, right? Yeah And I'm interested. I mean it looks I just did a quick google, right? So there's audit d also available with debian And and I think what we also start to hear coming up more often is Conversations around ebpf Again for that deeper data collection, right? So That's definitely a space red hat is is You know stack rocks is already there red hat will be doing investing more in that space And so, you know, when it comes to debian, I'm just going to google again and see pf, you know um You know is is that already part of a debian distro? So but but ebpf is is is something definitely worth looking into Absolutely, and I'm trying to find I know there's a ebpf book that someone sponsored at some point and it's free somewhere But I can't find it. I'm sorry, uh, but there are a lot of great Like brennan brennan greg, uh, if you haven't been to his website Definitely recommend you check out brennan gred's website because it is just Full of knowledge All things uh ebpf and he's actually written a book about it. So cool that link in there Yep, and there is a ebpf.io website as well. Right. Yes, ebpf.io Well, actually, you know, that's for sale now. Oh, I typed it wrong that math. Okay I'm looking at it It's like I know she I know she wouldn't tell me no I typed that wrong. Anyways, so yeah ebpf gives you like a deep look at the sys calls and everything going on Underneath the hood kind of deal and that is if you want to do a lot of tooling or a lot of tweaking That's a great place to do it So, you know, we're kind of wrapping up here and we got about seven minutes left, you know What what would you say in the security realm? Keeps you up at night, right like from your perspective. What is the thing that you worry about the most? Um boy, you know, I I think um Really, it's I can't so I assume that there's going to be Unknown, right that this thing's going to come up that none of us predicted and and so It's not so much the The unpredicted that keeps me up. It's more, you know, the organizations that I haven't yet Found a way to update their processes To at least do the basic That kind of is what what really concerns me, right there They're maybe not yet structured in a way to make it easy to update vulnerable packages or even be aware That they've got vulnerabilities in their environment. They're not yet Doing the appropriate level of security for identity and access management Um, you know, they're they're they've been so so I it's it's really again You kind of need that belt and suspenders approach and there's always going to be something unexpected So I I really do worry most when people aren't even using a belt Right exactly, right Why are you still using string to hold up your pants? There's this invention called a belt, right the It's and that to be honest with you. It's the it's you know Not to pull a full down around shell here, but like there there actually is unknown unknowns in the security space They're called zero. They're called zero days So we we have to be constantly vigilant of these things and you know If you go back and look at the struts to vulnerability and the whole story behind that it was literally one person in an organization patching all their stuff as fast as they could because they found this vulnerability and That whole story is just fascinating But that was a zero day and a lot of people were using struts that virginal struts is still being used by a lot of people And that's the scary thing to me is that a lot of people aren't doing that dependency scanning that is so important Um, what do you as far as misconceptions about dev sick ops? What do you think are some of the the misconceptions people have about it? First they they think that they can just add a tool and it will fix everything. Yeah, that's right So so even though I've talked a lot about vulnerability scanning and we've talked about dependency analysis Tools aren't enough right, so so you have to incent your team to You have to give them time to respond to what those tools tell them Right and and it's like they're in you know, I've been in organizations where developer productivity is measured by the number of lines of code They deliver. Oh god, that's such a bad metric. It's terrible. Oh It's terrible. You're asking for vulnerabilities of that. That's right. So So don't don't measure your team on that right and don't measure them on The number of vulnerabilities that are found You know the first time you scan Like yeah, yeah, measure them on how quickly they can respond Um, do do things like that. So so and You know or or how many tests, you know, the effectiveness of tests, right? Also, are are you testing the right things? Um, you know, it's it's not about how Necessarily how quickly again you have to balance the speed of delivery with meeting The customer goals and the customer goals include reasonable expectation of security, right? So So balance those two and you've got to think about how do you help? Because people respond to how they're measured, right? So yeah, exactly. What's an what's an effective measurement that will help your team Do what you're looking for So let's end the note. Let's end the show on a high note. Uh You know, you work here at red hat you're you're in the cloud platforms business unit like I am You know, what gets you up in the morning? What what what motivates you to come in and work for it every day? I just love the opportunities in front of us and and the fact that we're able we work with so many terrific companies and customers across such a wide variety of industries Which creates the opportunity to help them tackle really interesting problems that make a difference in in the world, whether it's healthcare or energy delivery or you know Telco, I mean, there's just this really fascinating set of problems as We help our customers move into a more cloud native world and and we get to be there working with them on the fork front and figuring it out and and helping them on that journey And it's a great deal of fun and we have it's and it's such a great group of people to work with too so Oh, no last question and then we're going to wrap it up. Um Do you think there's a lack of qualified professionals in the dev sec op arena? certainly It's hard to find qualified security folks, right and they're expensive So invest in growing them right give people a chance to learn um build a bench right and and you know, if you've got somebody on your active team who's interested in security Help them get training and and they'll be able to understand both sides of the puzzle, right? So exactly exactly Well, thank you so much for joining us today kirsten. This has been a wonderful episode and a lot of great Uh conversation and chat and things that we shared with everybody. So I really appreciate you coming on the day and thank you Thank you everybody and the audience for watching and participating And we will see you again here and uh, there's some stuff coming up So it'll be a couple few more weeks for the next uh in the clouds episode but Later on the channel today, we will be talking about claire four and Woo-hoo container scanning. Yeah, like the it's going to be an awesome episode It's actually the series premiere of cloud native thursday's here Uh on open shift tv and that'll be at uh 1 p.m. Eastern 1800 utc. So come check it out when you get a chance So again, thank you to kirsten. Thank you to the audience. Uh, stay safe out there everybody and we'll see you soon Thank you. Take care all