 I'm looking in the chat window for and there goes Chris short with his go. We are we are go time here once again. This is the open shift commons briefings operator hour show. My name is Mike wait for my hat. Hello. How are you and thank you for joining us today. Besides the fact that I have a blinding sliding glass door behind me. Apologize for that. I just I don't have any other options where I am right now. We can talk about that later. We are lucky enough to have with us Jody Hunt who's the SE director from cyber arc and Dave Muir good friend of of all of ours dialing in from sunny floor to this morning. He's the global solutions architect for security. Isb is how's it going fellas. Great. Terrific terrific. I I may have a little bit of on the on the line as I as I mentioned I'm up here and my summer cabin on a lake and that is being fed over over a pair of copper phone lines. So I apologize for that. But hopefully you folks have a little bit better internet than I do being in a more modern you know. Modern place. So Jody. Tell me about yourself. Are you are you into car racing. I see it looks like a race car seat. I've just got a gamer chair because I spent a lot of time in this chair. So I want something that's ergonomic and comfortable. I mean it's literally has seat belts on it or like shoulder straps. I mean what what kind of well that's that are you worried about getting thrown out of your seat. No I just you know how it is it's been a lot of time in a chair. You want to be nice and comfy. No I you know that's something I haven't done. I'm actually sitting here in an oak or green wooden chair. I never got the memo when COVID came that everyone was going out ordering really nice chairs and you know nice work from home desks. I missed that memo. So now that the virus is starting to slow down. I think I'm finally going to join the club and get a good office chair and a proper desk though. Well get one that doesn't sink on you. This one I keep having a pop raise back up every every couple of hours. Throughout so my house down home and mass I threw out my chair about a year and a half or two years ago just because of that. It's like literally you're on a call and it's just going just getting lower and you like come on. Yeah. Yeah. So tell us about yourself. What do you what do you do Jody. I am what's my actual title is DevOps subject matter expert within cyber art. We're folk. My role. There's others like me. Our focus on helping customers understand our solutions for secrets management. So most of us have some kind of development background. A lot of times we're working with developers. We need to need to know how to code need to know walk to walk talk to talk. But I've I've had a ton of different roles. I've been I've been a biz dad guy. I try my hand at sales. But it turns out I like the technical role the technical sales role is what I like best. So let's start doing the recording is on. Yeah they're part of a French big French company. So I have some friends of it. But yeah that's that's kind of how I went up at cyber art. And and it's been awesome and cyber making hefty investments in this space. Cyber has actually been securing application credentials for more than a decade. But but the use cases around as we're going to be talking about with OpenShift today requires a different architecture different approach. And so there the initial architecture that they built for long running applications didn't really scale or support. The dynamic nature of container orchestration, cloud platforms, serverless functions, you know, this kind of thing. So that's that's really why they bought conjure. Okay, well, that's cool. We're we're we're happy that you are here with us today. Dave, how about you tell us a little bit about yourself and and hopefully, you know, bring up some family photos or any other content that you prepared here for us today. Yeah, you bet. I could show it might take the whole hour. I've got five kids. So I've got actually, I remember that when you were working at synopsis, right? Or maybe even when you were at Black Duck, I remember being over at your office. And I think we met there in person or in Boston somewhere. And you mentioned you had five kids. I'm like, how do you get your own hockey team? Well, basketball right now, we didn't go for the hockey team. Thank goodness. But, okay, families up up there. Actually, you can see him. But no, I appreciate Jody being here in cyber arc. I work at Red Hat been working at Red Hat now for over a year. Primarily focused on security ISVs, our partner, our great partners like cyber arc have done a lot of stuff with cyber arc and did a couple webinars with Jody and some workshops as well. Got a very nice demo workshop capability that we put together over the last year. If you go to demo.openshift.com, you can, you can see the cyber arc entry in there as well. But some of the viewers may know, let me just share my screen here that this is part of an overall security series that we've created. A monthly security series. We're naming it DevSecOps is the way where we've broken all the months up into various security categories. We actually built a framework around DevSecOps starting with these categories and then taking that a little bit deeper and I'll show you another slide real quick. I only have two slides, I promise, but to identify specific capabilities or methods within these categories. And then mapping that into a DevOps pipeline and then taking our partners and putting plotting them on that pipeline alongside Red Hat to show how the joint solution looks and works together and it's been a pretty good tool to start conversations with our customers and with our partners around DevSecOps and helping them do that journey. So we decided to put a sort of content series together every month where we're doing, we're actually doing two OpenShift TV shows. We have another one tomorrow, by the way. And then we also publish, try to publish three podcasts every month and then we're trying to do blogs and other webinars and things like that. And you can see the categories on the right there and this month is May, the identity and access month. And so we're excited that CyBark is a part of this. You could learn a ton more on that URL red.ht DevSecOps and yes the D and the S and the O need to be capitalized to get to that page. So that's our monthly series. And then just from a CyBark Red Hat perspective, here's that pipeline I was talking about DevSecOps solution. It might be a little bit tough to read if anybody's interested, I'd be happy to send a copy of this. But at a high level, you can kind of see how Red Hat and CyBark complement each other on the on in DevOps and DevSecOps and each point like IDE source code build automation, there's specific security methods that you want to think about in your journey to DevSecOps. And of course, Secrets Vault authentication authorization is in CyBark's wheelhouse and they've got certified containers with us and can install nicely on OpenShift. We'll talk more about that. Just a very good partner and a very good fit to really complement what we're calling a comprehensive DevSecOps solution. Okay. Very, very good, Dave. And while you're going over your slide number 58 there, I decided to try and spin my chair around and get a different view because the glare from the slider was just absolutely driving me crazy. So I hope this is a little better. Much better. Oh, good. Good. Now I just have to, next time I'll just have to check for guns and automobile parts and things. Anyways, great. Okay, so Jody, you've been at CyBark now for quite some time. You folks have security software. Dave is a global essay managing software vendors who do security. For the lay person like me, isn't security security? I mean, how many different security vendors do we need out there? Right? I mean, is it end point security? Is it like network security? What exactly does CyBark do? I mean, I know you guys are publicly traded and I think you're trading at $110.60 a share this morning. You guys look like you've been trending up ever since 2016, which is really great. So whatever it is you're selling, it must be working for the market. So can you tell us about how you're different from somebody else who says they're a security software vendor? Yeah, well, fundamentally, we're about privileged access. And so that's, that's the core business is securing the access of users that have elevated privileges. So typical I am solutions are for the rest of the organization that needs access to email and applications and things like that. But your system administrators or DBAs, the folks that need elevated access, that's really what CyBark's built its business around securing that. And then it's morphed into a lot of other things. So as I said, we've been doing application secrets management for over 10 years. End point privilege mentioned. So keeping people from being administrator on their own laptops is a core part of the business now. And we're really now focused on identity, securing identities and just assigning identities using a zero trust model and moving forward with that. We acquired a company a little over a year ago called adaptive, which is a really single sign on solution. And that that starts getting at that sort of zero trust dynamic access just in time sort of access for for identities. So, so that's really where we what we do with applications as well. Every application that needs a credential needs to be authenticated. So it needs to be assigned an identity. It needs to be able to authenticate in order to just for us to know who it is. And then what it has access to. And so it's really, you know, an identity is an identity as far as we're concerned. It doesn't really matter if it's a person or a process. It needs to authenticate its access needs to be controlled through role based access control rules. And then it's it's access needs to be audited. So we know what when it's retrieving those secrets and and, you know, what basically what it's doing with it. Now we add onto that we do secrets rotation. So we manage the secrets so that they're not just statically vaulted. We're rotating them both in the vault and in the systems that are being accessed. So we can rotate SSH keys database passwords tokens, just just various things. And so it's a very extensive platform. We have 100 plus connections to target systems to manage those those credentials. And so that's been, like I said, at the core part of the business is the vaulting of the secrets. And the part that I focus on is really the non human access to those those systems. And just writing down some notes here I have I have all kinds of questions that I want to that I want to. Drill our victim here with today, but I do want to mention that we are live on YouTube and Facebook and Twitch. And so if anyone who's joining us from any one of those channels or the bridge here, if you have questions for Jody or Dave or or Santa Claus, go ahead and put them, you know, in the in the chat box there. And our bots will make sure that the questions get transferred over to here and we'll get those questions addressed for you live in Michael. I was just going to add, I think what Jody was saying just to recap is now you can get rid of your post it notes with all the passwords that you have. I got it. How did you know? I mean, it's like, honest to God, I mean, I people who've watched the show before know I've been here, you know, I'm as old as dirt and I've been here for 21 years, but it's just getting worse and worse and worse. You know, Red Hat has single sign on which is doesn't really seem to mean anything because I seem to be single sign on in like 20 or 30 times a day. And every password is different. And I honest to God, I have a notebook where I write everything down and you know what makes it worse is when different systems are like, oh, you have to automatically change it every six months and then you can't reuse. I don't need to bore you guys with my problems, but how does cyber art fix that? Like, can you seriously fix that Jody? Can you make that go away? Well, you know, there's a difference between the desktop user password like last pass, you know, that's a classic example of a desktop user vaulting platform, call it a personal vault, if you will. What we're really about is are those the secrets, the enterprise secrets that really matter that give someone access to, you know, a database in production, for example. And it doesn't even have to be DBA access. It's just if an application needs to connect to a system that matters. That would be a credential. We would say it belongs in our vault. And A vault certainly, but our vault, you know, for a lot of reasons. And then we would manage that. So the purpose is really to relieve the user of a secret from needing to really know what that password is from an application perspective. The application retrieves the secret when it needs it. And it simply uses it to connect to that, that target system. So we don't. You know, at least in the applications perspective, it's it doesn't have to remember its own passwords. Okay, that that's cool. Is there and we're going to, and you guys have put together a demo here, which is going to be somewhat technical in nature for our audience. So we're going to, we're going to be getting to that here. I'm just looking at our, at our schedule here. Are there workloads that are more susceptible or is there is cyber arc vault? Is that the main name of your product, right? Cyber arc vault privilege access security privilege. Are there certain types of workloads that are more susceptible or that are that take advantage that benefit more from what you folks have to offer? I mean, it obviously it sounds like like cloud native distributed databases like, you know, like you go by eight or, you know, cockroach DB or anything like that. That's probably like a prime example of where cyber arc fits in really well, right? Well, we certainly can solve some of the newer use cases. A lot of what we do is still the classic on-prem oracle database, SQL server databases, things like that. Those are, you would be amazed how many, how many of those passwords are not under management or they're being stored in various places. So, so that's the, the number one, basically the state we see in most organizations is secrets are being stored in a lot of what we would consider sort of haphazard ways. So there's no, yeah, there's, there's like no lack of places to store secrets, but they're not actual secrets management. Every tool. You know, Jenkins openshift has secrets. Well, we'll talk a bit about Kubernetes secrets here in a bit. So it's not that people are being careless. It's just that the solutions they may be using aren't necessarily up to what we would consider adequate standards. We advocate thinking like an attacker and so understanding how secrets can be exploited or discovered and exploited is a big part of what we educate the market on. I think the SolarWinds breach really opened folks' eyes to the susceptibility of the DevOps pipeline potentially getting compromised. And because that was really how the SolarWinds breach happened was, it was a DLL that got added to the product in the development cycle and in the packaging cycle. So, so that's, you know, securing DevOps pipelines is a big part of what we talk about. Hey, when you, Jody, you use the word pipeline and I keep thinking of gas shortages and the nowhere attack on that pipeline company. How did that happen and would cyber archive prevent it? I mean, obviously it's a pretty generic question, but I mean, that was, that was amazing to see an entire pipeline shut down. And the effect it had on the entire eastern part of the country, if not probably the whole country as a result, but like, how can that happen? And were they not managing secrets or like what? Yeah, I haven't, it's a good question. I haven't studied that one to know the exact vector that they used, but there are remarkably easy vectors that can be exploited. And that's a big part of what we do is, is the education of just, you know, there's, there's classic attack vectors like passing the hash, golden ticket, compromise it. They just, just very standard things that a lot of organizations still have left those doors wide open. And so if, if somebody's been careless or just hasn't been paying attention, then it's, it's not so hard for, for an attacker to get in and take over the network. Or in this case, it was, it was a ransomware attack. But yeah, it's, it's, it's one of those things where one of the reasons I got, I wanted to get into security is somebody once said it's the problem that will never be solved. I was like, well, that's, that's a good place to be because, and it is sort of like an arms race, you know, as soon as you shore up one, you know, attack vector than others open up like we were just talking about with the DevOps pipeline. Okay. Well, enough of my prying questions. I know that, that I think you and Dave put together a demo here to, to talk show, show the technology. I think it's running on, on an open shift environment. Yeah, let me do an appropriate open shift TV. Let's, let's show a little bit of open shift. So this is a right. This is a tab that Dave and I put together for to show how, how secrets can be accessed from pods running an open shift. And so it just goes through, we're all about providing options. And so some people want to use API some people don't want to use API is going to actually show you how to make the, the actual Kubernetes secrets or open shift secrets more secure. We'll probably promise to get this high, high ish level. It's going to be technical, but we'll try not to, to get out too much. I was going to say, is there going to be a, you know, is there going to be a test at the end? We could, we could have a test if you want, if you want one, but I, I didn't prepare one. So, but I, I could ask questions. That was actually Mike wait rumor. I guess. Anyways, I'll shut up and I'll, I'll, I'll let you to take over here. Yeah, and Dave, you know, feel obviously chime in. Whenever. Well, I was just going to say, I mentioned this earlier, but for those who missed it, if anybody's interested in learning more about this demo, if you go to demo.openshift.com, you'll see it there. We can even do workshops. So we've, I know Jodi's done a lot of workshops already on this. But we've got it set up where we can stand up a workshop pretty quickly. For those who know about Red Hat, we have a product demo system and cyber arc is now in there. It's really easy for us to stand up the infrastructure around for this workshop. The lab guide is here, Jodi showing it. And so just let us know happy to do happy to do a workshop in your location of choice. I think this is your video right? Yeah, there's a little 10 minute video there. So, for those like me who don't have a long attention span, it's just perfect. This is, and like they said, we've rolled this out. And so I'm actually running the lab in the red. This is the thing itself. I ordered it earlier today. So it takes about 40, 45 minutes to get fully stood up. This is any Red Hat solution architect has access to this. What we're going to show is just various ways of retrieving secrets from pods running in opens here. So this is really from the developer or the pod deployer perspective. We'll talk more about this, but this kind of gets at what I was saying before is that unless you're actually using a secrets management system, the place you're storing your secrets probably could be improved upon. And so secrets management is a term that really came about 4 or 5 years ago, but it wasn't wasn't really a thing until at least wasn't called that until then. And so, so the idea is, you know, you absolutely positiveness should not be embedding your secrets in your source code. But as soon as you take them out of your source code, where do you put them? So you're using Jenkins, maybe you put them in Jenkins credentials. And Kubernetes or OpenShift, maybe you put them in Kubernetes secrets. But even then, you know, Kubernetes documentation calls out the risks that are there. So point being that if you base 64 encode something that's not encrypted. And so if you check a manifest in with a secret that's based 64 encoded, they're saying you basically have compromised that secret. They're not even saying maybe checking it in means the secret is compromised. So these are the kind of things that we're a educating folks on and be showing them a better way. And that's really what this, this lab is intended to do. This is C running in AWS. This is the instance that I had provisioned earlier. I'm logged in as the administrator, but this has the ability to run in a multi to support multiple users. Each user has their own namespace, has their own, you know, basically sandbox to play in. So if we look at the projects here in the cyber lab project, we go to the developer perspective there. We see there's a MySQL database right here. And then what's called the DAP service node. Conjure Enterprise last year was known as Dynamic Access. Thankfully, we renamed it. But when we built the lab, it was called DAP. But that is basically the manifestation of this service. So the idea is this is a service that can be accessed from basically anywhere in the extended enterprise on-prem, in the cloud, multi-cloud, Kubernetes, DevOps pipeline. So the idea is that there is a single system of record for secrets, which would be our vault. But the secrets in there can be accessed through local representations of that service. And that's really what this DAP service node is. If we click on this URL here, then we actually get taken into the Conjure UI. And so this can show us the, actually, there's a very long password that goes with this. I'm not going to log in here right now. But it gives us the ability. Can I ask you a question? Please. Maybe I missed this. I hope I'm not being rude. But what is Conjure? I thought that your, I thought it was called CyberArk Vault. Yeah. So Conjure is that startup that I was at that got acquired by CyberArk. So Conjure was really focused on those newfangled use cases that came about with automation and cloud about you. So the existing solutions that CyberArk had addressed a certain segment, mostly on-prem long running applications. But as containers and cloud and serverless functions and things like that came about, a different approach was needed. And that's why CyberArk bought Conjure. So the company was called Conjure. The solution is called Conjure. You can really think of it as a way of extending the reach of the vault into these use cases like we see with OpenShift. Perfect. And so that's, so basically all the secrets are going to come from here. This is a service that's running in the cluster. And so the applications will access that. So what I'm going to do is go over to the user one namespace. We can see that there's a container in here called LabAdmin. If I look at that from this perspective, I'm just going to go to workloads, projects, user one, workloads. So you can see we've got multiple users here. Each of these users has their own project. I go to workloads and go into my LabAdmin pod and open a terminal here. Now I've got a terminal in my LabAdmin. And this is where the user one lab directors are. So these are just various ways of deploying applications, various ways of doing authentication. I'm not going into a great detail here, but basically we take care of the product takes care of authenticating for the pod. We provide a small container that authenticates the pod so the developer doesn't have to. And the whole goal here is to remove as much friction as possible from the secrets management experience. You don't want developers motivated to try and work around the security best practice. And so the 1st example here, generate the YAML and deploy the app is where the authenticator is running as a sidecar. It's continuously refreshing and access token that the application can use to connect to that database. So in every 1 of these examples, we're retrieving the credentials for that MySQL database and then using that to connect to the database. So if I exact into the pod, we look at this script here called MySQL REST. So this is simulating an application that wants to connect to that database. So we see that the MySQL client call here, it's going to use the host name, the username and the password. The username and the password are being retrieved from that counter service. So we pick up that token, these are the names of the secrets here, MySQL username, MySQL password. Make our REST calls to the service and this is just using a straight up REST call. And then getting those secrets, we each very carelessly leak those secrets. This is, this will, we'll get at something we'll talk about here in a bit. And this is actually called out of the Kubernetes documentation. The applications still need to protect the value of the secret after reading it from the volume. So even the Kubernetes secrets, the application can carelessly log it. So this is an example of that. But we're basically showing our work and then we connect to the database. So running the script, we just get the secrets, show the secrets, connect to the database. And I can say show databases just to see that. So we've now connected to the database and that's the whole point is we've gotten the credentials. The credentials are managed by CyberArch. But our application is able to retrieve them dynamically and use them. And in this case, use them, we're retrieving them with a REST call. And some people just want that API experience. Some people just feel more comfortable with that. But we're, like I said, we're all about providing options. So we have other ways of doing this. So for example, we can go into this example here and generate the YAML. And I think you can see what we try to do is make the lab easy. But if we were doing this in an actual workshop environment, you'd be coaching folks to actually issue the OC commands to do the deployments. And so they get a better sense of how this actually works. Do my deployment here. And this actually uses a solution called Summon. And Summon is an open source solution that we provide that will inject secrets as environment variables. And this is, I like to show this just because Summon is a cool little product that solves a lot of problems. So it can pull secrets from different back-end systems. It doesn't have to be conjured. It doesn't have to be cyber art. It can pull secrets from AWS secrets manager or a local key ring. So it's just a way of sort of insulating the application from having to know where secrets are coming from. We look at this script here called MySQL Summon. We see that the application is no longer making REST calls. It's just accessing environment variables. But these environment variables don't actually exist in this environment. We grep for environment variables beginning with DB. We see that the only thing here is that host name. So the username and password aren't there. Summon can be used to retrieve those. And I won't go into the detail mechanics of it. But Summon basically retrieves the secrets for the application, calls the application with those secrets and those environment variables. So the application can now echo those secrets and then use those secrets to connect to the database. So this is called secrets injection. It's a way that we can integrate with tools that we can't change to make REST calls or to use our APIs. And this is just a very generally useful tool. You can go to GitHub. I think it's github.cyberock.io. So this is here, cyberock.github.io slash Summon. Lots of detail there. Just a cool tool that's generally useful to keep applications from having to know where their secrets are coming from. It helps you keep those secrets out of source code. So that's that second lab. Typically, if I was doing a demo here, I'd be pulling for questions. Any colorful commentary you want to make here, Dave? No, I mean, I think, and I don't see any questions. I don't know if Chris has any questions, but so far it's been pretty clear for me. Well, of course, you help me. I've been through it so many times. I think you've seen this before. So this third example is where we really say, okay, and in fact, three years ago, I was showing that Summon example to an OpenShift admin. And he said, well, why can't you just push the secrets to OpenShift secrets? Because our applications are already built to use OpenShift secrets. And we actually thought that was a pretty good idea. So that's what this does is it allows the application to use OpenShift secrets as native OpenShift secrets. But it solves these issues. It solves at least a couple of the issues. Certainly this issue here where if the secrets in the manifest as a base 64 encoded value, it's not encrypted. It's basically exposed. You look at our DB credentials, YAML here. This is my Kubernetes secret. So we see the kind of secret name is DB credentials. There is something that's base 64 encoded here, but it's just the database name. It's not really a secret. We're not really worried about that getting exposed if we were to check this manifest in the source code. But we see down here this ConjureMap. So this is a YAML array where the key is going to be the name of the secret. And then the value is going to be the current value of that MySQL username and password. Same one that we've seen before. Now we're not making rest calls to retrieve this. This is being done for us, for the application, so that when the application goes to need secrets, they can be made available just like any OpenShift secret has environment variables. So if we grab here now, we'll see more than just the DB name. We see the username and password as environment variables. So these are mounted from the OpenShift secret that we've dynamically patched with these values. So before the application runs, we patch, we update, basically update the secret to provide these values here. They can also be mounted as a volume, which we prefer. We would recommend you mount them as volumes. But if we look at the secret volume password, and I'm technically just sitting on its own line, we see the database password. So at this point, they're just Kubernetes secrets. They're just OpenShift secrets. You can use those native secrets, but you can also eliminate that security risk that the storing basics of foreign coded values in a GitHub repository represents. So that's the third example here. The last example starts to get at that thing that I mentioned earlier that even the Kubernetes documentation calls out. The application has to protect the value of the secret. If the application leaks the secret, as we say, to a console, to a log or something like that, the application has exposed that secret. That's a risk that can happen even if the developer doesn't have any sort of bad intention. And that's really where a solution that we developed called Secretless comes in. So generate the gamble for that. The idea here is, what if the application never got the password if it just got the connections to the database? And so when I deploy this app and it's running, it's creating, it's running. And go in here now. I'm going to look at this MySQL Secretless script. And we see here now, there's no environment variables. It's not even accessing the database hostname that we saw in the environment. It's not accessing the actual database service in the cluster. It's accessing the database as if it were listening, as if for a local database. What's really listening on that default MySQL port is the Secretless broker. And so what it does is it intercepts that call. It invokes the handler for MySQL, retrieves the MySQL credentials, establishes the connection to the database, and the application interacts with that database as if it were connected directly to it. But what it's really doing is going through that broker. And so this is sort of the ultimate in protecting that secret because the application never gets it. So when I run this here, now what we'll see a slight pause and then it connects to the database. So it's sort of magic because the application doesn't have those credentials still using that same MySQL client. But now I can interact with the database without the application ever getting the secrets to leak, hence the name Secretless. So that's just a quick tour of the labs that we go through. We would typically go into more detail around what's really happening around authentication, how does this really work, differences between the net containers and sidecars for the authenticator, things like that. But that's not really what we're here to talk about today. We really wanted to just give you a sense of what we're trying to do as a company in terms of making secrets. As I said earlier, reducing the friction involved in keeping secrets ephemeral, vaulting secrets, dynamically retrieving them, and making that process as simple as possible for the folks that are developing applications. Yeah, that Secretless lab is my favorite, being a former developer. And it's actually the one that I focused on in that 10-minute video that I did. So very, very cool lab. I always chuckle because when I first learned about Kubernetes secrets and navigated to OpenShift to where you can see the secrets, I was like, oh, this is great. Nice secrets are taken care of. But then you can click a little I button and it shows the actual value. Yeah. I'm like, wait a minute, that can't be very secure. Yeah, I used to use a browser. I'm going blank on the name. That showed and it actually shows containers and shows the connections between the containers. And it's the same thing, a brand privileged and you can click on the container and see all the environment variables. Even the ones that were mounted us, you know, just from Kubernetes secrets. So yeah, so we. Netscape. Netscape. What was it? It was we've scope. Used to use that a lot in my demos because it visualized what was going on. Yeah. Yeah, I don't use that so much anymore. But yeah, it's, it's, it's one of those things where, you know, until you've really paid attention to it. You start finding these things. And that's why, you know, we advocate thinking like an attacker. It's like, okay. How could somebody get up these credentials if we're not vaulting them. Rotating them regularly keeping them a family. There's, there's a lot of things we would say goes into just basic good security hygiene. I have. Go ahead, Dave. I'm just going to say, you know, we've got about 15 minutes left. So if anybody has questions, feel free to shoot them in any chat platform you're on. But I think, I think, Mike, Michael, you may have some questions. I've got some questions. And I think it's, I think it's probably already got answered with the conjure acquisition, but let me ask it again. So. How has security changed. Did you just drop your car keys, Jody? No, that's my dog. Oh, so how has, how has security changed as a result of like distributed computing, you know, containers, orchestration, Kubernetes. So it sounds like you kind of answered that already a little bit, but I mean, so presumably. Based on what I infer cyber arc used to be on premise only with the, with the orchestration of Kubernetes requirements and microservices and containers and service mesh and everything else. You folks acquired conjure and that provided you folks that the necessary technology to then kind of expand into multi cloud. Is that, is that accurate? Yeah, yeah. I mean, and when I do my full presentation with all my slides, I like to point out that security. Security is not just for people anymore, but it always starts with people. People are very well vetted typically before they're giving given an identity in. In a network, you know, so that you have to provide 2 or 3 forms of documentation people to do background checks, you know, so. So people are very well before they're given an identity in the network and then you have passwords and to your point, you have to change the passwords on a regular basis have to have a certain level of complexity. So you want to extend that. But and people deploy applications and, but more and more people are building automation using things like Ansible to, to deploy infrastructure. So, so now people are delegating their privilege to processes and those processes in many cases have the same root level privileges that the person did and developers are some of the most privileged privileged users. In a network, because many times they are able to create new infrastructure and then deploy the applications and they have root level access and then they delegate that access to processes. So that's the real problem that we're focused on is securing that whole chain of trust from from developer to to automation and then on to applications. And that's that I think is, you know, what what DevOps has really brought about in the last 10 years, you know, automation itself has really increased the attack surface, if you will. And as we saw with the SolarWinds breach, you know, that that is now, if it's not secured, it can be vulnerable. I think what we've got, are we there, meaning like, you know, there was there was there was Unix then there was Linux and, and, you know, then there was KVM and Zen and virtualization and then OpenStack kind of hit the street and OpenStack was like the shiny object and one of those those conferences it was like, this is going to be the is going to be the end all be all and then containers kind of came out and became more mainstream I mean certainly containers are new right they've been around forever. But with the Docker technology that came out they became easier to manage and or and so forth and then and then containers kind of went away and Docker, I don't even know if Docker con is still even a thing. But, you know, and here we are Kubernetes, Kate's right. So is this it are we like, or is this going to be the shiny object for another 18 months and then there's going to be something else. Well, I think if technology show us anything, we're never going to be done. There's always going to be the new thing at one time service oriented architectures and and web services so XML, all of that was was the thing. That looks pretty anachronistic at this point, you know, there's still a lot of applications out there. So, so if technology show us two things one is it never stops. And you never get rid of it. It's like what you have. We, you know, that's that's one of the ways that we differentiate ourselves is we still secure mainframe applications because people still have mainframe applications that need to be secured. We could do never do the application circuit. Excuse me. Yeah, so I was saying that you're never going to go away. Yeah. And now, you know, serverless functions, people are deploying more and more service functions where, you know, there's there's no container per se. It's just the thing gets fired up when it's needed. And then it's not there anymore. But if it's doing a database query, it needs to be authenticated and it's going to be credential stacks that database so we can secure those. So, you know, we if and when there becomes a technology that that our current solutions don't address, then we'll we'll be able to buy that solution. We had, we were trying to be really well prepared for this call and I remember reaching out to your marketing people and I said, hey, you guys got to give me like, you know, 10 softball questions. You know, if, if Jody Dave and I kind of run out of things to talk about, I can start just reading off the, the boilerplate buzzword, buzzword bingo questions, but I don't think we're going to need to get to those thankfully. But I would say if, you know, when the when we when we hang up, well, maybe I'll say that one for later. We don't have a war story. Like we're working on doing this virtuals, we're working on putting together a virtual event. It's going to be, I think in July or something like this and I'm going to invite software partners to come and be be a part of a panel and say, if you got a story and you want to be part of a panel that is going to be called something like you won't believe it when. Right. So like what is, is there anything that you've absolutely just been completely dumbfounded by when you're working with a customer like I can't believe that how do people not step in it? Like what, what can you do in advance to help people not go down some path that's completely going to, you know, cause an unmaintained one for them? Well, you know, we would always say 1st, the 1st step is getting your secrets out of source code. No, no hard coded secrets. And that's. You know, that's job line. There's still a lot of clout. Those secrets never get rotated because then they have to recompile the application. So, you know, there, there, there may be long running applications and they not even have the, the, the knowledge to know how to rebuild that application. But that's, but that would be the 1st step, I would think. The 2nd step, like I said, as soon as you take it out, where do you put it? You know, where you store it in any vaulting solution is better than that. So, don't just put it in. Don't put it on a post it note. I was saying earlier, don't stick it on your, don't stick it on your screen, but also, you know, don't put it in plain text in a file somewhere. Use a key ring. There are native vaulting technologies that are better than, than, you know, putting it in plain text. But I would seriously say, you know, look at, you know, there's, there are open source solutions out there. Easy ways to get started. What we hear more and more now is we just want 1 vault. This is mostly what we hear from the security team. But security is always going to be on the hook no matter what developers are doing. If there's a breach security is the 1 that has to answer for it. And so this, this is where we're trying to enable that collaboration between. The consumers of secrets and the security organization. Enable the security organization to manage those secrets. And as I said, multiple times now reduce the friction on how. Users can consume those secrets. So, that's going to ask you a question about that, Jody, of course users would only want to have 1 vault. Isn't that like obvious? So it sounds like it's not. Well, do you see is. Sorry, we've got this lag is we'll just, we'll just keep talking over each other. Apologize. Do you find that different departmental teams. Go and deploy their own technology that they find and that you end up with 12 different vault tools in the same organization. You do people will use the solution at hand. Jenkins has a place to store credentials as well as a place to store credentials. Actually, red hat built a very nice integration to 2 of our secrets management solutions for ansible tower. But ansible open source, you know, it in secrets, we have a plugin for that. But the, even if you standardize on a tool, but each project has their own vault. Then it's very hard for the security organization to know how secrets are being used. Each 1 of these is being maintained by an organization that may or may not be using best practices. And, and that creates its own set of problems. So. So, no, it's the 1 vault is not the norm. It is it is the norm. You know, Syracuse a pretty large presence in the fortune. 5,000. I mean, we're kind of a de facto solution for securing human privilege access. The, the, the DevOps space, what you call secrets management space. It's it's newer. And so that adoption cycle was not right. Of course. Hey, do you mind, Jody, you mentioned the ansible integration. Can you just talk a little bit about that and what that does? Yeah, the ansible tower integration is, it's very slick in that basically you replace. A credential with a call to a credential retriever. So, so you build a, a special kind of credential. That's a conjure. Credential retriever it is the thing that retrieves the secret. So it has an identity. It's given an identity that can authenticate conjure and retrieve secrets. There's also a similar implementation that uses our central credential provider, which is a little bit older technology similar to conjure, but. But a little different. But the idea there is you don't have to go and change on your playbooks. What you do is you change. A hard coded credential and an ansible credential with that's that credential retriever. And it takes as a parameter the name of the secret to retrieve and replaces the value there. So it's very easy just to substitute hard coding credentials. In your ansible credentials with that call to that credential provider or credential retriever. Excuse me. Yeah. And there's some webinars on that subject as well that we've done. Yeah, I mean, if, if we were if we wanted to, you know, I just literally shut down my tower. But. But yeah, that's that's something that we demo a lot, especially to red hat customers, obviously. Very nice. It's a fascinating space. Oh, please. Yeah. Just one follow up question about the whole concept of disjointed security teams, but just I find that amazing. You know, we were talking about different vaults and different teams just deploying whatever how do is that a problem with really big fortune 1000 companies or is that. Mid market companies or is that like SMB's where they just they're just kind of winging it by their by their bootstraps. I just I find that incredible that that the fort that if you tell me that, yes, it's like the biggest of the big. That that just seems like a major flaw inside their it planning. Well, I guess that secrets management was really only became a thing about 4 or 5 years ago. So, so this has. It's been exacerbated by by automation, but it's existed for a long time. We've helped a lot of those fortune companies secure applications, but these newer use cases came about so. It's, I think it's just technological evolution, you know, the state of adoption, the best practices become more commonly known and organizations put initiatives in place to start consolidated. We saw the same thing with with cloud adoption. Originally developers went to the cloud because they couldn't get. They couldn't get access to servers fast enough. So you had shadow it phenomena. This is this is very similar. It's kind of a shadow it. Phenomenon that that security organizations have. That now become sensitive to and are taking steps to address. Okay. I'm going to throw in 1 question here just to when we get off this this show here. I want to prevent that phone from ringing on your desk and having your, your manager or your director marketing call you and be like, Jody. You were on there for an hour. Like, why, why wouldn't you have just said the following? So is there is there something that you want to share with our listeners here that will prevent that phone call from happening? Well, let me let me just take a second. But but I've said, you know, I, I, I do things like this. I talk about that. This is my job. You know, talking about this stuff. So I've hit most of the major points. Yeah, I would just reiterate that our goal is to reduce that friction and power the security team to deliver a service that can be consumed as easily as possible by by the users of secrets. But those secrets are managed by the security team. That's really the goal. We've we've got various ways. One of the things that that we see as a necessity there, you know, talking about the cloud and the sort of immediate gratification you have with cloud platforms. Developers want that same experience for their secrets. So as a self service model is really imperative to in reducing that friction developers don't want to have to wait until somebody gets around to provisioning their access. They want, you know, fairly immediate turnaround or at least visibility into that that that process. So so that's that's things that we've helped our customers build. We're working on how to provide the widgets. Every the beauty of this space is every customers process. If not every projects DevOps process is a little bit different. And so there's no there's no one way of saying this is the you can't be prescriptive about how people do their DevOps. And so we've got to meet folks where they are and help them secure the pipeline that they've already built. But but doing that necessitates that we be very flexible and and how we how we deliver that. So, well, thank you. Dave, you put up our call to action slide. We have less than a minute left before our producer is going to start. Slacking me so anything here you want to highlight? That was that today or to me either or. Yeah, Joe to go for it. Well, I mean, these are these are resources. Many of these are are either, you know, cyber arcs, red hat page or red red hat cyber art page. That's that partner ecosystems. That second section there, the joint white paper that I think that's when you and I worked on, right? That's right. Yeah. So, as you can see, Dave and I have collaborated on multiple fronts here. There's some links there links there to the open source solution for conjure. So it is available as a single node open source. Solution at conjure.org secret list is also part of that and summon those are all 3 open source solutions right now being the name and open source. We like to call the attention to that. And then then the documentation, our, our enterprise documentation is online at docs.cyberac.com. You look in the left column 3rd box down as the. That it's still using the old name application access management dynamic access provider, but that is conjure enterprise. So that that goes into all the details of the, the, the open shift integrations and many things that I haven't talked about today. Great. Well, I'm pretty sure that the, the, the stream switched over at the top of the hour, but. This is going this recording is going to be post produced and then. It will be republished back onto Facebook, YouTube and our LinkedIn site. So it's good to get this on there. So. Jody from cyber arc Dave Muir from red hat. Of course, thanks for joining us today. I know that this was this was very informative and we'll look forward to catching up with you soon. Awesome. Thanks to the opportunity. Love working together. Great. Take care.