All right, I think we're good to get started and welcome everybody. Welcome to this webinar on AQUILAs versus CyberArk. We're gonna see a live demo for modernizing secrets and identity security. We're gonna talk about unified secrets. We're going to talk about modern privilege access management and also certificate lifecycle management. So PAM and CLM. So speakers today, have Doctor. Connor Mancone, who's a principal solutions architect from Achilles and myself, San Gabriel, a platform engineer from Techneat Solutions. And, Conor, why don't you introduce yourself? And, I'll go next. Sure. I've been I've been doing engineering for a long while. I spent the first part of my career as a software engineer. So I built e commerce sites and business automation solutions for companies throughout the US. And I was always very interested in the security side of things, especially just because that never ending list of data breaches. So it was something I took very seriously in my own work, so not surprisingly, I transitioned into the security world. I spent five years as a security engineer and architect, which was a lot of different focuses, but one of them was definitely secrets management. So it's probably not a surprise that at this point in time, I'm with Achilles doing that a lot more directly. So that's great. Yeah, yeah, yeah, no, makes sense, makes sense. Yeah, so I started off actually my career as a network engineer, did that for about six or seven years working for an Internet service provider here in Canada. And that's really how I started and then decided, you know what? I wanna move up the stack a little bit and get to know the applications. And that's around where Docker got started. Right? And I was interested in DevOps, so moved into that space. Worked for Docker for a bit, worked for Sysdig, and worked for HashiCorp for a little bit. And then finally, in the last three years or so, I've been doing it alone. So building content in the space, doing training and tutorials, and I have an academy online if anybody's interested. But but basically, yeah, I'm doing a lot of teaching nowadays, which is a lot of fun. So let's go ahead and get started. And this is our agenda for for today. So we are going to cover quite a few things here. We're gonna understand the challenge of security stack sprawl. We're we're gonna look at two approaches, CyberArk and Akeyless. We're gonna look at the Akeyless platform itself with three main components, the unified secrets, modern PAM and CLM. Then we're gonna uncover some hidden costs of fragmentation when you have so many tools. And then a side by side comparison between CyberArk and Achilles and some key differentiators. And then we'll have a live demo. And that demo, we're we're gonna see how we can secure a Postgres database end to end. And finally, we're gonna have a q and a. But don't don't save your q and a's till the end. Go ahead and ask them along the way. We'll be looking through here in the questions panel, and we may answer questions as we go along. So let's go ahead and get started. So the problem, security stack sprawl, that's mainly what we're gonna be focusing on. So unplanned accumulation of security tools, secrets, privileged access, certificate management really leads to fragmented workflows, inconsistent policies, and significant operational friction. So the security stack in an organization can grow organically over time with teams adding new tools as they see the need, and each new tool brings its own workflow and policy model creating complexity, friction, and daily security operations. And really what I've I've spoken to a number of directors, v VPs at a number of of some of my customers, number of companies in general and, you know, consistently I keep hearing that they prefer to have a solution, a one solution that has, you know, everything they need and GitLab comes to mind and what GitLab has done actually even from from before what how GitHub has has actually caught up. But from the very beginning, GitLab had that mentality of trying to centralize a lot of their tools under or build their own tools. So things like the repository management that they started off with, pipelines were there from the very beginning, even building environments in there as well. So they did a great job, a lot of these VPs that I was talking wanted basically one vendor to choke to be able to get everything out of them and all at the same time, some seamless integration of, the offerings that they have. So two different approaches, CyberArk and Akeyless, and CyberArk spreads the solution across multiple products, each with its own admin layer and rollout path, and CyberArk really expanded their portfolio of products by acquiring these separate products rather than building a unified platform from scratch. And each tool kept its own technology base and remains bundled commercially but not necessarily merged technically. And this creates sometimes operational silos and slows deep integration for Teams. So when customers adopt one product, they still need to onboard Teams again for the next. Whereas Akeyless delivers one platform where everything kind of lives under a single control plane, everything lives under that. And when when you have that kind of framework, everything under one control plane, guess what? The security teams don't waste time stitching capabilities together. And the CyberArk stack is made up of really good products. So we're not we're not putting down any of their products. They're actually very good products. The question is, how do you integrate these products to work together well? And that's kind of what we're trying to talk about. So there's conjure for secrets management that they acquired CyberArk has their own or their claim to fame actually started in privileged access management and then also they acquired Venafi recently. And this next slide here kind of gives you an outline of when they acquired these different solutions. So like I said, their forte was PAM, and then in twenty seventeen, they acquired Conjur for secrets management. And then in twenty twenty, they acquired Adaptive, which really moved CyberArk from privileged access management to a broader identity security framework, adding workforce and customer I'm to the mix. And then recently in twenty twenty four, they extended their reach into machine identities and certificate lifecycle management and PKI management with the acquisition of Venafi. So quickly, the Akeyless platform here at a glance, and they have or Akeyless has secrets management, they've got dynamic and static secrets with automated rotation. I have a lot more to talk about dynamic secrets, are near and dear to my heart, so we'll chat about that in a bit. Modern PAM, so just in time privileged access without jump hosts and bastions and all that. Certificate life cycle with automated issuance, renewal, revocation, and even provisioning to target machines. And key management, so distributed fragment cryptography which is DFC for short, which is zero knowledge design, again one of my favorite things about Akeyless, we'll talk about that in the next slide. And then, multi vault governance. So giving you visibility into external secret stores in case your teams have to have, you know, access or have to use other, secrets managers like secret manager in AWS or maybe HashiCorp Vault. So Akeyless can bring all of that under one roof. So built on zero knowledge architecture and Akeyless employs this DFC technology or distributed fragments cryptography for a zero knowledge design. What does it mean really briefly? It means that your encryption keys and secrets are inaccessible even to the provider themselves which is Akeyless And that is very important to me. When I first heard about Achilles and that it is a SaaS offering, I was a little bit concerned because I don't wanna keep my secrets in, a SaaS managed by a vendor. So when I heard about this technology and they actually split the keys into fragments, one fragment sits in Azure, one in GCP, one in AWS, and there is a fragment that you as a customer will actually host in your own environment and that enables or prevents even Akeyless from viewing your secrets. And, Conor, I don't know. I I said this many times. I really love this technology. I know you have some thoughts about it even when it comes to internal admins, I think, within within Akeyless themselves. If you wanna comment on that at all. Yeah, no, think it's a good differentiator. Again, because you get the fun of a SaaS, which really solves like disaster recovery and a lot of other operational issues just disappear for you as a customer. But you don't have to give away all your secrets. You don't have to worry about what if X, Y, Z, because you can make sure that you are the only one who has access to your data. So you really kind of get the best of both worlds. And I think what you're alluding to, you get the ability to even bring that to your own company, right? Because a lot of the times with the secrets management solutions or PAM or whatever, the admins of that service themselves inherently get access to everything. It's just kind of like an unavoidable reality. But with DFC, you can actually, you can change that. It doesn't not have to be so, because you can be an Achilles admin and have full visibility over everything going on in Achilles, because it's a SaaS. And then individual teams can manage their own customer fragments to protect their own secrets using your tenant. And as a result, you can actually have a case where the keyless admins get full visibility without getting actual access to the secrets themselves. And so, for those really privacy conscious organizations, or maybe you have some teams that are really much more serious about the security, often there's different risk levels for different teams in your company, you have that option to bring in a higher level of security, even amongst your own organization. So I think it's a good, flexible option to have for your company. Right. It makes a lot of sense. Yeah. No. Thanks for that input. Cool. So the first when when we look at different security tools, I always like to speak in phases, right? Whenever I have a customer and we're talking about implementing secrets management, for example, I like to talk in phases. So we're not going to go ahead and implement everything at the same time. I like to talk crawl, walk, run kind of phases. And you really, you need to start somewhere. And secrets management sometimes is one of the good places to get started. And when you get started with secrets management, you'll notice the difference when onboarding applications between CyberArk's Conjur and Akeyless's own secrets manager. And that comes in specifically with Kubernetes applications. And I find that CyberArk's Conjur, you know, this step becomes a bit harder because Conjure Cloud doesn't really ship with a native Kubernetes secrets injector, whereas Akeyless does. So that's that's one differentiator that I really like about Akeyless. I mind I I promise we'll talk about dynamic versus static secrets. So once you've onboarded and typically with secrets management, are trying to, at the very beginning, move all your secrets that are sprawling in everywhere, you know, in Excel sheets, in your GitHub code, and maybe on a post it on your keyboard or something, but you want to centralize all of that, you know, in a in a central location. And static secrets kinda fit the bill in the very beginning, and you you do that with static secrets. But as you start to mature, you know, you want to move towards dynamic secrets. And static secrets are long lived credentials that require manual rotation and increase your risk exposure, whereas dynamic secrets, these are short lived, they're tied to a time to live, so they expire automatically and they don't exist until you actually request them, right? So that is that is really key. So the reason why I bring this up is that Conjur coverage for Dynamic Secrets is more limited than Akeyless across databases, cloud providers, which leads teams to have to go back to use static secrets, is really what we need to move away from. Whereas Akeyless supports a lot more dynamic secrets out there, database is have a lot more coverage. Cloud providers with automated rotation and so on. So that really helps to move away from long lived credentials to short lived credentials. So, again, if you haven't heard of Dynamic Secrets, they the way they work is that they're generated on demand. They do not exist until you you request them. They're short lived by design, automatic expiration after the time to live expires. No manual cleanup is necessary because once they expire, they're gone, and we'll see this in our first part of our demo. Security benefits, reduced blast radius, lower risk of compromise, and improved audit trail, and of course, less operational headaches and overhead. So continuing on with our adoption journey, now once secrets are secured and you've you've rotated them, you've used dynamic secrets, the next question becomes, well, who or what is allowed to use them? Most legacy approaches split identity into different paths, you know, one for systems, one for people, one for workloads, and often even the separate consideration for AI agents nowadays. Right? So this divide creates more policy surfaces to maintain. So Akila streets access management for humans, machines, and AI agents as part of the same platform, once again, that same platform, the same policy boundary that governs a secret, creation also governs who or what can use them, making once again, just in time or dynamic access a natural extension of secrets rather than a separate product, everything under the same umbrella. Okay, so moving on from secrets management to human remote access. Now you want people to be able to access your infrastructure and traditional PAM solutions really relied on shared admin accounts, long lived credentials, jump boxes or jump servers, bastion hosts. And as I mentioned in the beginning, I used to work as a network engineer in the beginning of my career and I had to manage firewalls, I managed VPN concentrators, and it was quite a pain when you're onboarding a new user in the organization. You have to have to create an account for them perhaps on one of those jump hosts in the VPN concentrator. You need to add them there. You need to deal with IDP, you need to see if the firewall needs to be opened as well. So onboarding is is is a hassle, and offboarding is even worse because then you have to reverse everything you've done, make sure you followed all the steps and didn't miss anything. Not only that, with jump hosts, you're actually getting access to the entire network. You're jumping with VPN into a a box in your network. So if you're not careful, you can have you can give more access than you want. Right? So that is that is something that we don't wanna do. Whereas with the new way of doing things with a modern PAM like a Keyless, Keyless removes this layer altogether. You can access your end machine and device directly, with short lived credentials. So we'll see in the demo how we're gonna access Postgres, and we're not gonna access, the network. We're gonna access the actual end target host directly. So we'll get a web UI with Postgres only on it. And you can also get a terminal or through a CLI, you can get straight onto the Postgres CLI prompt. So that is much more powerful. And you don't you don't have to worry about any kind of credentials that is handled again behind the scenes with dynamic credentials all in one product. And then recording. Right? We need session recording. Any PAM solution would would would need that. So we'll see session recording for RDP sessions, for SSH sessions, all available within Keyless. Alright, next in our journey is certificate lifecycle management, right? And in the CyberArk world certificates are handled by Venafi, which again remains a standalone product with its own admin workflow. And this means the lifecycle certificates is disconnected from the lifecycle of secrets and access. And then finally compliance made simple and once your secret rotation remote access and certificates share the same trust boundary, we now have compliance that improves as a natural outcome and instead of pulling logs and audit data from multiple systems, everything now lives in one place, we have access to it directly. So the hidden costs of fragmentation, when you have this coverage split across products, operational costs rise and that's why we call them hidden costs, you don't necessarily see them, but they're there. And each upgrade is separate. Each support path is separate. Each onboarding, requires its own process. So security teams now handle policy drift, platform teams handle integration drift, and the weight accumulates over time. And when these functions move under one control plane, on the other hand, there is only one life cycle to manage. So a quick side by side comparison here between Akeyless and the CyberArk stack. So one UI and API for Akeyless, it's a single platform for secrets, access, and certificates. I would, of course, add the audit logs as well. Whereas with CyberArk, we get separate consoles, Conjure and Venafi, for example. Kubernetes onboarding, much easier with Akeyless, with the Kubernetes secret injector. Dynamic database secrets, we have a lot more coverage with Akeyless. And from a certificates management perspective, it's built in with one policy model, whereas with CyberArk, like we saw, you need a separate product in Venafi. Anything you want to add at all, Conor, before we jump into our demo? You know, we had a question come in from Steven, which I think it's worth saying out loud, because it's a question we get a lot. It goes back to DFC, but still, so I'd like to cover that before we move on. And he was asking about that customer fragment and that DFC process and what it means for continuity in case of like a network outage, or what if you lose your customer fragment? And we get that question a lot, so I think it's a great question that I'd love to address because the answer is also very simple. So the DFC isn't inherently online process. So it's true because those key fragments are stored in multiple cloud providers. So it's true that if you lost network access, DFC would stop working, you wouldn't be able to decrypt secrets, it would be a problem. But that's where gateway comes in, which is something you deploy into your customer environments, you need it there so it can talk to those networks scope or resources. And it also has a lot of caching options. And so it can continue to serve secrets and even in the event of network outage. So very easy to solve. And that's one of the many reasons why we have that gateway there. On the customer fragment side, it is true that you do have to protect that very carefully because that's the one thing we don't protect, right? Because as a SaaS, the whole point is that we don't have that customer fragment, so we can't decrypt your data. So just by definition, keyless themselves can't help keep a copy of that customer fragment for you, the customer is responsible for it. And so you don't wanna lose it. But the nice part about it, which I really like to emphasize is that it's actually not like, it's not something you have to treat as a state secret or a really critical secret because it's only part of a key. So even if somebody were to steal it, it wouldn't give them access to any data, they wouldn't be able to go decrypt anything, they don't have access to the data directly anyway, right? Because that's stored in the AQUILA SaaS. And so you need to back it up, but you don't have to like chisel it on the metal and put it in the safe somewhere, you can maybe put it in like, I don't know, just an AWS multi region AWS secrets manager secret, or maybe on just a RAID drive somewhere on your premises, you have a lot of options for how to store it as just a simple ASCII string, you can really do whatever you want to back it up, and so it's, I don't think we've ever had an issue with a customer losing one because it's really very simple to store. So yeah, that's what I wanted to explain. And you don't need to use it if you don't want to. That is also true, yeah. Because I see Emon here in the questions asking, looks very risky, right? But you don't have to, like for the most part, in a lot of my demos, I I forego it because just from a an easier demo view perspective. But you you totally can if you you know, if if this is not an issue in your organization and you wanna run with with the SaaS as it is, completely fine. Right? No problem. Okay. It is a very similar problem for a lot of the other secrets managers as well. You know, I know from my time involved that you also have kind of like that root encryption key that you have to store and not lose or you lose access to all of your data. And so it is just the nature of the beast, so to speak with secrets managers a lot of the time that you want your data encrypted and you don't wanna lose the encryption keys. We can help manage that process for depending on Or we can manage it entirely for you, like you're saying, Sam, if you don't want to worry about it, you don't have to use it. Cool. All right, let's start our demo here and then we'll I'm glad there are some questions in here as well. We'll work through them as we go along. But really quickly, we have four mini demos for you today, and we're going to showcase the on demand dynamic secrets for our Postgres database. We're going to see certificate issuance and maybe this will help answer some of the questions. And then just in time access, we're going to do secure remote access to that particular Postgres database and see how we've generated a certificate and we've actually provisioned that certificate onto the the box where Postgres is running, and we'll get into the box and see it. And then finally, we'll we'll look at the audit trail right inside of of Achilles. So let's go ahead and do that. Let me get out of here and jump into Achilles, and of course, I have to sign in. I'm gonna sign in with SAML. And maybe this ties in to a question we had here while I sign in here. I think there was a question about where do we, like, what what happens with PA from where does the user get provisioned, where I should manage the user? It could be in my AD or Entry ID. Yeah. So there's SAML, there's OIDC, you can tie Akeyless into that and you manage your users there. I don't know if you have anything to comment on that, Connor. You can also connect LDAP AD with Keyless, so you can have users use active directory design into Keyless as well. We can more commonly see SAML or OIDC, but you have a lot of options for how users get into Keyless in the first place. Right. Which is great. Again, you have single sign on, so onboarding, offboarding becomes very simple. You in your IDP itself, you you you you add them, you remove them, and then that's it. They're off from all your systems within your organization, not just Akeyless. K. First demo, Postgres. We've got a dynamic secret secret here for Postgres, and the way this works is you define a target and that target is connected to connects Akeyless to that Postgres database. And from here, it's as simple as requesting a secret. And what this is, we've requested a username and password into your database, and this request is tied with a an hour TTL. So you can see here it's decrementing, and at some point, this secret will disappear. So what will happen is that Akeelos is going to go into the database and delete those credentials from the database when the TTL expires. So you typically use this with your applications. So if your back end API, for example, needs to connect to the database, it will make a call into Akeyless, and it will retrieve those secrets on demand. And then when it needs the secrets again, it will make another call, and we get a new set of credentials, fresh credentials, again, with one hour TTL. You can view all the generated temporary credentials here. These are the two that we just created, and we can go ahead and revoke if need be. And that's gonna revoke one of our credentials into the database, and and that's it. We have another one. In in about fifty eight minutes, this is going to expire, and that's it. The application will need another one to to be able to log into the database. And one thing to note though, applications are horrible at keeping secrets. So if I'm a developer and I create a an application by mistake, I might log out credentials as I'm testing in dev and forget to comment that log or remove that log, and all of a sudden, that gets pushed into prod, and now you have secrets showing up in the logs that get pushed into your SIEM onto your or or log manager, or a monitoring tool, and now you have a secret showing up there. So if that's a long lived secret, that's a problem. If it's a short lived secret, then less of a problem. Obviously, that will expire after a while. Of course, you don't wanna do that to begin with, but you're you're you're reducing that blast radius we're talking about. Okay, so that's the first mini demo. The second one we said we're going to talk about certificates. So when you're creating certificates you need to build a chain of trust. So you typically have a root CA, that root CA signs a certificate that becomes part of an intermediate CA issuer that then you can use to sign leaf certificates and these leaf certificates are going to be the certificates you give to your applications for TLS or mutual TLS or what have you. So this whole setup you can have in Akeyless. Some organizations will have their own root CA so they can use that to sign an intermediate CA and then you can put this into Achilles, that's completely fine, or you can have the whole setup if you wish. There's a very neat command here that sets everything up for us right away with one command, AQUILA's generate CA, and that's what we use here for our demo. And what that does is it basically creates this folder and in this folder we have this PKI folder and we have three folders inside of it. We got a certs folder where we have our intermediate CA certificate. You can see the cert, the private key associated with that and then if we go back you can see the root certificate as well And if you go back, you can see the issuers. So I said there are two issuers, the root issuer right here, and we also have our intermediate issuer, and this is where you would generate your certificates from this issuer. This issuer would generate all your leaf certificates. Allow domain here is anything under example dot com, and that's basically what we're going to do in just a bit. And here are all the keys. So the keys stored, these are DFC keys for the root, as you can see, and also for the intermediate CA, it's also a DFC key. And then finally, I created a leaf key, it's a classic key here, and it's very easy to create a key, go into encryption, classic, and then you create your key. This is an RSA two thousand forty eight key. And now, what we're going to do is we're going to create a certificate, a leaf certificate based on this whole PKI setup that we have. So, we got let me pull up my let's see here. Where is my IDE? And by the way, I just downloaded the new ID called anti gravity by Google, which is you'd expect the same thing. It looks like Versus code, but there's a few things I like about it. Maybe we can talk about it later. But, basically, we have a few steps here where you authenticate, of course, to Akeyless with SAML as we saw before, we can do the same from the CLI, and then you generate your CA chain, we saw that command in the documentation I just showed you, And now we want to generate a certificate signing request, so a CSR. Let's go ahead and do that. And it looks like I gotta once again sign in. There we go. We're authenticated. Let's go back in here. And here is our CSR, you can see it has a certificate request and it also has a private key. Excellent. And then we want to extract that private key, so run this simple set command. And that will generate or take out my private key because we're gonna need that in the next command. And this next command is to issue that leaf certificate. So you can go ahead and run this command. And there we go. We've issued a leaf certificate with the entire chain. So the top is the root certificate, here is the intermediate certificate, and here's our leaf certificate. Right? So all that has been created for us. And then we can go back into the UI just to show you what has happened. So if I refresh here, we now have a certificates folder with our test. Example dot com certificate we just created, and here it is. The entire chain is here if you notice, if I keep scrolling, that was the root certificate, this is the intermediate, and at the bottom is the leaf. The private key is also stored here as well, and we can take this a step further, as I promised, we can provision this directly onto the Postgres database, So I can just specify a few things here, including the certificate remote path, where I wanna send the certificate to on the Postgres machine, where I wanna send the key to, and where I wanna send the entire chain as well. And then a a command that you want post provisioning, which in this case, I'm just putting anything, but you would run something like a system system control restart Postgres or something based on how you've actually set up Postgres, and then you can go ahead and attach that. Let's see here. I think that post provisioning command was not quite syntactically correct, that's all. Maybe, maybe. Let's do let's go with the echo command that I know works. There we go. Yeah. So there we go. So this has been provisioned, and that takes us to the next part where we wanna now go onto the database itself and see what's going on. Yeah. So thanks for that, Connor. And here is a portal. This is the secure remote access portal where we have or you would expose all the different infrastructure to your team so that they can go in and access these these boxes, basically. Here's a Postgres. Let's see here. Let me refresh. Let's go back one second here. Maybe I need to authenticate again. Let's try that again. Alright. Not sure why this is giving me a little bit of trouble. It wouldn't be a live demo without one one. Of course. Exactly. I'm waiting waiting for Probably another probably another AWS outage. Yeah. Could be. It could be. Well, what I wanted to show you is basically what we just provisioned, and we have actually a this is all recorded in in coming out in a blog post next week. And oh, here we go. So I can jump into the actual Postgres database directly here with a web portal, and there we go. I'm on the Postgres database itself, and you can see here there's nothing really here. You can create a table and all that good stuff, but I'm inside the database directly with no credentials, you noticed. I didn't have to put in any kind of credentials to the database. This was all taken care of behind the scenes with Dynamic Secrets from the same, again, platform, the Akeyless platform. Let's go ahead. While you're doing that, there was a question about for the provisioning question, he was wondering about how, in terms of provisioning, how do you connect to that target? So as you're going off and connecting to this Linux box using SSH, can you talk a little bit about how that connection is actually the credentials for that connection are managed? Yeah. So, yeah, so let's do it. We're we're jumping into the Postgres. I have a Linux box here and Postgres box. So let's go ahead and connect to this Postgres machine. And again, look at that. We were in without having to show any kind of credentials. I didn't have to, you know, there's no certificate. I logged in, but there is and maybe you can talk to this, Conor. There is a target that was that you've you've set up beforehand and that gives us access. I gotta talk to that towards Sorry. And for the SSH piece, there's there's really three options, which is that you can have, Achilles can be managing an SSH username and password, and it can be rotating that password after each session. And so when you connect, it can connect as that user. You can also set up a private key in Achilles, which it uses to broker that connection. And finally, what's going on here is you're using a temporary SSH certificates. So the machine has been set up to trust, again, another PKI authority that exists in Achilles. And so when a user wants to connect to Achilles, a keyless wants to connect to this machine, a keyless generates a temporary SSH certificate, which is what's actually used to connect to the machine. And so there's no, it's dynamic credentials even for So in this case, it's connecting as a specific user. Keyless isn't going and creating a new user account on the Linux box. We do have that kind of user provisioning where Keyless is gonna go and create a new user that exists for Windows and databases and stuff like that. Excellent. All right, so like I promised, we're in the path and we've got server. Ca, server. Cert and server. Key. If we quickly look at those, these are what we provisioned. So here's the cert, Here is the the entire chain. Right? It made its way to the box. And finally, the key is right here. So if you if you also wanna just, you know, just for kicks, the Postgres the Postgres configuration itself. Right? So if we go down here, so somewhere there we go. Here's our SSL. So you basically would just uncomment this SSL section for the CA, the cert, and the key, and then we would bounce that service. And that that service would be basically bounced by the command, the post provision command here, right, and and then you can go ahead and provision again, right, so we can we can automate the renewal of these certificates and automate the process all the way to the end to to send the new certificates to the to that machine. Right? Excellent. And one last thing here is the audits. So audit logs are also, again, part of the platform, and we can go ahead Okay. Look at dynamic secrets, for example. Here's the access to the dynamic secrets that we created. Excuse me. The certs that we we looked into, certificate provisioning as well. Apologies about that. I've been fighting a cold recently and I'm getting this hacking cough. But basically, everything here, as you can see, is in the platform from an auditing perspective, but we can send these also to Splunk or a separate SIM. And Connor, if you wanna talk to session recording, maybe RDP and terminal based sessions while I cough a bit. Yeah, no problem. Although I'm gonna go back just one topic because Charles had a great question about whether or not temporary credentials pose a problem for audit trails. You were just looking at the audit trails, so I figured I'd jump in there. And it's actually, it's the opposite, temporary credentials, rotated credentials, shared credentials cause a problem for audit trails, right? Because a lot of PAM solutions rely on rotated credentials and so every user who connects to a service is using the same username for that service, and that creates a problem for auditing because everybody shows up in the audit trails as the same person, and so connecting, if you're looking in like your database audit trails and you see a username doing some activity, it doesn't help you if every single connection has same username. So when you're using just in time credentials, every session, every human user gets their own independent credentials into your database or your Windows machine or whatever. And so now they're actually separated inside of your service. And then the audit logs, which Sam was just looking at will actually tell you which human user was using which temporary credentials in that destination system. So you can actually use the audit trails to connect them back all the way. If you find like in your database logs, if you find some username that's obviously a temporary user, you can come to Achilles and you can search for that right here, and then they'll tell you which human user had that session. So you actually get better audit log capabilities when you're using dynamic credentials. So I hope that makes sense. And then Sam, oh yes, the recording. So yeah, we absolutely have recording setup. So there's two different types of recording setup. One is for all of the CLI based access. We just have recording of the text, what the user types into the service and what the service responds back, whether that's a database or an SSH session or whatever. And so you can forward those along to your SIEM just like you would then audit logs in Achilles. And finally we have RDP session recording where for any RDP session to a Windows machine, the gateway is going to keep a video log as everything happens and you can have those videos uploaded to AWS or Azure or leave them on the gateway to do whatever you want with them. So full session recording, you know, as you would expect. Excellent. Let's take a look at some of the questions here. I think there's another one by Moshe. Regarding certificates. Can I integrate my CA as well? So the answer is yes. Correct me if I'm wrong here, Connor. But, actually, that's a use case where, let's say, your roots like like, let's say you have the you have a root CA and you wanna be able to sign SCA inside of Achilles and then get the Achilles intermediate to go out and create the leaf certificates. I'm I'm assuming that's the use case here. Yeah. And actually, so if you real quick, if you don't mind, Sam, over to the console and going to the target section, we can just show that takes all of two seconds. Let's do it. Targets and hit new. And if you scroll down a little bit, we'll see all of the certificate automation right there. So those are the public CAs we currently support. And so yeah, Keyless can even automatically provision certificates from those public CAs. So they're the ones issuing the certificate, but Achilles will request it, get the certificate copied into Achilles provision into a service for you. So there's support for public CAs and those are specifically the ones that we support out of the box right now. Excellent. How are we doing on time? No, it looks like we're about at the end. Yeah. Did we cover most of the questions here? The questions regarding the PAM I want to access remotely to something. Okay. I think that was done. One just came in. How will it make a difference if there is no gateway? For PAMs, the gateway is required because you it's providing network connectivity to the users and it's also the one managing those temporary credentials. So if you're using SRA specifically, you definitely do have to deploy Kiwi. I think we had a whole session about gateways at some point and how powerful they are and their stateless. One of the reasons I really like it, I also came from HashiCorp. Right? So big on Vault. And with Vault, you have to you have to build clusters everywhere. With gateways, they're very lightweight and very powerful. So cool. Alright. I think we're at time. Just to be respectful of everybody's time here, we are very thankful that you're able to join us today. And, hopefully, this kind of shed some light on what we mean by one product that has deep integrations because it was all built from the ground up with all those security tools in mind. So once again, thank you for tuning in, and we'll see you on another webinar.