Well, welcome, everybody. And, today, we're gonna talk about Akeyless as a modern PAM versus Hashicorp Boundary, and we have an exciting demo for you as well. And, I'm joined with my friend here, Netser, from Akeyless. I'll let Netzer introduce himself, and then I will go next. Thanks, Sam. I'm Netser. I'm the director of solutions architecture here at Akeyless. Been with the company for three and a half years now, and very much looking forward to this exciting webinar. Nice. And, myself, I'm Sam Gabriel. I am a content creator now. I guess that's what I call myself. Build content in the platform engineering space. I do training, tutorials, and so on. Been working I've been doing this for about three and a half years now. Prior to that, I worked at HashiCorp for two and a half years. And prior to that, worked for other, companies like Sysdig, Docker, and so on. So I've been in the DevOps slash platform engineering space for some time now. Alright. Let's go ahead and get started. So our agenda for our webinar today, we're going to talk about the challenge of moving from VPNs to identity based access, what this all means, and I'll give you a little bit of a story of my history there. And then we're gonna talk about two approaches, the HashCore boundary approach and Akeyless. Then we're gonna talk about some of the features and limitations of boundary and then dig into the unified approach that Akeyless presents and then a side by side comparison of the two products. Then we're gonna have a demo. Netser is gonna lead us in that demo, at the end, we're gonna have a q and a. So as we're going along, please feel free to put any questions you might have in the q and a. We'll see if we can answer them on the fly. If not, we'll we'll answer them in the q and a session at the end. Okay. So, the traditional privileged access problem. So a little bit of my history. I actually started I don't know if you know this about me, but I started my career as a network engineer, and I worked for a big telecom slash Internet service provider here in Canada and manage routers, switches, firewalls, VPNs, you name it, right, MPLS. And, one of the things that we have to do as part of that role is onboarding, contractors, onboarding vendors, onboarding even even internal employees to get access to our systems. Right? So they may need access to certain data centers or even, segments in the data center and access to certain machines. So the way we would do it is that we would open firewalls, put firewall rules in there, update the VPN concentrator, and, update the bastion hosts or jump boxes and all that kind of stuff, and it was painful. And it could take up to a week for a request to come in until they actually get the person gets access. And then they use that. Maybe a contractor's on there in there for maybe six months, and then you have to off board them, and you gotta remember what you did, and you gotta go backwards from there and and off board. And it was painful, but at the same time, we didn't have cloud. We didn't have dynamic infrastructure. It was all our data centers and our corporate offices, and we had access we had firewalls. We own the perimeter and we secure the perimeter because we own the network. Nowadays with dynamic infrastructure, you don't own AWS. You don't own, Azure. This is dynamic infrastructure that you need to figure out how to provide secure access to to users. Right? So this is what we're talking about, and something has to change from the old way of doing things. So the new approach, which, by the way, both Boundary and Akeyless take this approach, and this is where users need to come in and authenticate against an identity provider. So think Okta, think, Entra ID. And from there, there is an authorization mechanism to see what they're allowed to access, what target hosts. So this is auth n and auth z or auth zed. And then from here, they need to get access to the target hosts whether through SSH, RDP, even a cloud console. So they need to get these credentials injected dynamically so my users should not have to remember how to access these these end hosts. They should get the access directly, and that's what this is the flow basically of how this should all happen. And we are not supposed to give full network access. When you give the old approach where you what I used to do, when you give Bastion access, a lot of times, you're actually giving network access to people, not just by protocol, not just by session. This approach, you are very strategic and surgical in what you're giving access to. Right? So you're giving access to specific target hosts. And if I may add, definitely, the application level sort of VPN equivalent is definitely where we wanna go, but, also, the fact that, you know, Boundary and our secure remote access solution both rely on dynamic secrets. That in and of itself is groundbreaking because if you look at let's call it some of our more legacy type of comp competitors, right, in the Palm realm, their main value proposition was talking zero trust, making sure the users, like you said, don't have to know their password, but it wasn't necessarily assuming that that password were to auto rotate or dynamically get provisioned. We're already in a good starting point where these are the comparisons. Right. Right. Good point. Yeah. Absolutely. So let's talk a little bit about Boundary, and, Boundary is an identity aware proxy. It's designed to broker connections between users and the infrastructure targets. It's part, of course, of HashiCorp's broader ecosystem of infrastructure tools that they have. And they've got three flavors. They've got community edition, which is free but really limited in its capabilities. If you're really serious about PAM, probably you would look at either HTTP Boundary, Boundary Enterprise, or, of course, Akeyless. The HTTP Boundary, HTTP stands for HashiCorp cloud platform, so it's their SaaS offering, and Boundary Enterprise is a self managed offering that you can, self host yourself. So some of the limitations of communication, we'll see this later, but, basically, it doesn't give you, credential injection or passwordless access, and it doesn't give you session recording. These two things alone, you know, is is a hindrance. So that's the flavors of boundary. Boundaries domain model, it works with something called hosts, versus targets. So really briefly, host is a computing element, so it can be a a server, a VM, a container that boundary needs to reach. A host set is a collection of these hosts, and then a host catalog is a container or, basically, a container of hosts that, host and host sets which can be static or discovered dynamically. And then finally, the target is the access point users can connect to whether, with a protocol TCP, SSH, RDP, the port, and permissions. Now one more thing that actually tripped me a little bit with Boundary and the wording is, a misconception that Boundary gives you access to the AWS, Azure GCP consoles themselves. That's not true. It actually gives you access to the VMs and EC two instances inside of those clouds. What it does, it gives you automatic discovery if you put some tags around these EC two instances, for example. It gives you automatic discovery so you can have those in the host catalog so you can actually SSH or RDP into those machines inside of the console rather than access to the actual console itself. So I think this is something that is is worth talking about because, like, Akeyless gives you both. Right? It gives you access into the actual machines and also to the console itself, which I find interesting and, very valuable. Excellent. Now this is the key thing that if you forget everything we say today, I think this is worth remembering is that Boundary really needs Vault for anything to be valuable from a PAM perspective. So for functionality like credential injection, you need HashiCorp Vault to help you with with that. For just in time credentials or dynamic secrets, you need Vault for that. For auto credential, rotation, you need FootVault for that as well. And always when you're adding another tool, you're adding complexity, and, Boundary actually came as a product, historically came after Vault. Right? So they came with their own team, and, so so you're gonna have to deal with two different teams in the organization, and that comes with two different support tickets. And as a VP of an organization, usually, you know, we try to consolidate tools, not not expand. So that's that's one of the drawbacks of Boundary. So keep that in mind when we're when we're looking at, Akeyless. And not only that, Vault is a complex tool. Like, I I spend time teaching Vault as part of my training. Right? I when I do trainings. Vault is not simple. So you need a team that understands Vault pretty well, and, of course, top on top of that understands boundary as well so they can make use of both products. And I think one of the things that we talk about I talked I talked in multiple webinars here with Akeyless, and the thing I like about Akeyless is this unified approach that, we've been talking about. So we had a a webinar with about CyberArk as well and how that that's a separate, product with, Venafi. They acquired Venafi recently and how these, you know, the surf certificate management is now part of that platform, but they're actually coming from a separate vendor versus Akeyless having everything in one place, and we'll see that in the next slide. But here's a a screenshot for you of what we'll see in the demo. This is the secure mode access portal. You can get access to databases, AWS console or Azure console, Google, Kubernetes, SSH, and so on. I'll leave that part for for Netser. Won't steal his thunder on that. But back to my point where unified identity security platform, this makes a lot of sense because, Akeyless built something very unique and very special in bringing secrets management, privilege access, certificate life cycle management, encryption all under one cloud native solution, with zero infrastructure, meaning it is a SaaS. You don't have to deploy anything. With zero knowledge architecture, their distributed fragments cryptography, DFC, I almost mentioned in every YouTube video I make or any webinar I make because this is very important. Just in time, everything, their dynamic credentials created on demand. If you're using dynamic credentials with their PAM side of things or if you're using rotated secrets, you can you can automatically rotate, those secrets post session. Complete feature set, credential injection, session recording, enterprise capabilities, they're all included. And abroad the broadest protocol support natively. So there's SSH, RDP, databases, Kubernetes, web apps, cloud consoles, and so on. Yeah. The protocol support is a is an interesting strategic decision we made earlier on that we realized the pains of having to either go with our own new you know, inventing the wheel, having agents deployed. We don't do any of that. We see how the existing targets with the modern technologies out there, definitely cloud stack as well as Kubernetes services. The more you go to, like, the more modern type of solutions, you see that they offer great native options on top of native protocols, the ones you're mentioning here, and we try to see how we can make the best out of each of them rather than have to, again, reinvent the wheel. We this was also, you know, a quick way for us to to start. Right? I I believe this the competition that had to come up with their own unique ways took a lot longer and had to run into way more blockers along the way. Right? It's, it's something that was we've seen as a strategic decision that that paid off so far. Right. Yeah. That makes a lot of sense. So real brief briefly because I wanna get into our demo. Akeyless, secure remote access, how it works. The user access targets via three methods, either through a web portal, through native CLI access, or a desktop app. So think of a thick client. The zero trust connectivity workflow or connection workflow, you authenticate via SSO. Like I said, you can go through LDAP. You can go through Okta and so on. Akeyless validates your identity and permissions. Credential injection happens. Session recording starts. And then at the end of the session, again, whether you're using auto rotation or dynamic secret revocation, you can have that automatically rotated, on disconnect. If we're talking about dynamic secrets that already, you know, expires, like, it didn't exist to begin with. I'll talk about this in a second. But the key architectural advantages, SQList user access. So, again, user authenticates, and then Akeyless retrieves and injects credentials transparently to the user. They don't need to know the end target's credentials. Just in time credentials with dynamic secrets. Let's think of a database. A database will not have credentials yet for Sam to access it until we request it, and then it gets created on the database, and then it gets injected into our session, and then we have access to that database. And then once those credentials, the TTL for the credential expire, the session expires, they are removed. Again, we can do dynamic secrets. We can do rotation, rotated secrets. Unified secrets and access because SRA is built into that same platform as a secrets management platform again. There's no integration complexity. It's all one seamless, platform. And then flexible deployment, this is key because you can deploy these gateways which are stateless, very lightweight everywhere. You can have them on prem. You can have them in your different cloud VPCs in different clouds, which will give you this zero knowledge security model. I can I can add to that? That's the gateway the gateway key, this component, is it plays so many different roles here. It enables, like you just mentioned, the holding on to that customer fragment so that from a security and data sovereignty point of view, Akeyless as a vendor never has access to our customers' secrets, but it also leverages this same gateway to talk to the targets, the ones that actually hold or or or the are the targets for the secrets. Right? They these are the targets that the secrets open the door to. It's able to talk to those targets natively to both rotate a credential or create them just in time and revoke them, but it's also the same component that facilitates the connection, brokers the connection for the end user in our secure mode access solution. So it's somewhat of an all in one, not just in the platform aspect that that you rightfully keep mentioning that it's a unified platform, not a modular one that you have different moving pieces to. It's also the same potential deployment that would help you with secrets management and secure mode access, but in a way that is not you don't have to have both. Right? Can have either or or you could have both, all based on the same setup. And this is something we've been able to see from customers that either started with secrets management and we're able to easily expand into secure mode access or vice versa because it's again, same platform, same deployment with this gateway component all in one. It's really I don't believe I've seen yet, not with Boundary, but not with other competitors, either any solution that is able to truly leverage the same capabilities and the same components in that way, maybe with the only fine print is being that the RBAC would have a subset just for secure mode access because these have far more advanced use cases. It's not just about reading a secret or listing a secret. It's also about being able to request access and have someone else approve it. Like, all the approval authority aspect of secure remote access is managed in a unique way by our RBAC model. But other than that, truly the same. Yeah. That's a great point that you brought up. You don't need both. Right? You can you can and that's that's typically how how customers start. They can start with secret management, and then they they move to PAM or the other way around. So that's a really good point. I'm glad you brought that up. Yep. Cool. Alright. Next up is this feature comparison. I have a love hate relationship with with with things like this because things move quickly. Right? Right now, session recording is only SSH and Boundary. They don't have RDP. You know? In a in a month, they might have it. But the key thing I think is more important to me is the architecture itself. And you you nailed nailed it right there, Netser. The architecture is boundary has to have vault. Right? And you have to get these two to work together, and that is not seamless. It it is complex. Right? So that's a big deal. You have two two different thing two different products, two different, of course, licenses and all that kind of stuff and multiple teams that have to manage these. Right? Not just teams at the vendor side, but also teams on your side as well that you probably might have a different team managing Vault, different team managing boundary, and so on. Right? So, this is what we've got. I mean, one thing to note, though, boundary community boundary, I put it up here just so you can see it. But, really, again, there's no credential injection, no session recording, very, very basic in in its PAM coverage. So I would if you're seriously evaluating, you'd evaluate Akeyless versus Boundary SAP enterprise. Right? And that takes us to our demo, and you can see there's a bunch of things we'd like you to see. You know, anywhere from the platform as a whole and also how do we connect through SSH, how do we do RDP, recording, session recording? How do we do Kubernetes access, AWS access, and so on? So with that, let me stop sharing here. And just before I dive into the into what it looks like, I wanna clarify or maybe even, you know, hand it out to Hashi and the boundary idea of taking just in time as a core principle. I will say that I believe Akeyless and Hashi are truly the two vendors that realize this is no it's not a a nice to have. It's, in a way, another secrets management use case hidden inside the PAM world. Right? PAMs always it goes to the I'm team, it goes to the human to machine type of use cases, and often just in time is somewhat ignored in those use cases when you think about just vaulting secrets management, which is all about machine to machine. Because if I were to try to summarize it, PAM, traditional PAM is all about zero trust, end users not knowing their passwords so that they couldn't use it in harm's way And about session recording, right, which is obviously an enterprise feature that is a is a must to both alert or or scare the bad guys from doing anything funky while they're connected, but also to allow some sort of, like, a forensics view retroactively to see what really happened. Dynamic secret is where we are truly a modern solution. And the fact that what Hashi sort of missed in my perspective is that they've taken it as a separate product, that they have to interact with Vault separately. And with Akeyless in secure remote access, it's just built in. It's just part of how it works. That's the default way that we would set up a secure remote access connection is based on a dynamic secret. You do have the ability to switch to others, but that would be a de facto standard or or default for you. With that, we can get started. Yeah. Great points. Alright. So this is the secure remote access portal that we have here. I've logged in based on my own identity provider based on Okta in my case, and now I have this is a dynamic view that is built for me according to my permissions. So when Sam logs in, he will see potentially different number of tiles or within each of them a different number of servers or targets that he can access according to your each and every user's own permissions. So I believe we can sort of categorize some of these into what, to me, are are more classic use cases for PAM, which is primarily servers, where you're thinking Windows, highly active directory heavy, Linux with SSH, some database access, but then we get to the more modern technologies that require modern privileged access, which would be typically Kubernetes environments as well as the cloud consoles. We give you coverage to all of them in different approaches, and the Zero Trust portal is our web landing page, but we could, as you've seen on the slide, also leverage a client like a CLI running on your terminal if it's for SSH access, for example, or a thick client based on our desktop application. Now if we start with the I guess when you say PAM, typically, the first thing that comes to mind is Windows, right, going into different servers. And in this case, I have my own active directory. I'm able to either take advantage of rotated secrets, domain users that autorotate after each session I run, or dynamic secrets that can literally provision a dynamic domain user to my active directory with specified permissions. These two different approaches would typically be relevant to whether you care deeply about the session continuity of your internal end users, or is it some maybe an external vendor that just needs access every once in a while and there's no day to day work? Because if these are in your internal users, I'll I'll be very blunt, they would hate the admin that makes them use a temporary desktop in Windows every single day and start fresh. What they want is the ability to continue using the same session and save something on the desktop and reuse it and go back to it. So either leveraging rotated secrets where they don't like, would typically be their admin user, and you can see now it was it it took a minute and even way less to now RDP. The session is being recorded. I can jump around here. I can download files from here to my native client, or I could upload files onto here. You have all these different capabilities that let you very quickly start leveraging RDP, but the fact that this is a preexisting user or a fixed user is something that is is not a compromise. It's by design. You have to understand that end users will not tolerate the ability to having a temporary credential, which is the standard for dynamic. Right? Having a temporary user every time. That would work very well for external vendors typically, but internally, you have the choice between rotated secrets, right, for the for your admin users, or an even more advanced in a way type of option is just in time permissions. You may know the concept of elevating permissions. We could find a fixed user and temporarily add them to an administrator's group through the domain group, through a local group. We support all the different modes. For the duration of the session, they will be able to access it only through SRA. They will be recorded. And when the session is done, they get the essentially brought back down, right, or downgraded to just their normal day to day access. So it's still very much a privileged access type of thinking. Now while I did all of this, the session is recorded. Now you have you have the ability to for for example, the way I configured my session recordings was that it would get automatically uploaded as files onto an AWS s three bucket. It's being encrypted and and compressed first, but now let's say I want to access my AWS account, and I want to do it with a dynamic secret. I want not to take use of some, my own user password to AWS. Ideally, end users shouldn't have such permissive, capabilities. Instead, I have this AWS temporary s three read only credential or connection, which does something quite interesting in the background. It provisions an I'm user for me in the back, and notice that we've actually introduced a custom delay for how long it should wait before truly injecting the password. Even though we have it immediately, we know AWS takes a few seconds to synchronize a new I'm user with the policies that it has, so we have to introduce some delay before injecting it. Similarly, it would be the same with active directory. If you create a new domain user, you may wanna wait a few seconds for all the group policies to sync in. It's an interesting requirement across multiple yeah. That's pretty cool. So now here we can go into s three. This IAM user I just created is only limited to read only from s three buckets. And in here, we should see a brand new file that was just created with a with the three mega megabyte. You see an encrypted file, and it's all here. So we are able to easily go back to this, download it, open it, or you can choose a different type of output. But this way It's a it's a video. You can see it's m four v right there. Yeah. Yeah. Yeah. It's a video file. You can watch it later. Yeah. And now what's nice is that this was, again, a temporary credential. So I didn't actually know. If you noticed, I had something injected for me, and now if I try to do it again, it would be a new temporary user every single time. And every time you disconnect, behind the scenes, Akeyless revokes that temporary credential. So if even in any malicious way, it was somehow hijacked along the way, once the session is over, the credential is over. Next up, we can take an example of potentially a DBA that needs to make or connect to a production database. Obviously, that would be permissive by definition, and they want to leverage a connection to a MySQL database. So they could choose between a web interface, a generic one that we provide to all databases, a CLI connection that would be like a shell running within your browser or leveraging later the Akeyless Connect from the CLI or even a native thick client running on your desktop like DBeaver or etcetera. There are too many for me to name them all, but let's start with a generic view that would work for any database, Postgres, MySQL, MS SQL, Oracle, all of them, that allows you now to view all your tables and change the different databases or simply run SQL commands. The basic functionality and even more than that is all supported here, and you can see this is me right now. This is a TMP user. Our dynamic secrets always work this way. They always create a TMP dot something as a prefix even though recently we've allowed customers and users to actually change whatever the prefix ought to be. They can now make it an Akeyless prefix so that they can easily recognize those end users, and also we always maintain the link between the temporary user credential that you would see on the end target and the user requesting it on Akeyless on our audit log. So you can easily do that for audit reasons or compliance, you can easily do the link. Now this is the dynamic secret issuer that I just viewed. I'm taking I'm taking you to see the admin side of things from Akeyless. As an admin, I would also be able to see all the standing privileges, all the active temporary credentials that are now taking advantage of this or using this secret, and I can actually remotely revoke their access. I can kick them out. If I have reason to believe that this is a malicious user, I could just decide I want to revoke this temporary credential. And once this is done, it takes a few seconds, then the next time I will run something here, I actually get kicked out. Four zero three. I'm no longer allowed. I'm forbidden. Right? Just like that. That's ease right away. It doesn't wait for a time period or a time out or something. Yeah. Yeah. Exactly. It gives the admin of this platform a true ability to control. Right? Typically, I think some of the palm mindset, to some extent, is recording and then reacting if something were to happen. And here, potentially, you have the ability, thanks to dynamic secrets concept, to act, not react, right Yeah. When it's still relevant. So while I'm sort of talking about this, this is the console view of of Akeyless where you can see all of our different products, not just SRA, but there is, and you and you can quickly, you know, take a glance here of what else the same platform offers you beyond secure mode access, sequence management, certificate life cycle, encryption KMS, password management, and manager of manager for other secrets. All is included. We have no time to talk about anything else. So I'll focus solely on the secure remote access, and you can see this other view of the admin that can take a quick look of all the sessions that are now happening, their status, the session ID, the secret that was used to facilitate it, the end user that actually initiated them. And here, it's a it's a not really a a good indication because it's all me. It's just my demo environment. But you can imagine in a real scenario, there will be a lot of different end users in here. Going back here, we've discussed how you RDP to Windows, how you use web console access to different cloud consoles, for example, and databases. I think the two main ones that we want to talk about are Kubernetes and SSH. Kubernetes gives you, at least in the portal access from this browser, it gives you, again, a shell within a browser that gives you a prebooked or precooked kube config that points to the relevant cluster. In here, you can get pods, you can get namespace, you can do everything that the permission that corresponds with this, dynamic secret, which you can think of as a permission profile. You can have one dynamic secret that lets you be a cluster admin and another one that lets you be a read only user. As the SRA admin, you would decide which of your internal users should be able to leverage the temporary admin access versus the temporary user access. And you may choose to let your users have temporary user access directly, not through the set the recorded sessions. Maybe maybe that's not like a a palm use case for you that if a an end user that can only read and and get the status of your prods, it doesn't always have to be the most extreme measurement of security. You wanna find the right balance so that you don't frustrate your end users when it's not really required, when it's not privileged access. And that's another sort of nice thing about this platform is that you can create the same target and associate one dynamic secret to it that is permissive, that is requiring POM session recording, and another one that isn't based on the same target, same platform, same RBAC. That's how how platformed it is. That's not a word, but I think you understand. Now so this is just a nice example of what it looks like in Kubernetes, but I will show you hopefully, we'll have enough time. I'll also do it from the CLI because it's probably more of a realistic use for most Kubernetes users. And last but not least, we'll look into how we SSH. SSH is its own unique implementation in terms of just in time. Just in time, typically, in other cases that I've shown so far, is a dynamic secret, meaning we go behind the scenes, create a temporary user against that target, retrieve its credentials back to the client, in this case, in a seamless fashion that it doesn't even know it's done for the user, and then it gets revoked. But here with SSH certificates, that's the core concept here. What we have is actually a public CA certificate or a public CA key, sorry, that could be just the one for the entire company or for all of your hosts and it could be provisioned across all of them. It's a minor change in the SSHD config file and it allows certificates signed by the corresponding private key, which is protected in Akeyless and is used as a DFC key. Again, our root of trust, which is a truly unique offering we have. It's able to sign just in time temporary SSH certificates that allow you to log into the server in a native fashion just like you would with SSH that you typically probably use minus I and give the pem key over there. Except here, it's not a key, it's a certificate and it has an extremely low TTL. The time to leave for the certificate would typically be in seconds. And how come we can how come we can do that is because SSH actually only needs the certificate to be valid for establishing the connection. Once you're logged in, it doesn't matter if the certificate is already expired. It will only kick you out after a stale time out or after you just exit the session yourself. But that's how SSH works, so we're taking advantage of it and telling end users, you could end you could do it either here from the portal like you're you're you're seeing here and everything will be recorded and you can see who am I, and you can upload and download files here like an SCP in a in a managed fashion, but you can also do it natively from your own terminal. So let me let me put it on a different background so it's easier to spot. But I would have my own Akeyless CLI configured here, and I would use something that looks like this, an Akeyless connect command. Right? The Akeyless CLI is something you would already have, and it would have a profile tied to your IDP. You will see it in a second. And then I give it just like normal SSH, username at server, and then in this case, I'm telling which gateway to use. This could also be, done behind the scenes if you always if you always use the same gateway, but obviously, in my environment, I have, like, three different ones I could choose from, so I have to specify it in this case. And when I log in, the first thing it does is it authenticates me, in this case, against Okta using SAML. Yep. And then hang on. I'll put this as the background. I'm logged in from my native terminal. I'm running on a Mac, and I have a completely regular experience. I can use my own copy paste. There's no, like, extra clipboard to go through. No clunky upload, download. It's all native terminal, and you can do it all from here. And the the ability to provide end users with their own native terminal experience makes all the difference in an SRA implementation or a PUM implementation because it's very nice, and I don't know, you know, who's who's watching us, how many of you guys are are are from the security organization and how many of you are, let's call it, the more hands on DevOps people that that typically would have to or IT people or or platform team that has to connect to all these different environments. Even if the the CISO is happy with a privileged access solution, if the end users don't adopt it, if they don't feel like it's it fits into how they work, the implementation is doomed to fail. Even if we would really want it to succeed for all the right reasons, you must at least that has been my experience. You have to get the you you need a carrot, not a stick. Right? The stick may work in the in the most strict environments, but if you want this to be a big success and and true you know, truly adopted, that's the that's the better way at the very least. So this is this is the Akeyless Connect experience. And on the Kubernetes side, I mentioned we could also leverage Akeyless Connect, by the way, with any let's call it textual type of connection. So it could be SSH, databases that expose a CLI, even something like AWS CLI, and obviously, kubectl. Right? So anything that has a potential CLI or terminal like interface, we can take advantage of it. And in this case, I wanna log in to a cluster. In this case, I'm telling it the namespace and the cluster endpoint URL. And I will be given the same kubectl sort of built in client, and you can see behind the scenes, it still leverages an SSH certificate to connect me through the gateway itself. But now I have, again, the ability to use kubectl, of course. I need to Nice. I don't have to mess with kube configs or anything like that. It's done. You don't have to. That's that's very much an option, and this is recorded, and that's really nice. But I had many customers tell me, yeah. But I wanna use my own KubeCTL with the KubeConfigs. I wanna use Lens or k nine s. So for those use cases, the I mentioned the thick client support. You're able to use those same connections behind the scenes but at a tunnel. Right? Essentially, it's an SSH port forwarding based tunnel that you're choosing the local port for yourself. In this case, I choose fifty five fifty five. And then what it does is is it's opening a tunnel that's happening on one of your tabs. Now it's listening and I'm still recording, by the way, the API server of Kubernetes for every call it's going to get. So I still have eyes in what's happening even though it's end to end encrypted for the end user. And here on another side, I have a pre prepared kubeconfig that all it has inside is pointing to my own local host over port fifty five fifty five. Right? And I can create as many of these as I want. Obviously, there's no there's no restriction, and I could then have my native thick clients use this as the kube config. Easiest example is obviously just a plain kubectl get pods that points to this kubeconfig, but I don't think that's not the most impressive one, but it's, I think, maybe the easiest one to understand. And then you can see I was able to run kubectl. And on the other tab, you will see that the API server got a request to get pods. Yeah. Right? On this namespace, my apps, it was got it got a get a get command to list pods. So that's another sort of finding the the the right middle between your security requirements, wanting to be able to leverage just in time access and make sure you're recording the sessions, but let your end users agree to use it, right, in a way, if that makes sense. Yep. These are some of the examples we have here. I don't know. I mean, if you have any other use case or example you would want us to, to discuss, let me know. We have one question here in the q and a. What protocols do you support for session recording and credential injection? So the session recording, we have the RDP you've seen. It's actually doing a session video recording. It would create the actual videos that you can later watch based on files that we upload to your, repository of choice. For the textual sessions, you may have noticed throughout different examples that I've shown, it kept showing this indication that the session is being recorded, but it's something to notice. These are textual sessions. It's not a video recording. It's a transcript it's like transcribing all the inputs and all the outputs, all the STD in, STD out, and they're being streamed live to your log management or SIEM solution. So you can imagine all of these logs entering something like Splunk or Elasticsearch or etcetera. And you could actually be having predefined alerts for specific malicious, you know, commands that someone may wanna run, like a drop command on your database, and you could intercept it live while they're in session. You could get an alert telling you someone's trying things they shouldn't be on your privileged access session. And then remember, you still have the ability to go ahead and revoke their access. Right? You have power. You can actually do something about it. So at least with the with the textual based session recordings, it's more action driven than the than the video option that would allow you to go back to it retroactively, which is still a lot, but we are I I personally like the idea of being able to leverage the textual ones in live. Cool. And maybe for the other part of the question, in terms of protocols, at the end of the day, it sums up to five main types. Right? So there's HTTP or web browsers as a whole that we support for, and then that could extend to different websites or web applications. We even have I mean, this is a bit off topic. I I hope you'll excuse me or indulge me, but I we even have our own internal SRA solution at Akeyless for the support teams where they have to gain access to our SIEM solution. We're able to use a custom dynamic secret. Right? You've seen so far dynamic secrets for all those native targets that are very common in the world, but maybe you're using something that's not that common. Right? Maybe you have even your own proprietary app that you need dynamic access to or even something that's just not yet natively supported. You can add your own custom dynamic secret by exposing the APIs to create the user and revoke the user. Right? And the gateway would trigger that endpoint and then have SRA injected for you. You get access to, in this case, our log management solution, view the logs for from a support, you know, a hat, do what you gotta do, and after fifteen minutes, thirty minutes, whatever you decide for this to be or after the session gets terminated, that credential would revoke. So you, as an end user, don't actually get to know what the password was. And it works even for the things that you haven't seen here on this demo. So that's web applications, and beyond that, it's everything you've seen, SSH, RDP, SQL, and KubeCTL. Nice. Excellent. Yeah. While you were talking there, I don't see, I don't know if there's any other questions. If you wanna put those questions in the q and a, we're ready to to take questions. But as you were talking there, Netser, I was I was thinking about we are talking about human access, but very soon, probably, we already started, AI agent access, which probably and I think Akios already is thinking through this and already has some some thoughts on that. Have you come across that yet with with your customer base, or have you talked through that? Brilliant question. I think I don't know if I've gotten a an explicit request about how an AI agent would securely acts like, have a secure mode access session. But the beauty of the platform is that it's already ready for those use cases. Because if you've seen some of our other episodes in this, you know, identity security series, I think that even the first one, we've started by showing an example of how an AI agent could leverage dynamic secrets very similar to what we've just been using behind the scenes Right. To use an MCP connection, for example, to a MongoDB database. And you could have that same AI agent potentially connect to that same database with our gateway intercepting the connection in the middle and making it recorded and secured so that the AI agent doesn't actually have direct communication from a from a Zero Trust network perspective. It wouldn't be able to access the database if it's not through the gateway in this SRA solution, and then it would also record what an AI agent is doing. That's yeah. That's that's where things get really interesting because we don't even know what we don't know about what AI agents would think about doing in such a permissive privileged access to potentially your company's digital assets. Yes. Great point. Great point. Cool. Any other questions from anybody on the webinar? Great demo, by the way, Netser. Appreciate it, Sam. Great presentation. We should do this more often. Right? Yeah. Right? It's funny. I saw the the text, the what's it called? The text file that you put into the Windows machine that we were looking at beforehand, yesterday or the day before when we were preparing for them. It's still there. Yeah. It's not it's continuous, session access. It's not going anywhere. Exactly. That's the beauty. Okay. Well, if there is no other questions, I hope you enjoyed this webinar. Thanks for joining us, and this webinar is recorded. So if you have to step away, you will get the recording. And once again, thank you so much, Netser. Appreciate it. And we'll talk to you folks on another one. Take care. Thank you all. Thank you, Sam. Cheers, sir. Bye.