Let's get started. So I'm excited to be joined with Netser once again. We, did a webinar not long ago. It went excellent, and we really had lots of fun, doing it together. So we get to do this again. And today, we're gonna talk about, multi vault governance with Akeyless and how, centralized governance access or across HashCore Vault and also cloud secrets managers, is supported by Akeyless. It's a really interesting topic to go over. And, for those of you who weren't on the previous webinar, I will let Netser introduce himself, and then I will go next. So, Netzer, if you wanna go. Yeah. Thank you, Sam. Hey, guys. I'm Netzer. I'm the director of solution architecture, for Akeyless. I've been with Akeyless for almost four years now and very excited to be joined here by Sam, the expert, to discuss this very interesting and very relevant use case for multi fold governance. Yeah. Yeah. It's it's really exciting. I'm I'm really excited to talk about it. And thanks thanks, Netzer. About me, real quick, I am a content creator in this platform engineering space and been doing this for a number of years. I'm also an instructor giving or doing training in this space as well. And and, yeah, I've I worked for a number of companies in the past, HashiCorp being the last one. Was there for about two and a half years supporting HashiCorp Vault, and that's one of the reasons why we're we're talking about this today. And, let's go ahead and get started. So let's talk first about the governance gap. So we'll introduce the problem, and then we're going to talk about the solution. Right? So the first thing I wanna clarify, though, as we go through this, we're gonna talk about HashiCorp vaults, and we're gonna talk about CloudSecrets vaults as well. So when I say vault, it can encompass both Hashicorp Vault and, you know, AWS secrets manager or Azure Key Vault and and GCP's secrets manager and so on. But one thing to clarify as well regarding Hashicorp Vault Enterprise. So some companies sometimes will use something called disaster recovery and performance replication to replicate across regions, and that, in a sense, gives them central governance. But I'm not talking about that use case. I'm talking about the many organizations that are still operating tens to hundreds of HashiCorp vaults all over the place with no replication, Different teams own different environments, and, sometimes replication is costly for them, and it's complex and not justified for every workload. So this is the use case we're talking about where you might have Hashgraph vaults running everywhere. Every team is running their own. And, also, same thing with secrets managers. You know, one team might have their applications running in AWS, and they've centralized or they've standardized on using, you know, AWS secrets manager. So they run with that, and then you're missing governance across all these vaults. So then you'll have these vaults everywhere, as you can see on the screen, in your CICD pipelines, in Kubernetes, in application configurations, and teams are relying on this daily. They've built, muscle memory around it. Runbooks reference it. SRE teams have built tooling on top of it, and it works for what it does. So the the problem is at the governance layer, as I was just mentioning. For example, if if my CSO today comes and says or asked the question, who accessed the database password for the production payment service in the last thirty days, then we're we might go scratch our heads and and go look into the logs of different vault instances and, again, secrets managers, across the board and hopefully find the answer without anything falling through the cracks. So access policies are managed per vault. There's no consistent enforcement model across teams. So in essence, every cluster is its own little kingdom, and the obvious answer might be, well, why don't we just migrate everything over to a new secrets platform? Now on the surface, that might sound great, but that takes time and sometimes not practical, And sometimes even the migration risk alone can kill that project. So the governance gap stays open. So now that we've added the problem yeah. Go ahead, Netser. Thanks for adding you. I can add on to that that we've had Yeah. Discussions about this problem as early as, I think, three years ago with Gartner when we talked about how in in their strategy, they forever foresee, at least for, you know, for the foreseeable future, that those other vaults will remain. Right? They they didn't anticipate that it will ever be fully possible to migrate all of your secrets to a centralized enterprise secrets management solution because some of probably the cloud vendors are the best example. Some of their built in services don't even expose an API to work with anything but their native secret manager that comes out of the bot with the same platform. Meaning you have to have something in your strategy for secrets management that also accounts for other cloud accounts that manage your secrets or other vaults or other teams. It it goes beyond just the list, you know, of the cloud providers and vaults. There's also all the CICD built in credential stores or the Kubernetes secret store and and more and and so on and so forth. So it's something that you must have in in mind that even if you really want to or today you already have a centralized enterprise secrets manager, there will be apps that you can't reach without being able to manage other secret managers. Right. Right. Excellent. Yeah. Completely agree. So, Akilas provides a solution to this. Actually, there's two ways to govern, different vaults without having to replace them. Right? The first one is multi vault governance or MVG for short, and this is how you can manage secrets that physically live in your vault instances but govern them from Akeyless' control plane. You're applying Akeyless RBAC to those secrets. Every read and every write is logged and, audited, and teams are using the Akeylesses CLI or the console or the API, they don't have they don't need to know that the underlying secret, for example, is in AWS secret manager or in HashiCorp Vault. Doesn't really matter. So that's the first one. The second one is the HashiCorp Vault proxy or HVP, and this is for teams where changing tooling is just not gonna happen, as we mentioned. And then using this Vault CLI is what they're used to using it every day. So they can actually point Vault address over to the Akeyless endpoint, and everything works the same, except that Akeyless is actually behind the scenes, the back end, that they're actually accessing. Anything you wanna add here, Netser? Yeah. Both approaches come to solve the same problem, which is a challenge to change the client side. Right? There is a difference between the two approaches with respect to being able to migrate the secret, which is the server side, if you will. Because with MVG, the assumption is that secrets continue to reside on their native secret manager solution from before, whatever that was. It's still living there, but it's just going to be remotely managed, and there's a lot more to say about that, and we will. But with HVP, the assumption is that the secrets were migrated. Now the secrets do live in a keyless. And in fact, the entire back end, all of it does give you the the centralized approach. Right? What we've said initially, it's just centralized everything. HVP does not contradict it. It just means that instead of having to now go through all the client integrations that have changed the integration or changed their API to talk a keyless native API, they can continue to use existing plug ins that came from primarily from community plug ins of Vault, and we know how to translate those ape open API plug ins into the corresponding Akeyless ones so you can continue to fetch your static secrets or even dynamic secrets across different engines, as they're called, in Vault, but different secret types in Akeyless. And this is just a client-side interpretation of the Vault APIs to correspond with whatever Akeyless has to offer that's mostly the same. I hope that made sense for everyone, because I believe HVP is, like, a very interesting use case, but it's always with the mindset of a migration in mind. Right? So eventually, you'd probably wanna switch over to a fully Keyless cloud because it also has our native support. It's part of the advantages of working with Keyless is that our plug-ins are fully managed by us. It's not something I've seen vault community plug ins that someone stopped, you know, working or, supporting three years ago, and enterprises still rely on them and use them in production because that's what they have. They don't have a vendor behind them to help. Yep. Right, to add new capabilities or whatever. So MVG is a bit of a different story. It's where we really wanna focus today to understand how you could continue to govern all those other vaults, and this doesn't necessarily mean it's an intermediate solution. It could, like I mentioned in the in the first slide, it could be that it's just not possible to replace that vaulting solution, and you may wanna keep doing this for a long time. Absolutely. Yep. Okay. So how does the plumbing work? So really briefly with this diagram, I'll explain what's going on here. Let me see if I can make this bigger. There we go. So this is the Akeyless MVG flow, and it starts with the Akeyless CLI or the SDK. And we are going to the goal is to access the, the actual HashCorp Vault, maybe k v store, the AWS secrets manager, Kubernetes secrets. So we go through this, and you can see that it's all governed by the SaaS control plane of Akeyless. So our back audit logs is all there. We do have the Akeyless gateway, which is a lightweight, stateless, and, it it it is the, the our gateway basically to our different vaults out there. So we have different vault, with different targets. So vault target, AWS target, commodities target, and I'll show you this in the demo. And then from here, that is what connects us to the actual vaults, and we'll see a bidirectional sync in our demo where if you make a change inside of a keyless MVG or USC, which stands for universal, what is it? Universal secret connector? Yeah. We've been rebranding it. So MVG is the up to date name. USC was the previous one. There we go. So we'll use it in this webinar interchangeably for now. MVG USC, and this is what allows us to do this bidirectional sync. We can change it here or we can change it here, and we'll see it both in both places. A couple of thoughts here. For the architecture, the Akeyless SaaS control plane, as you can see, all requests will pass through the cloud control plane. So your policies are back, audit logging, everything is enforced centrally before reaching your vault clusters. And, like, again, I need to highlight the role of the gateway. It's stateless. It is very lightweight, and it lives in your private networks. Think we've, I've talked about this a number of times where, as we compare, for example, HashiCorp Vault, their architecture versus the architecture that Akeyless has. I think Akeyless has a much smarter architecture. Because these are very lightweight, you don't incur cost from a hardware perspective where you would need multiple HashiCorp Vault clusters all over the place. You can install these gateways in every private network that you have. Any thoughts on this at all, Netser? No. I think we can, we can, you know what? Alright. I'll I'm tempted to always add on at least I know you I know you always have something good to say. So, almost like an instinct by now. So all I'll say is, while this is accurate, what I have seen, I believe, being having a greater demand for not necessarily using the Akeyless, clients, CLI, SDK, APIs to go through MVG so that you could reach the secrets in the other secret manager behind the scenes. More often than not, it's not so much about the client using a keyless natively, rather having the clients continue to leverage their existing vaults, their existing secrets manager natively without switching the CLI, in which case, obviously, there's pros and cons to each approach. But mainly, we're going back to my previous point, it's a challenge to get the teams to switch. That's typically the hardest part with onboarding secrets management use cases, getting the actual client side, the applications to rewrite the integration or code or whatever it is that's talking to the vault. And if they don't have to change it, and they can continue talking to their existing one. But through MVG, your CISO wanted this centralized visibility across all their vaults and potentially for additional advanced use cases, which again I'm I'm holding them still. I'm I'm not spilling the beans just yet. We have more to unfold throughout this demo. But you will see that you can also introduce governance through Akiva's to those remote vaults. So it comes over control plane, just like you said it, to present for example, introduce rotation remotely or control the life cycle of those secrets. So this would be some specific cases, we have customers that wanted to be able to leverage a keyless client to talk to a behind-the-scenes remote vault, but I think that's the more of the exception, not the rule. For the most part, I've seen customers seek out a solution to manage their vaults without changing their client. That's the real, challenge, typically. And that's actually the meat of our demo today. I'm sure it is. So here's what that's a good segue. So here's what we're actually going to show everybody. We have, five mini demos, and we'll start off with the multi cluster governance. So, I have two isolated vault clusters as if you have, like, let's say, one in one region, one in another region. One Akeyless control plane will demonstrate the bidirectional sync that we were talking about. And this is what I mentioned, the meat of all the demo where we're gonna talk about this exact use case that Netser was talking about where we have, applications that are consuming secrets from, one, from Azure Key Vault and the second one from a HashiCorp Vault. However, we are leveraging and using Keyless' control plane and also Keyless' ability to rotate secrets on a regular basis so that this rotation is actually done, by Keyless and got gets synced over to the other vaults, the Azure Key Vault, HashiCorp Vault. So the application has zero changes. It's using the secrets from its local vault. No problem. However, the added value is that these secrets are not living forever. These are being rotated, and we're we're using short lived credentials, which is what we kinda preach all the time, use short lived credentials wherever possible. So that's the second piece or mini demo. The third one, we're gonna talk about this HVP use case, as we mentioned earlier, where, we're gonna have this, if if a user is still using the native Vault CLI, how can we help them by, getting them to switch the back end over to Akeyless? To them, it's seamless. They're using the same CLI, but Akeyless is giving them the secrets they need. And then, fourthly, we're gonna talk about, briefly on our back just to show you that we can easily deny access to all these scattered vaults all over the place, again, because there's a central location where we are governing everything. And then finally, we'll we'll end it off with just showing you, audit trails, which is always fun to see. Okay? So let's go ahead and get started with this. I will switch gears over here, and this is our Akeyless console here. And first off, I wanna show you the targets, which I think is the starting point to understand how everything gets connected. And the four targets that I'm interested in showing you are, first, the Azure target, and here we see that there is a connection between Akeyless and my Azure instance. Right? So this is a way for Akeyless to talk to Azure, and we'll see how this is the way. It's gonna enable us to rotate a an application registration secret in Azure. There's another one here. This is a connection into a MySQL database. This is a database that's running locally in my Kubernetes cluster, and also my Keyless gateway is inside that same cluster. So everything is local in a sense, so there's no, requirement to open a firewall inbound into my environment. So this is the second connection or second target. And then I got two isolated vaults as I mentioned. There's one we call the back end vault, and this is connected to a vault that's running locally on my computer here on port eighty two hundred. And there's another vault, call it the payments vault, and this one is connected on port eighty two zero two. Okay? So these are the targets that we have defined. And, next, let's jump into the actual items, the actual secrets. Actually, before we do that, let me show you a view from the multivault governance product itself. Just to give you a quick view as to what we've already configured for multivault governance or MVG, here we've got Azure. So we're able to do the sync with the Azure Key Vault. And here, we've got the two isolated Hash four Vault instances that I talked about, and you can see the sync secrets and so on. So with that, let's jump into the, MVG demo here. Okay. And let's start off with the again, remember USC, MVG, we use them interchangeably. So the vault USC back end, this will show me all my secrets that I have in my first vault. So I got three secrets here, API key, DB password, test two. So we're able to discover any secrets that live in my first HashCorp Vault instance, and this is the one here. And you can see the same secrets show up here. Okay? Api key, if I'm interested in actually seeing the value of this one, here's the API key e to e vault rotated. Going in here, I can also view it from Akeyless, e to e vault rotated, which is cool. Of course, I can show you the other vault. This is the second isolated vault instance that I mentioned, and this is the payments vault. And I have a few, secrets as well. Let's say the DB URL, and I have a secret here. And once again, I can see that over here on the Akeyless side, the payments, view all secrets, and here are all my secrets. Okay. So we can add a secret from here. This is showing you the actual two way sync. So first, we're gonna sync from or create a secret inside of Akeyless and call it test three, and then we'll see how that gets reflected over to Vault. So let's call this, I don't know, foo bar, for example. Save that. Okay. So that got created, and let's go over to here. Go back to over here. Test three secrets. There we go. Foobar. So that's cool. And now let's do the opposite. Let's do the other way around and create maybe a new version of this secret call call it Foo two bar two maybe. Save that. Okay. Let's go over to Akeyless, refresh this. We see secret version now is two. And if we go in here, we'll see the value is Futu bar two. Okay. So very simple use case. You can see the two way sync happening, which really covers our first, demo. We're gonna jump into the second one just in a second, but I will let Netser comment if he has any comments at all. Otherwise, we'll move on. I think we can move on. I won't stop your flow unless you want to, I know. Give you seconds to drink. There we go. No. I know you are dying to comment on the second one, so I'll give you the floor here. I'll hold my horses. It's okay. Okay. So the second one here, as I said, is rotating an Azure app registration and also a database password. So I actually have a couple of diagrams to help us along, before we actually demo it. So the first piece is we have the Akeyless control plane with the Akeyless rotation engine, and the first step is we're gonna rotate a secret using the Akeyless gateway, which is the target we saw before, with a service principle that allows us to to to rotate this app registration client ID and client secret, and that is going to, of course, rotate that application. But then using MVG or USC with the Azure KV sync is going to sync that new secret into Azure Key Vault, and so our application sitting down at the bottom here can read that secret directly from Azure Key Vault, and it has no idea what's going on behind the scenes. Everything is controlled by a keyless. Of course, you know, our back, as we mentioned, the rotation is done on a regular basis. For the demo, we're gonna manually do it so you can see it live. But once again, the application is working, seamlessly with Azure Key Vault, which is what it's used to doing. So that's the first piece. The second one is the MySQL database. Very similar idea, but showing you in a different light where there's no cloud in this instance. We have, again, an Akeyless rotation engine. We have the Akeyless gateway that runs inside of my, labs Kubernetes cluster where the database is also living. So the gateway connects to the MySQL database based on this rotation engine on a regular basis. It will rotate the MySQL username and password, and that gets changed. And then that is, it is a rotated secret inside of Akeyless, which then, using USC or MVG, that gate gets synced over to one of our HashiCorp Vault instances. And now, again, the application doesn't know anything about this, but it can read the secret directly from HashiCorp Vault, which is what the team is used to doing today, so they don't need to make any changes, whatsoever. Okay. I hope this clarifies what we're trying to do, and now let's jump into our demo. Alright. So I have a rotated secret here for Azure. And looking at the rotation configuration at the bottom, you can see that the rotation interval in days is one day every day at eight o'clock local time that we're gonna rotate the service the, app registration secret. And before I rotate it, let's take a look and see what it looks like here. So if you can see here the username, the password, the application ID. So pay attention to the user to the password. If I jump into my Azure Key Vault and take a look at the current version, let's show the secret. And I don't know why Azure keeps it so difficult to see here, but here it is. Yeah. One second. Let me see if I can. It was visible for, like, a brief moment. It's a Yeah. Here we go. UA sixty eight q. Okay. So that is the current secret. And then where can we manually rotate it like this just to show you for the demo? But, of course, this is going to be rotated every day at eight o'clock. So let's get this going. Okay. Rotated the secret successfully. I see we're gonna get kicked out soon, so that's fine. I'll re-authenticate. But you can see the password is zed zed u g a q. And over here, if we go back and refresh, there we go. We have a new version. Show the secret value and there you go. Z u g eight q. So we've successfully rotated the secret and now the Azure Key Vault has has done the rotation. One thing I wanna show you finally is the sync. So the sync is happening here to the Azure USC from the Azure USC over to the demo app client secret, which is what we saw in Azure Key Vault. And this Azure USC is over here, and it will have, and we got kicked out. Let me just log in real quick. While you do that, I will mention maybe two brief comments. One is that what we've just seen can work both for existing secrets, which is a big you know, it's a big deal. It's a big part of this. The fact that we're expecting an application not to have to change anything means we have to be able to sort of tap into an existing Key Vault secret in this example. So when you create this sync between Akeyless secret object, like a rotated secret, and the remote secret, you can actually reference an existing secret name on Azure Key Vault or AWS secrets manager or HashiCorp Vault, whatever that is. And then the first rotation or manual update, it doesn't matter, will enforce that now they will actually have the same value, right, from from both sides. And, constantly, the MVG, this little console that you're seeing right now, always gives you the true state that exists in the remote secret. This is important to understand because, initially, this will have existed before you've done the sync. And this is a big difference between some of our comp competition, if you're familiar, because both, actually, Apache and CyberArk, the others, they do offer some equivalent or some idea similar to managing remote secret managers. Right? They've also done that. But at least with Hashi, what they've done, is a one-way sync. Right? Vault secret sync allows you to pick existing secrets from Vault and only push them remotely, and there's no it's not a bidirectional thing. You don't see the result back. So anything that changed, you it you could end up with something like a split brain. You don't really know what's going on. You don't have the ability to constantly govern what's going on. It's like you do it and you forget about it, and you hope things are okay from the other side of it. And this does allow you to see both ends and control it, and I also wanna clarify that with the rotated secret that we have just seen, this is an Akeyless native capability regardless of MVG. Right? So when we did you've probably seen some other demos or videos that we've made here. When we talk about this native secrets management capability that Akeyless has to give, one of the best offerings there is the rotated secrets because, again, the likes of Vault and others don't excel around managing rotated secrets specifically, right, as in as their own object. And this is actually a huge thing because we're seeing that most enterprises today are still trying to focus on this problem. That's currently their main pain point, getting them their secrets to autorotate because they need to do the manual rotations for years. They still do. But now the regulations are catching up to them, telling them the rotation interval has to happen sooner and sooner. We actually have a customer who had to manage thousands of key volts, literally. It's a Fortune ten customer that has to manage thousands of KeyVaults manually and had created invites, calendar invites for each KeyVault owner to regularly like a recurring invite on the calendar to every ninety days change their password, right, on those Key Vault secrets. You can imagine how much time that is because it's not a single secret. It's a single; it's every Key Vault owner, and then they have to do this for all the secrets in that Key Vault. And every ninety days, you know, it's no longer once a year, something you start feeling and dreading even. You probably fear the day you get that invite. Have to do this because of regulation and audit compliance; they're catching up with them, telling them they have to do this. So they've realized that this solution that we have for them is huge because they're able to create those regulations to meet those regulations and govern secret rotation against thousands of keyvaults from a single pane of glass, right, from a one-to-many approach as well. If you need a single rotated secret, if, for whatever reason, it is used through multiple keyvotes, even though it typically would be a bad idea, if you do happen to need to support this, you can. Right? You have this flexibility. And so I think, personally, you know, when when I, as a solution architect, when I present this solution to our prospects and customers, this is the piece I'm most excited about, the fact that you can literally, from a single pane of glass, control and govern and change the life cycle of secrets that are remotely managed or poorly managed, really, because they're just mostly sitting there. And Azure doesn't give you any built in native rotation capabilities. It's always a struggle. You always have to account for the client side that would read those secrets. And in this case, if they had to do this manually, now they can do it automatically. They can set those rotation intervals to happen every ninety days at a specific time. But, actually, when you have this capability, suddenly, the interval is no longer a threat. Right? Ninety days is, like, also a compromise. Right? It's also something you do just so you don't annoy the users to have to do this too often until they lose their mind. So if it's automated, you can do it you can do it weekly. You can do it daily, and it doesn't interfere with the workloads because every time they need the secret, they fetch it from the single source of truth, which for them remains Azure Keyboard without code changes, without client side changes. But this is as you can you maybe can tell, I'm quite excited about this part in particular. So I hope you I hope you can see it. I can I can tell? Yeah. And I think I we have a couple of questions here. Luigi, Netsu, I heard over. Is that a query? No. This is not a recording. We are live. No. Very much live. Hello, Noigi. Good to see you. Ankit had a question. Is there a separate license to procure MVG and HCP? I think there's two different things. Right? MVG is an Akeyless product. HCP is HashiCorp cloud platform. These are two separate. Also, doesn't that mean we can also directly migrate secrets from any legacy vault directly to Akeyless? What do think? Unless you mean HVP and it was just a typo. Ah, okay. That might make sense. So I'll assume it's the latter. Right? That's what you were talking about, both, Akeyless aspects, MVG for multi-vault governance, HVP for HashiVault proxy. So HVP is not another license whatsoever. It's built into the secrets package. So it's the exact same secrets management. It's just another way or interface to talk to Akeyless, but same secrets management, same client count. Yeah. Thanks thanks for confirming now that this is indeed HCP. It's confusing, all those acronyms. Right? Yeah. And you're then asking, do do does that mean we can also directly migrate secrets from any legacy vault directly to Kiosk? Oh, absolutely. Maybe we've kind of skipped that part because it was to an extent, to to me is the first thing I start with is the discovery and migration section. You can see there on the left, where Sam's hovering just a tiny bit above the product, there is a discovery and migration. And we actually provide you with automatic migrations to a variety of secret managers. If you hit new, just as an example, you can see the options. You can migrate your existing secrets onto Akeyless and then use Akeyless either natively, or if it's HashiCorp Vault, then you can migrate it and use it through HVP. Both of these aspects, migration and HVP, entirely part of the same secrets management license. Nothing is new. MVG is its own license, yes, where we look at the the uses per connector. Right? So for Azure, that would be typically corresponding to the number of key vaults you manage. With AWS, it would typically be the number of AWS regions times accounts because each region is its own separate secret manager. And then you're and, obviously, with Vault, it's the number of Vault instances. So this would allow you to to manage all of those remote secret managers or vaults, and we're adding more and more capabilities. We've added Contour just now, as you've seen on the first page, and hopefully within the next release probably. I don't know. You know, this is a recorded webinar. Some of you will see this maybe in a year's time. Who knows? But as of, end of March twenty twenty six, we're about to also introduce a multi vault governance to GitHub. Right? So you could manage also re GitHub secrets across organization, repos, environments. So that's also upcoming, and we keep on working on those things. And the huge advantage is definitely it being a bidirectional control plane, I I think, is the best term I've I've I've heard so far for this. Right? Because you get to see what's going on. You get the visibility, but you also get to control it and change it and regularly rotate primarily to manage the life cycle of those remote secrets. And thank you guys for the questions. Yeah. Absolutely. Keep them coming. Cool. So, we did the first one. Just for the sake of time, I'll move a little bit faster here. Let's jump into the database one, which is very similar to what we just saw. So MVG demo here and the database rotated password. So this is for MySQL. And here is the current password, f at nine j I. And this one is syncing over to the payments vault under secrets payments DB rotated password. So if I go over here, payments DB rotated password, secret, look that up here, f at nine j I. So I can quickly here rotate that. Before that, of course, once again, this is rotating on a daily basis. As Netzer was saying, we can do this really quickly. It doesn't have to be ninety days. Rotate the secret. Rotate now. Give it a couple seconds. That's done. Let's view it. Now it's b s b g over here. Let's come back. BSBG. Excellent. It's been rotated. Again, the application can use it directly. And, again, the sync is happening also inside of Acuitas' USC. So Vault USC payments down here, we should see the exact same secret as well, right here. And this one, b s b g twenty five. And and I can add that for each of those different targets, Vault, AWS, Azure. We have from the existing customers that we have, we keep hearing their needs to refine some of the interface because, eventually, we've tried to create a single user interface that fits sort of all of them. But suddenly, we've had customers say, we wanna make sure that within the Vault's connector, we can see different versions. So you've just seen or Sam opened it. You could see a version drop down. But in some others, I believe with AWS, we had customers that wanted to make sure we onboard also the the tags. Right? You see the secret version here. But they in AWS, they cared more about the tags that exist on the remote AWS secret manager so they could view them in here. With Azure Key Vault, we have something even more advanced if you ask me where maybe if you can even hop hop over to that one. Azure Key Vault, unlike all other solutions here, manages not just secrets but also certificates. Right? Potentially, also encryption keys. That one is a bit more complex. But you can see that for this one next to the title where it says Universal secrets connector, you have a secret option, right, at the top at the top there next to the refresh button, but you can also manage the certificates remotely used on the same Key Vault. Right right now, of course, you you have you only don't have the permissions probably to list those certificates if you get a No. Downstream four zero three forbidden from Azure. But from here, you'll be able to also manage life cycle of your certificates within Azure Key Vault, not just secret. And for those who are more advanced and know Key Vault can also do the encryption key stuff that we manage through a different way with the bring your own key approach. It's a whole other concept. Let's let's put it aside for now. There's too much to to cover anyway. Excellent. Love the color here. Okay. So, let's continue moving on here. I'll, again, speed it up a little bit. We're moving on to the, HVP demo. Right? So if I go back let's see. A couple back here. Native Vault CLI changes. So I have this will go pretty quickly. The key thing here is to change your Vault address to use the HVP dot Akeyless dot I o. And once you do that, I can just run regular Vault CLI commands, and I will actually retrieve secrets directly from Akeyless, although I'm using the CLI or the API to Vault to Akeyless that doesn't know the CLI doesn't know the difference, and you can see the response. It's as if it's a it's vault. And to prove that, if I run vault status, for example, you're gonna get this error because, really, there is no seal status in in a queue in Akeyless. Right? This is it thinks it's Vault, but it's not Vault. And for those who maybe know a bit more about our gateway, we obviously have the corresponding same endpoint on the gateway itself. So instead of going to HVP, Akeyless it would be your gateway address slash HVP. Right? And we've even had a need. Some Vault plug ins have port eighty two hundred hard coded to them, so it couldn't work against, like, a reverse proxy implementation of our gateway that would have, like, a slash HVP and map it internally to something like an eighty two hundred port that we had to expose explicitly port eighty two hundred to the gateway as well so that you could continue to leverage those plug ins directly against the gateway. So that is also an option. Good point. Okay. Let's clear that. And then the last one or the second last one, let's see if this will work. I'm going to what I did here is I got a denied token just to show you that, this is gonna fail, which is expected. What I did is I'm getting an access ID, access key with a role that doesn't allow me to access, USC for one of the vault back ends. Right? So as you can see here, failed to get universal secrets, and we have a four four zero three forbidden. So this is just to show you that our back is running, and it's healthy, and, you know, everything is controlled through the governance of Akeyless. And that's it. Finally, we have, of course, the audit logs as well. So there are audit logs that are visible within Akeyless itself, and you can also send that over to, to Splunk or whatever log aggregator that you might have. Let's see. List universal secret, for example. As you can see here, some of the this is for the demo Azure USC that we're talking about list or get. So, again, everything is centralized, so we can answer that question we had earlier, the CSO that asked the question, who who accessed the database and when and so on. It's all located in one central, place. And with that, any other questions? I think we're out of time here, but we can probably take at least one or two. And thanks for the questions during the the call. Actually, there's one coming in here. What's the impact of rotation on just in time tokens? Assuming your your message may have been cut in the sentence as we see the last but maybe I'll take a swing at at making sure I understand what you mean. The just in time dynamic secrets is something we have purposely left out of scope for multi vault governance because a multi vault governance concept is for the secret types that sit there that have to be stored and fetched, right, from some central repository. If you need to have just in time, right, dynamic sequence is how we typically refer to them within the Akeyless platform, the recommended approach would be to work directly against the gateway, right, skipping any other vaulting because, actually, the dynamic secrets in Akeyless assuming that's what you mean. Again, I'm sorry if I I don't answer your exact question. It's you can still, oh, okay. I see you confirmed it is topic you are after. Okay. Good. So dynamic secrets, because those are more like producer, they're more like issuers. We don't actually have a secret stored as a result. It's only provided back to a client just in time, and then it self revokes. It doesn't exist. We don't even keep a copy of it or we don't save it in a persistent fashion even within our SaaS, let alone with some remote secret manager. So it doesn't really fit this use case for managing remote vaults. You should, in those cases, interact directly with Akeyless with our dynamic secret engines and be able to use just in time credentials, for example, to access a MySQL database or a Kubernetes environment, a cloud environment. You've seen it's pretty long list when Sam was opening it there. You could have seen a bunch of those native examples as well as a custom option you could always set up. If you hit back, you can show the longer list of the of the opt oh, back again. Yeah. That's fine. That's fine. It's all good. There we go. Yeah. We're actually you know, a AI AI AI always being a thing. We've already added OpenAI, and, Gemini is next. Gemini, I I actually never know how to pronounce it. You know? Gemini. Yeah. Gemini? Okay. Yeah. So Gemini is upcoming again, probably in the next gateway if I'm not not mistaken. But, again, this is a webinar. Who knows when you hear this? It's, probably there by now. Yep. Yep. Excellent. Okay. I think we can wrap it up here to respect everybody's time. Unless there's something else you wanna add there, sir? No. Just really thank you, everyone. Thank you for the questions for taking the time, and thank you, Sam. This has been terrific as always. Yes. Yes. Looking forward to the next one. Amen. Alright. Alright. Thank you. Thank you, Netzer. Thank you, everybody. Enjoy the rest of your day. Thank you so much, guys. Cheers. Thanks.