Welcome everyone to our demo of Akeyless versus Legacy, the next generation of sequence management. I'm Marian Brand. I'm here with Sameh Khediri who's our who's our customer success director at Akeyless. And, he's going to, give a quick recap of our last webinar and then, launch into the demo. So, Tommy, please take it away. Alright. Thank you, Miriam. Sorry. One little housekeeping, matter before we Yeah. Before we start. If you have questions at any point during the webinar, please put them in the q and a section, and we will address them at the end. Go ahead, Fran. Alright. Sounds good. Thanks, Miriam, and welcome, everyone. My name is, Fami Kaderi. I lead our customer success team for, North America. And today, I wanted to continue on what we discussed, in the last last session that we had, which was, talking about legacy solutions and the, modern approach to managing secrets. Where we left off last time was around, the issues that we see with legacy solutions. So we categorized them in three categories, scalability, resource overhead and cost, and then developer effort and friction. And so with regards to scalability, you know, with legacy solutions, you have on premise faults. Those on premise faults are limited in their scaling capabilities. So for example, you would need to deploy, you know, if you're in a multi region, multi cloud environment, or even a hybrid cloud environment, you would need to deploy multiple clusters, and you need to manage high availability across all of those regions, and you need to deal with how you're going to share secrets, and you're you, you know, and you need to manage all of that. Right? So, scaling is challenging as your environment grows, but also, managing the additional cost both in, resources and, in infrastructure. So, you know, legacy on prem solutions, you know, generally have high maintenance cost, because, they need to be managed by these by the team. Right? So you need to have dedicated teams, to manage these specialized systems. They need to apply patches, version upgrades, etcetera, and this can consume quite a bit of time from, from your people. Additionally, there's also the infrastructure costs that you need to maintain. Just to give you an example, I was working with a retailer, and the retailer has, peak seasons. Right? Things like Boxing Day and Black Friday and, you know, all of the holidays generally where there's peak shopping, happening. And so what they needed to do was to build out their infrastructure, to be able to handle the load for those busy seasons. But the load is not consistent throughout the year, and so what ends up happening is there's a lot of infrastructure waste. They're overprovisioning to handle for peak, you know, the the peak activity, but the majority of the time is not being used. So underutilized or wasted infrastructure, costs as well. And then from a developer effort standpoint, you know, legacy systems slow down innovation. There's development bottlenecks like waiting for security approvals or complex integrations. And so you have developers that are looking for workarounds, and so they choose to, operate in, you know, sort of a siloed siloed environments, to be able to move, quickly on their objectives. So what is the solution? So from an Akeyless standpoint, we solved the scalability issue with our SaaS first platform. It's built in a multi regional, high availability. We offer automatic scaling, on demand, so that the burden of managing scaling is taken off of the, user's responsibility. And then it's a unified platform. So for think of it as any type of, any type of authentication, you know, whether it's a user or a machine, identity, we're offering a three hundred and sixty degree view, across all of that. And so, we're providing a unified, consistent approach in how we manage, authentication and authorization across the board. From a resource overhead standpoint, again, it goes back to being a SaaS first architecture. So you don't need to deploy, expensive, difficult to manage, infrastructure, particularly if you're hybrid or multi cloud. From an Akeyless standpoint, you just need to deploy our gateways, which are stateless Docker container. And, this reduces the infrastructure and management overhead costs significantly. And, you know, some of the, customer metrics that we were able to collect, we're hearing upwards of seventy percent cost savings compared to self hosted solutions. And then from a developer, effort, standpoint, we integrate with a variety of CICD tools. We have robust automation and and secretless capabilities, and we're built for the modern, modern cloud workloads. So, what I'll do now is go into the demo and just walk you through how that works. But before I do that, I wanna cover briefly how how this is, enabled on our side. It is the Akeyless gateway. So think of the gateway as a proxy to our SaaS platform. It's a stateless Docker container that you can deploy on Kubernetes, which is the recommended approach for production deployments, or you can deploy it in Docker. You can also deploy it on a on a Linux machine. I've seen it run on Windows. So there's a lot of different modes of operation for the gateway, including what we call, what we we call serverless, gateway that you can deploy on, Azure or AWS as well if you don't wanna run any infrastructure whatsoever. But, the gateway is a proxy to our SaaS platform. The gateway can be deployed on prem, can be deployed in the cloud. And by default, the gateways talk to one another. Right? So, you know, think of use cases where you need to share secrets from one environment to another environment. It's seamless in in in a queue list through the gateway network. And if you have environments where they need to be isolated and segregated, you can, through RBAC, segregate one gateway from the rest of the environment. You can also go a step further with what we call, zero knowledge encryption, which basically cryptographically isolates one gateway from from the others, by deploying what we call a customer fragment. So when you enable zero knowledge encryption, it isolates the gateways, so that, you know, let's say you have a PCI environment and you want to keep everything in that PCI environment segregated from everywhere else. You deploy a gateway with a customer fragment that only that gateway has and no no other gateway shares that fragment. The other, use for the customer fragment is it ensures that a keyless that doesn't have access to your secrets. Even though we're providing the solution, we need multiple fragments to be used at the same time. One of the fragments which lives on the customer side, we don't have access to. Right? So it gives you sort of the best of both worlds, the ability to leverage the ease of use and the, you know, the the, a SaaS platform that, as well as, as well as, knowing that no one can access your secrets except except you or those, you've authorized to access your secrets, not even the vendor. And then the gateway also supports things like just in time dynamic secrets, rotated secrets, also migration from other platforms. If you already have a secrets management tool, solution in place and you want to migrate those secrets from that existing solution to Akeyless, The gateway also facilitates that. The other thing not mentioned here is, high availability. So the gateway performs caching as well. So let's say, you know, you one of your applications needs access to a secret. Without caching, typically, the secret gets pulled from the Nikkila SaaS through the gateway and then deliver to that application that needs it. When you enable caching, the gateway can detect when it's in offline mode. So it pulls all the secrets it has access to into a, an encrypted read only file system. That file system is locked, until the gateway detects that it's in a disconnected state. And then when it's in a disconnected state, the user or application will continue to fetch a secret the way they normally do transparently. So they don't know that the gateway is disconnected. They are, able to fetch the secret from the gateway. The gateway will just pass that secret to that application. And, once service is restored, then, the gateway will continue its regular operation of syncing secrets back to the cloud. So with that said, I'll stop here, and I will go through a demo of the solution. So let's switch to our console here. So my console has access to the Akeyless gateway that I've deployed. This one's deployed in GCP. And you can see on the left hand side, I have a menu of items that I can pick from. I'm gonna start off with items, and I'll just show you one use case. I'll show you different versions of that use case. We're gonna start with dynamic secrets. So dynamic secrets are credentials that are generated just in time on demand. And you can see here we support a variety of different dynamic secrets, databases, cloud providers, Kubernetes, remote desktop, infrastructure tools, including our custom producer. So anything that we do not support out of the box today, you have a custom in house application that you're building. You can use the custom producer in order to to deliver just in time secrets. The credentials or I should say the permissions rather are baked into those dynamic secrets. So you can create different dynamic secret profiles. One can be a read only. One can be a read write. Another can have, you know, tailored permissions of what that secret can do. And so you create these profiles, and they're baked into the secret. Now, the users that need to get access to those secrets based on RBAC, you would provide them, access to one or more of those dynamic secret profiles. So you'll see an example here when I go to dynamic secrets. I'm gonna go to databases. We're gonna choose this Postgres database as our example. I'm going to click on get dynamic secret. And when I click on get dynamic secret, you can see a couple of things. One, my username is embedded, into the username itself. Actually, my name. So you can see my first name and a part of my last name, here. You'll see what the credentials are. You'll see that it expires in fourteen minutes. This is user configurable. The default is an hour. For the demo, I set it to just fifteen minutes. But after fifteen minutes, that credential expires. And if I lose it, no problem. I can request another dynamic secret. And each time I'm generating a just in time dynamic secret with the permissions baked into this profile. Right? This one has read write, but I can create one that is, restricted to only read activities and then assign it to individuals that, that only need to read data as opposed to write data. We talked about developer friction. One of the areas that we focus on is meeting people where they are, not necessarily forcing them to use our way of of, operating. Right? So we're now forcing everybody to go through the UI. If, someone's comfortable in CLI, there is a CLI that they can, install and perform the same activities. If they're comfortable with API, there's keyless APIs as well, as well as a browser for nontechnical users. Right? A browser plug in. So here you can see I'm going to select my browser plug in on, the top right hand corner. I'm going to I've already favorited to two types of secrets. One is a rotated secret, another is a dynamic secret. Same one that we looked at here. So I'm gonna click on this, Postgres DB. I'm gonna click on show value. This is the rotated secret, but let's choose the dynamic one. So when I click on short value, same same scenario, username, password, expiry in in fifteen minutes. The way this, works on the Akeyless side is that in the database, you need to create a root user. That root user needs to be provisioned in what we call a target. Think of a target as a placeholder for the, you know, master secret, your golden creds. Right? So that target has the, credential that is needed or that is called by this, dynamic secret producer. So Akeyless is using a root credential for the database in order to generate a dynamic secret with those permissions that are, set for what that profile needs to have. And then once those, once those dynamic secrets are are expired, then Akeyless goes and deletes that that credential. Now one question that comes up is, well, you have a target credential here that has the root password for this application, and that's a long lasting credential in itself. And so the way that Akeyless handles it is through another object, that we call, rotated secrets. And this is an automated process. There's no scripts to manage. There's no, additional, out of band, processes that you need to follow. So if I click on this GCP Postgres DB rotated secret, you'll see under the rotation configuration, I'm setting the rotator type as the target. So I'm basically telling it to rotate itself. Right? And the policy that I've said is that every thirty days. So every thirty days, that target gets, target cred gets rotated. And then you can see under versions all of the different versions, that I've created over time since since this secret was first, or this target credential was first created. And if I do show you the credential and you see what that password looks like, no problem. I can also rotate it on demand. Right? So I'm just gonna click on rotate secret again, and now that secret is rotated. And under versions, you can see that there is a new version created. We also talked about how to access secrets from other, components. Right? So we covered the browser extension. We covered the UI. There is the capability to also use the Akeyless CLI. So in CLI, you can see an example here where I just call get dynamic secret value, and there's the new dynamic secret with the username, the password, the TTL. I can do this through API as well. If you go to our docs dot Akeyless dot io, there's API builder you can sandbox with. But here, I just need to provide the authentication token. I've already set this ahead of time. And then when I click on try it, it will create another dynamic secret. So many ways to integrate with Akeyless, whether it's, UI, CLI, API, SDKs, all those also other integrations like Terraform and CICD tools. So lots of, lots of ways to interface with the with Akeyless. But the core value that we bring is, the ease of use, the, wide integrations that we have, the ability to do automated, rotated secrets, as well as dynamic secrets. But most people that we talk to already have a secrets platform in place. Right? So they're not starting from scratch. It's usually not greenfield. You have some other secrets tool that you're using, whether it's in GCP, Azure, or AWS, or you're using secrets, you know, in HashiCorp Vault, and and some other tools. And so we have the capability to also automatically migrate secrets. Alright. So we call that automatic migration. So you can see here, if I click on automatic migration, and I click on my gateway and go to new, I can migrate secrets from any of these platforms. You know, the three cloud platforms out there, other infrastructure tools, including HashiCorp Vault, Active Directory, and, any subsequent, migration that I do, let's say, configure HashiCorp Vault, and then I I initiate a migration the first time, it will download all of the secrets and store it in the folder path that I specified. But any subsequent, migration is going to be, just looking at the differences. Right? So any changes that have been made since my initial, migration are gonna be synced to to Akeyless. We also have use cases where you don't wanna migrate secrets. You just wanna keep working in the secrets area that, or the secret platform that you're already using. Right? And, in that scenario, we provide, a capability called universal secrets connector that will connect with AWS, Azure, GCP, Kubernetes, secrets, and HashiCorp Vault. And it's a two way sync. Right? So it's not just a one way sync from, you know, the third party platform to Akeyless, also from Akeyless to to the third party. And so, typically, this covers most of our customers' use cases, as it relates to secrets. But, Akeyless is a, unified secrets platform. Unified secrets and identity presentation, we're gonna cover, we're gonna look at an overall overview. Right? So, this is you know, think of it as a framework. So on the left hand side, you have the who and where, who's logging in, and where are they logging in from. We have your users, your cloud providers, your on premise, your, you know, micro microservices and applications. We provide a variety of different authentication methods tailored to those use cases. Users, typically, we wanna federate with, SAML, OIDC, etcetera. And cloud providers, we wanna use a federated cloud identity using, the cloud providers themselves. Right. So if you're in AWS, you're gonna use AWS IAM. And for on premise, where where a, cloud identity is not a viable option, we bootstrap an identity to those workloads with what we call universal identity. And so we provide identity in those scenarios where one isn't readily available. And then all of those are unified into a single authorization framework, that provides create, update, delete, list permissions that, you know, through RBAC, provides granular access to folders and secrets. And then our gateway is where, you know, that's deployed close to where those applications live. So close to where your targets and your automations live. And you can deploy as many gateways as you need. And through the gateway, you can do logging, collect metric information, automation, kickoff automations. And then at the very, very right, we have our targets and secrets. So we already covered, the Postgres target. That's just one example. But there are many types of targets you can create, including custom targets for any custom applications that you have. And then in terms of secrets, we covered the rotated secrets, dynamic secrets. I showed you a little bit about universal secrets connector. And, essentially, it's a unified platform for any type of secrets and identity type use cases. So think of things like mergers and acquisitions, for example. Your company merges with another company. They have their own secrets manager, that that they need to manage. How do you bring them under the fold, you know, while you figure out, you know, what the long term needs needs to look like? Right? So we can facilitate those those types of use cases, as well. So, essentially, making it simple for, users and applications and services to rapidly integrate, with minimal effort, minimal downtime. And, that is pretty much it for the demo. So I will stop here. And, Mariam, I'll hand it over to you, see if there's any questions, that you wanna ask. Yes. We actually have several questions that have come in, during the, during your presentation. So in some cases, you may have actually already addressed it, but I think I think, the first one, I'm not sure if you have enough information for this. It says, in order to use dynamic secrets, does the application need to be capable of managing such dynamic secrets? I'm not sure. No. So if it's a commercially off the shelf application, that's pretty easy. Right? So from our standpoint, you just click on the application that we have available, and you can set up dynamic secrets. The only thing it needs is that you need to create a root pass root credential, and import that into the target. Now if this is an application that is not commercial off the shelf and you are using a custom producer, the only thing the application needs is to provide webhooks, a crate webhook, revoke webhook, and a rotate webhook. Right? So as long as we have that, we can build in dynamic secrets. So for our internal use cases as an example, for things like Grafana and, and Splunk, we use dynamic secrets. Right? Even though, you know, the application itself doesn't have any dynamic secret capabilities built into it. Okay. Great. And I and I see a lot of questions coming in. If we don't get to your question, we will, we'll address you directly after the webinar. We didn't ask. So, another question. How easy is the Kubernetes integration, and how does it work? Pretty straightforward. So we support the standard, you know, Kubernetes secrets operators as an example, but we also have our Kubernetes secrets injection, which is a, which is a mutating web webhook. So you install the secrets injector in in in Kubernetes, and then from there, you can, configure it to fetch, you know, static secrets, dynamic secrets, rotate it. It's pretty straightforward and and seamless. Hey. Great. Here I have a a fairly polite questioner. Hi, Fabi Kaderi. Thanks for the information. Who would be able to create the target? My use case involves creating rotational secrets for Adder app registration. How can I achieve this? Yeah. So, essentially, in, Akeyless, you have admins. I didn't show you the RBAC component. I I skipped that for, you know, interest of time. But within RBAC, you can specify, what users can and cannot do. So as an example, let's say you're connecting through Azure AD. In Azure AD, we will read the SAML attributes that come back. So one of the SAML attributes may be group memberships. So you can have you can be a member of a group, that we can map to and say any member of this group has these admin admin privileges. Right? And so that way, as long as you're a member of that group, you have those those those admin privs, then those admin privs can give you the the capability to create targets. But other users that connect, if they're not part of that AD group, or or SAML group, then you can define different permissions for them. Right? Maybe they can just read and list, but not have the ability to create or not see anything at all that they may not need to see the targets. Hi. I apologize for the background noise here. So then we have someone who has a couple of questions. I'm going to ask you one by one. First is if I've got it right, the on prem variant is a gateway that is connected to Akeyless Cloud? Correct. Yeah. So so it is not a, air gap solution. Right? So we don't we don't, you know, I don't think there's any plans in in the in the near term or or long term to do anything outside of that, but, it's not an air gap solution. So you're always connected to the Akeyless SaaS platform. The gateway is connected to the Akeyless SaaS platform. But the gateway can be deployed anywhere, and it can buffer and and manage in scenarios where the SaaS is not available for any reason. Okay. Second, is there a way to migrate secrets from other platforms that are specified in automatic migration? And then examples are Oracle Cloud, KeePass, Bitwarden? Yeah. We we it's not, part of automatic migration today, but we do have the ability through our CLI and and and also through scripting to migrate, secrets from other tools. Recently, I did one, for LastPass. So as long as you can the easy way is to export those secrets into a CSV format. So once once it's exported into a CSV format, you can easily, import it through the CLI itself. So that capability is there. But if if, export is not easily, achievable, and it's not in CSV, then, you know, we can look at, writing a small Python script to automate that process. Okay. This is a big one. I'm not sure if we could just do this in the q and a. How does your solution compare with Happy Quartz? And follow-up, with HappyQuote now being part of IBM, do you see opportunities for replacing them, or is it more of expanding on use cases? Yeah. It really depends on the on what problems the customer is trying to solve. Right? So we compete pretty well, you know, respect to HashiCorp. They are the, you know, they founded the space. And, you know, as as great as they are, there are use cases and problems that HashiCorp cannot easily solve. We hear it from our customers all the time. And so, you know, for us, it's just the focus of what problems the customers are trying to solve. Typically, what we hear is cost. I've seen many cases where, you know, we we talked about developer friction. Right? So one of the scenarios I see come up repeatedly is the, customers trying to get around the cost of adding another client. And so rather than just using the platform and doing what they need to do, they're they're having to curb themselves, because they don't wanna overrun their their, you know, committed costs, that, you know, that they're paying for. So that's that that could be one use case. Another one could be, you know, you're deploying in multiple regions. If you've seen, HashiCorp deployment across multiple regions, cloud providers, on premise, you know you know, that hybrid use case, it can be challenging. It's multiple clusters, multiple deployments, you know, syncing secrets across them and making that available to to different teams. It's not an easy process at all. And and, also, we do have, I think, a wider rotation capability on an automated rotation capability, actually. Correct. Correct. Yeah. We can rotate, secrets out of the box. Okay. Another this is this is, this question just says, demo certificate oh, Dan, he wants you oh, this is someone who wants you to demo certificate rotation to a cert. Yeah. So, we do integrate with, a few cert authorities. Let me see. I don't think I can do the demo today, but, happy to discuss offline and show you what that looks like. But if I pull up our, let me just pull up the UI real quick. And under items, if I go to certificates no. It's not it's not here. Maybe it's under targets. Give me one second. Let me take a look here. Yeah. So we do integrate with, you know, GlobalSign, GoDaddy, Sactigo, Venify, zero zero SSL. So in a separate session yeah. Maryam, maybe that's a separate, demo that we need to Yeah. That would be A webinar. Follow-up. Yeah. Yeah. Okay. And let's see. We have oh, we have, two more questions. Is Aquila support oh, does Aquila support on prem Windows and Linux servers local account password manage? Yeah. That's a that's a great question. So, we do integrate with Active Directory. So we're able to, import, you know, through our automatic migration, import, things like service accounts and other other local accounts, and then you can specify what the rotation schedule will be in Akeyless. So, yes, we integrate that way. From a Linux standpoint, we do, actually, we have one customer that strictly just uses it for that p for that purpose. And it's our, you know, rather than managing SSH keys, we provide a certificate based management for, your Linux system. So they basically, either through our desktop application or our browser extension or even the CLI, they can run an Akeyless connect command. The only thing you need to do is deploy the certificate. So we'll create a, you know, for our cert issuer. You just need to deploy that to the machines. So you need to a deployment mechanism. But once that's deployed, then, you know, through our RBAC and and and our mechanisms, we're able to, facilitate, remote access, and not only through SSH, but also through the web UI. Right? So we have a secure remote access capability that allows us to, you know, just click on the target that we wanna connect to, and then, we'll be able to access it, through the web or through CLI. Okay. And the final question has come in. Can targets be created using the Akeyless CLI, or is this functionality restricted to admin users only? Yeah. As long as the user has permissions. Right? So you you can create targets any number of ways, API, CLI, UI, other CICD in integrations, through automation. So there's a lot of ways, but it falls back on that user or workload that is creating the target just has to be, has to be authorized. Okay. Great. So thank you, Sami, for a really, really interesting, presentation and demo, And thank you everyone for attending. Of course, you will have a link to the recording afterwards. And for those of you who ask for a follow-up, we'll be looking forward to following up. Thanks, everyone. That's great. Thanks, everyone. Take care.