Eliminating Privileged Access Toil with Infrastructure Identity
Transcript:
Introduction
Gus: Hey, everyone. My name is Gus Luxton. I’m a Specialist Solutions Engineer here at Teleport. I am going to put this on screen, and let’s get ready. So the title of today’s webinar is Eliminating Privileged Access Toil with Infrastructure Identity. And my hope is that, whether you’re a seasoned professional who’s already deep into short-lived certificates and identity in your infrastructure or whether you’re just getting started out — my plan here is — I’d like everyone to learn why static credentials and long-lived privileged access is bad, how you can start to move away from this and adopt something that scales better into the future, and what some of the benefits are and some of the things that you might see as an advantage. Now, I’ve been told we do have some gift cards to give away to the best questions that we select today, so if you do have questions at any point, please use the Q&A box at the right-hand side to ask those. We’ll have time for questions at the end. We’ll make sure to cover some of those.
The toil of legacy PAM
Gus: So I’m going to get started. Let’s go. So let’s find out why are you here. As a person, why did you come today? Well, let’s think about what toil means. So the definition of the word toil is: work extremely hard or incessantly. And it’s that incessant part that I’d like to focus on. It means that it doesn’t stop. It just goes on forever. And if you were to tell me that you’ve never had to use a legacy workflow where you have to check a password out of a vault and then copy and paste it somewhere to get access to something, I’m really, really pleased for you, because I’m going to tell you from experience, that can be incredibly painful, and I feel for you if you’re in that place. It’s fine the first few times you do it, of course, but when you need to access all of these different environments multiple times a day, it gets really old quickly. And then there’s other roadblocks that go on with this as well. You’ve got those servers in Azure, for example, that you can’t connect to unless you’re on a VPN. They don’t have to be in Azure. They could be anywhere. But maybe you have to be on a VPN to get access to them, so now you’ve got to start that again. And then when you connected to the VPN, your other sessions dropped because now you’re on a different network and, ugh, your routing table’s changed. What a pain. And now you have to switch back and forth and juggle all the sessions just to be productive — just to get on with your job. And don’t walk away for too long because your session will drop if you’re gone for too long. You’ll be disconnected because you’re idle.
Gus: How about if you work on the security side of your organization, for example? You’ve got people complaining about how they can’t get anything done because of all those things I just mentioned, and they make it your problem to solve. Or how someone urgently needs all those audit logs for a session that happened — they can only tell you it happened sometime in the last week, but they can’t be more specific. So now you’ve got to go and search for them manually. Or how about if you work in ops and you’re really fed up with how you have to go and fix your password rotation failures every month? Some credentials have expired, and you’ve got to deal with that. Or you go to sign in to fix that, and then you find that your access has mysteriously been revoked overnight, and nobody seems to know why. If you’re on the network team, all the VPN complaints about how slow it is and how people can’t connect and how it doesn’t work the way they want. So that’s the sort of things we’re going to talk about today. We have a better solution to this, and we’d like to talk to you about it.
Gus: So I’m going to start a quick poll, actually. I am going to ask some questions about what you are using for your access today. So if we can get that started, we should be able to put a poll in the chat. So the poll is open now. If you go to the Polls tab in your chat, the second one along, you should be able to choose an option for how you’re managing privileged access currently in your infrastructure. So I’ll give you a couple of minutes to work on that, I’ll go on to the next slide, and I’ll share the results of that shortly. So please do vote on that. So why does this matter now? Well, this has always been a problem, right? But the truth is that, in the past, it was good enough. It was something that you could get away with. But that, honestly, is becoming rapidly not the case anymore. There’s a lot of reasons for this. I’ll go into a few of them now.
Gus: So modern infrastructure is really ephemeral. Many organizations are using short-lived infrastructure that’s spun up on demand, used for a short time, and then discarded when you don’t need it anymore: Kubernetes Pods, containers, ECS, this kind of thing, always across multiple different clouds in many cases, on-premise, cloud, wherever you want to keep it. There’s a lot of different demands that go on this infrastructure as well, so more than ever, development teams have adopted more of a DevOps mindset. And they’re free to manage and build their own platforms to run a service, but this introduces a lot of headaches as well in terms of managing that access and keeping things secure. There’s also the fact that the use of non-human identities has exploded, so CI pipelines, build services, cross-cloud service workers, and, of course, let’s not forget AI agents. Trying to quickly make sure that you can provide access to infrastructure while you keep everything secure, that’s difficult. It’s very hard to keep up with. Platform and security teams are the ones who are responsible for this, and they’re being spread really thin, trying to allow everybody to get access to all the resources they need, all the while not slowing down delivery and keeping everybody safe from a potential breach. A lot of the existing solutions out there do rely on the distribution of longer-lived credentials: service account passwords, API keys, things like that. And trying to make sure that credential rotation is being performed correctly when the infrastructure is ephemeral and comes and goes all the time — that’s pretty tricky. This has a real business impact and a cost there too. The costs go up. The delivery time becomes slower for services, for software. Auditing all of that access becomes very difficult, if not impossible. And the potential blast radius, if there’s a breach or compromise, could be bigger than ever with all the multiple clouds and different accounts in the mix.
Gus: And I’m going to tell you a little story. I don’t want to scare anyone or keep you up at night, but it’s not just the good guys who are making use of AI and LLMs to speed themselves up. We’ve all used tools like Claude. We’ve all used tools like Coda, all these kind of things. The bad guys are using these sorts of tools too, and they’re using them to attack infrastructure. They’re using them to find weaknesses, and it’s easier than ever for them to try different techniques for social engineering, for phishing, for credential theft, SSH scanning, probing for weaknesses. So honestly, if you’re still using static, long-lived credentials, they’re just not good enough anymore. Humans will always make mistakes, and it’s not a case of if you get hacked, but when you get hacked. So the bad guys are waiting for their chance to strike.
Gus: I’m going to show the poll results now. I think I have to stop sharing this. So these are the votes we’ve had. So how do you currently manage privileged access? So we’ve got a fairly even split of votes across the poll. So we’ve got two votes for SSH keys or another homegrown solution, some manual credential management and sharing, vault or credential stores. So less for just-in-time elevation, less for Teleport, and same for Other. So definitely more on the static keys and the privileged identity side. So that’s definitely interesting. I am going to switch back to my slides. Okay. All right.
Infrastructure identity unifying human and non-human identities
Gus: So what’s another solution to this? How do you get away from that same credential confusion? Well, the answer is — you use identities. So what’s an identity? Well, a human has an identity. It’s who you are. Computers and machines have an identity too. And knowing the identity of what’s trying to access your infrastructure means that you can use that to make decisions about what it should be allowed to do rather than just having possession of the credentials which allows you to take actions. So the idea behind it all is this: you start using a universal language or a policy to define who gets access to what. That’s one story for everything across all of your infrastructure, so roles and role-based access control for both humans and non-humans. You start to unify that behind the same platform, where you take away standing access by default, and all the access that you do give out is backed by strong cryptographic identities, so things that are validated by multiple factors for humans, like a password and a fingerprint, password and Touch ID, password and YubiKey, those kind of things, or hardware identifiers, like a TPM, a public key built into a machine, backed by a private key which you can’t get access to. The idea is you get away from long-lived secrets and API keys. So use short-lived identities wherever possible. These can be certificate-based. They can be other ways. But they should be short-lived, and they should be scoped only to give you access to specific resources. So you enforce just-in-time, least privileged access which expires by default, and you have clearly defined policies that say what people can do and what they can’t.
Gus: You should try and measure the access lifetime of users in hours, not months or days. So when you know that that access expires by default, you can give it out, but you know that it’s going to expire when someone’s done with it, and you don’t have to worry about those credentials being left around for long periods of time. Start from no access at all. So take away standing access, and just get people to request access to what they need when they need it. And make use of automated review wherever possible so that people aren’t slowed down. Get the team members to review their access. Have automatic approval policies for low-impact environments, but make sure that you still keep the approval process for production or higher-priority environments. And most importantly, you need to centralize visibility. You’ve got to keep one audit trail going across everything. So by putting everything through one platform and having this unified trust layer, that gives you that audit trail that lives in one particular location.
Driving transformation with infrastructure identity
Gus: So what does this get you when you do it? Well, here’s some of the outcomes that you could expect. So number one, engineers are able to move faster. So that means no more switching around between VPNs or bastion servers or anything like that, no need to keep going through separate access through separate means, and no more waiting on Jira tickets to get provisioned for access or having to have credentials rotated for you or anything like that. Doing this means that your risk drops drastically. Long-lived credentials — they go away. Standing access — it goes away. Lateral movement — moving between servers with keys that are in place — that goes away too. It’s all no longer necessary. And just the same with credential rotation, no longer necessary at all. And when you do this, your auditing process becomes easier too. So you have the complete audit trails for both humans and non-humans in one place. You have that one centralized place where you can control your access, and adding new users to the environment or offboarding your old ones gets done centrally, too, and becomes drastically simpler. You don’t have to go and manually remove those or deprovision people. You can do that through the central platform that manages that. Your access story for people becomes a lot simpler too. So new staff can automatically be added to groups that give them access to the resources they need, and it becomes one consistent control plane for managing the policy across all your environments. And that one place for policies means you can use exactly the same policies for humans and non-humans, and then AI agents as well. You can grant them the same access as you would use, to limit access to other resources. And those same policies can just apply to your existing infrastructure, so it can speed up your delivery a lot. Moving to just-in-time access and via these short-lived permissions rather than having standing access — this means that if there’s no task actively being performed, if somebody’s not actively accessing your infrastructure, that goes away. And then that means there’s no standing access to compromise, and non-human identities are scoped to only provide the actual access that they need at any point.
Customer case study: Before Teleport
Gus: So let’s look at a little case study, for example. We have a customer in the financial services industry who was using a legacy PAM service to access their infrastructure. They’re in a very heavily regulated environment, as you’d imagine. They’re in the financial services sector. They go through many audits every year, and they told us it was hours and hours of manual work to provide the auditors with the video-based session recordings that they needed to prove access, and proof of the access policies that they had in place too. They absolutely dreaded the audits that they had to go through. They had teams on their staff that were solely responsible for making sure that credential rotations that they were mandated to do by policy were actually happening and then going and fixing the issues with those when they didn’t happen automatically. And they told us this took an awfully long time. This happened a lot. It was something that broke frequently, and it was the bane of their existence. The maintenance of that existing solution took up a lot of the ops team’s time. And trying to keep everything up and running and making sure that everything was good — that was difficult. And even with a distributed workforce that was across different sides of the planet, it was still a nightmare for them. It was still something they found very difficult.
Gus: The other issue they had — and this was a really big one — was that this existing service that they had, although they were hosting it themselves, it was unreliable, and it let them down when they needed it the most. There was a senior engineer who worked there who told us a story. He was responsible for this service. He went away on a two-week vacation with his family. The PAM service had a huge outage going on, and nobody could get into anything. They tried to get support from the vendor, but the vendor wasn’t particularly helpful, and this engineer had to work 12-hour days. He was on the other side of the world. He had to work 12-hour days in the middle of the night, couldn’t see his family, and had to spend all this time just trying to get everything back up and running, because they needed it. It had to be working there and then. They couldn’t wait until anyone got back. So he spent all of his vacation trying to fix this problem. And they did get it back up and running, but he vowed that, “It ruined my vacation. I’m definitely going to find an alternative to deal with that.”
Customer case study: After Teleport
Gus: So they started looking at Teleport. They found out about it, and they tried it out, and what they were able to do is move their platform — or move their access onto the Teleport platform instead. So now, rather than having this disparate, spread-out access platform, they liked that they had policy all in one place. They liked that it was much easier to get session recordings for any session, no matter where it went on, and they liked that all the policy was centrally defined. It was very easy to script and automate, and they could make some strong guarantees about the identity of the users and the services that were being accessed. And best of all, all those headaches about the credential rotations that they had to do, they were reduced drastically, because there are no credentials to rotate with Teleport. You don’t have to worry about that. It handles the expiry of credentials and issuing of short-lived certificates and identities for you.
Gus: They started out with a fairly small use case that was going on, where they onboarded access to some of their databases that didn’t have privileged access management in place already. The feedback that they got from their database teams where they started out with this use case was incredibly good. They said they liked it. They said it was easy to use, and they found it smooth. So, slowly, they expanded this out to more and more of the databases they’re using. We talked to them again recently, and they said that they are completely content with Teleport, and they’re incredibly happy with the speed at which they’ve been able to roll everything out. They said, “Five months from start to production. This is incredible. We’ve bought other PAM tools in the past. We’ve bought and tried all of them. We’ve tried everyone under the sun. None of them have ever been as good for us as this. None of the feedback has ever been as good. The teams have never liked it as much.” And so now they want to consolidate on Teleport.
Gus: The next step for them is going to be that they’re bringing their non-human identities into Teleport soon, anyway. They make a lot of use of Ansible internally, so they’re going to be recoding all of their Ansible to use identity through Teleport, non-human identity instead, and get the centralized management and visibility into that. And they’re also looking into CI pipelines. They’re looking into other jobs and other services. They have a lot of non-human identities, and they’re really excited to start looking at how to bring all of those through the same platform and keep the policies all in one place, and the audit logging too. They’re also moving forward with replacing all of the existing production access that they had with access through Teleport. It’s a slow process. As I said, they’re a regulated industry. It takes them a lot of time to make changes. Uptime is a huge priority for them. This is an incredibly distributed global service. Trust me — you’ve heard of them. You probably use them on a daily basis. It’s very important that they keep everything up and running. So it’s a slow process, but they’re getting there, and they’re really excited about it.
How to get started
Gus: So let’s talk a little bit about how you could get started on the same thing with your identity-based infrastructure access journey. So we’re going to talk about this in terms of the crawl, walk, run phase. So to start off with, in the crawl phase, think about one particular flow that you could change, one thing that you could alter. So think about a just-in-time access path that you could use to, say, a high-value resource or something like that — maybe a Kubernetes administration user, something with administration credentials to Kubernetes clusters, maybe a production database that people need access to, something that you really want to protect and something that’s important. For this one particular case, implement just-in-time access via those short-lived permissions. Test it out. Get users to use it. Make sure that it works. Make sure they understand it. Make sure they know how to use it. And then, in the walk phase, when you start here, switch off the standing credentials, switch off the legacy access, just for that particular path, and then mandate that you must go through the new short-lived access path instead. Test this out. Get people to check it. Measure the metrics. Look at the time it takes to do things. Look at the ticket volume if you’re using tickets to provision access. Look at the time it takes for people to do their job. Just watch what they do. Just watch an engineer on a daily basis, what they used to do with the old method and what they do with the new method. Check the ticket statistics. Check all of the metrics. Measure, measure, measure. That’s the most important thing here. Measure to see what you’re doing as a better story from what’s going on.
Gus: When you’ve got this information — when you see that the metrics have improved, you can start to use this to make a broader case for just-in-time access across the rest of your organization. Span this out to other services. And you don’t have to do this immediately. This can be a slow process that you do over a period of time. But the point is that moving forward and driving the metrics slowly down, making sure the tickets are — they don’t take as long, the access provisioning is not something that you spend time on, the toil, the general frustration that you’ve experienced — if you can drive that down and find a way that users are still happy but you’ve got a lot less work to do, that’s a great improvement. And the more you scale this out, the more wins you’ll see. And you can move as quickly or as slowly as you’d like to. It’s just a question of: find something, start somewhere. It’s kind of standing at the bottom of the mountain and looking up, but if you start somewhere, you start to realize it could be less daunting than you think. Scale it out to handle Kubernetes non-administration users as well, so daily level access. Look at cloud consoles. Look at SSH. Look at applications. Look at databases. Look at Windows. You really don’t have to boil the ocean here. That’s the thing. You can start with one thing and just prove it works. Make sure that you’re seeing the changes that you expect and that things in general are trending in the right direction.
The Teleport Infrastructure Identity Platform
Gus: So, obviously, I’m going to talk to you a little bit as well about how Teleport can help you do this. So Teleport is based on short-lived infrastructure identity from the ground up. But what are some of the other benefits that you can get? So Teleport does use that identity-based, short-lived access from the ground up, and this expires by default. It makes it easy to start with small use cases and expand as needed to — Teleport can grow with you. We have people in all sorts of different-sized companies, different environments, different sectors, different regulated/non-regulated industries, FedRAMP, all of these things. We work with all of them, and we’ve managed to find ways that we can help everybody to do this. Teleport integrates with OIDC- or SAML-based identity providers, so if you use Okta, Entra, PingFederate, any of these other sorts of priorities, Google, any kind of other provider, OneLogin — all of these things, we support all of them. And if you’ve already got identity in that place, you can plug this into Teleport and get yourself a really easy source of identity right from day one. Teleport integrates here, and then it brokers that issuance of the short-lived identities, the short-lived certificates, to the end users. Teleport’s also a managed PKI, a public key infrastructure provider. So we take all of the headaches out of managing certificates for yourself. It can be tricky. I’ve talked about credential rotation a lot, and I’ve said that credential rotation is a real problem. Rotating certificate authorities manually can be a pain as well. But this is the thing — if you use Teleport to do this, it takes the headache out of doing it. We manage the certificate authorities. You can rotate them on demand, and we handle issuing new identities to users and resources automatically. So you don’t have to think about it, and you just get to focus on the things that matter.
Gus: Teleport covers a whole variety of different services and protocols. So we cover SSH servers. We cover Kubernetes access. We cover databases. We cover applications. We cover Windows. We cover cloud consoles. We cover APIs. We cover MCP servers for AI. We cover GitHub. We cover workload identity, machine identity, SPIFFE, those kind of things. And we’re adding new things every single day. This is our job. We do this. We take the headache out of doing this so that you don’t have to. Teleport can also enforce Device Trust at the edge and role policies and session controls, so we can assert that you are connecting from a trusted device, a laptop that you have enrolled into your Jamf or your Intune infrastructure. You can enroll serial numbers manually. You can trust TPMs on Linux machines. You can assert that users are connecting from trusted devices to Teleport, and you can block their access if they’re not using those. So that gives you extra control over what you’re doing. The policies are all defined in a central location, and there’s an easy way to express these and change them.
Gus: Teleport provides rich audit data as well. So because there’s a single platform where all of your access goes through — there’s a compliance angle to that, the forensics angle — we provide all of that rich data that you need. And most importantly, we have both self-hosted and cloud offerings. So if you want to use our SaaS platform, we run all of the control plane for you when we manage all of this, but you can also self-host this. And even when you do self-host it, you run the components, but you still get the benefits out of the managed PKI, the certificate rotation, the short-lived identities, all of these things. And you can run this in any platform that you like. It’s just a simple Go binary. You can deploy it on-premise. You can deploy it in your own cloud accounts. You can split it across. You can do multi-region. You can do all kinds of things like that.
Trusted by industry leaders
Gus: So Teleport has a lot of customers that are leaders in their markets. It’s a great solution, like I mentioned, from any size, enterprise-grade hyperscalers — we have a number of customers in that bucket — all the way down to smaller customers and teams that are just starting out. So if you’re interested in this and it’s something that you think, “Oh, well —” if you want to use the same sort of security standards as some of the biggest companies in the world do, something like Teleport is a great bet to use for that. Do you ever notice that — I say hyperscaler companies. I’m talking about the Googles, the Facebooks, the Amazons of the world, those sort of things. You ever noticed that they’re not in the news because of security breaches? Now, that’s not just because they have good PR teams, which obviously they do, but they’ve adopted certificate-based authentication early on, and they can make strong guarantees about the identity of their users. So this helps them to prevent being breached as well. So despite the fact that they have some of the highest numbers canonically of server counts in the world — they’ve got these huge deployments and global workforces. They employ tens of thousands, hundreds of thousands of people. And despite that, they’re still able to run these and not get breached. And part of the reason for that is because of robust security policies and using identity-based infrastructure management to do that. And this isn’t just about authentication and credential management. It’s about building your entire architecture from the ground up around identity. You can go to the concept of zero trust or BeyondCorp, or things like that. It all goes into the same thing. It’s all the concept of infrastructure identity and making sure that you do this.
Gus: So we talked about toil at the beginning. How about some of the benefits that we’ve seen? Here are a couple of unsolicited quotes from Teleport customers. We had our Identity Summit recently in San Francisco, Teleport Identity Summit. Lots of customers and prospects and people who are interested in Teleport, Teleport fans, came and talked about us, and we had some really cool quotes, “Running automation using Teleport is fun. I’m able to impact my entire customer base without all the log-in churn I used to have and do it in a way that doesn’t scare security.” It’s interesting to hear that using what’s fundamentally a privileged access management tool could be fun, but that’s what he said. It’s fun. It’s one of the coolest things he’s done, is fleet management, where you can do all of these things, and there’s nothing stopping him from running commands across everything. And the security team isn’t worried about it at all. Another thing that someone said was, “Our auditors love Teleport. It reduced our audit time by 80% and labor costs by 40%.” Genuine quote from someone using Teleport who said, “Our auditing got so much simpler when we did this.” That’s a really, really positive impact that people have seen. That’s a huge cost saving, that’s a huge time saving, and it lets people get on with the things that they want to do on a daily basis, the things that they really enjoy, rather than having to manage passwords and things that, really, they don’t want to do.
Q&A
Gus: That’s all my content for the presentation here. I’m going to go into some Q&A now. We will take a look at some questions, and we’ll see what we have. So we have a question here. I’ve just got to — Q&A. So here’s a question. Augusto, “Do you need agents installed on the user endpoints to manage their certificates?” Fundamentally, the answer is yes. So there’s kind of two parts to Teleport. You’ve got the certificates which you issue to users, which are handled by the control plane. So all the user needs is a log-in binary for Teleport. We have a client called Teleport Connect, which is an Electron client you can use on your desktop. So you log in, and that gives you your short-lived certificates. And that will give you access for a period of time, which is configured. So those certificates that are issued to users, the short-lived certificates, you just manage those locally on your laptop. In terms of managing the certificates for, say, an SSH service which is joined to Teleport, yes, there’s an agent binary that runs. So Teleport has a Go binary that you run. It will handle the credential rotation automatically. So it handles that certificate authority and the rotation, the issuing of the certificates. It manages all of that. And if you do a certificate authority rotation in Teleport, then it will handle that for you automatically. So for other things, like databases and Kubernetes and things like that, there is an agent too, but you can deploy these in more of a kind of one-to-many structure where you run one agent and that provides access to lots of different things. So there’s a bit of nuance to this, so we’ll be happy to discuss some more of this if you need to.
Gus: Masatoshi asks: “Do we have any use cases for using vTPM in cloud environments?” That’s a great question. So we haven’t focused specifically on vTPMs, but for example, in AWS Nitro, things like this, where there is kind of a virtual TPM, as you might [inaudible], which is exposed to the service — Teleport does make use of that. So if you have a virtual TPM exposed to the Teleport process or to a process which is running a Machine ID service, say, or something like that, if you have access to that, Teleport can use that identity to assert the identity of the hardware. So I guess the answer is, sort of. We haven’t specifically focused on vTPMs, but the fact that Teleport does support TPMs in general means that if there is a virtual TPM exposed to Teleport, we can make use of that. And I hope that over time we end up with a better, kind of more rich environment for virtual TPMs inside containers and things like that. I hope that we continue to focus on that.
Gus: So another question from Augusto, “How do you avoid the use of VPNs to connect the user to the servers?” That’s a great question. So in general, the way that Teleport works is, we have what’s called a proxy service. So there’s two main parts, what we call the control plane. You’ve got the auth service, which is the part that manages the certificate authorities and the credential management and the issuing of those short-lived certificates to users and to resources, and you’ve got the proxy component. The proxy component is the only part that needs to be public-facing. It doesn’t have to be public-facing. You can actually put it behind a VPN if you’d like, but you don’t have to. In our cloud platform, for example, our managed SaaS service, we do expose that proxy to the — so the user connects directly from their laptop to their proxy endpoint. And we have regular kind of third-party security assessments and things going on with that. So we do assess the security of Teleport regularly. We run the service, and we believe it is safe and secure to expose the Teleport proxy service that users and resources connect to. We believe it’s safe to expose that to the internet and that users can connect directly, because the benefit of doing so is that not needing a VPN means that the headache of managing that on the user side goes away. You don’t have to distribute credentials to the end users. You can use single sign-on through Teleport, that zero-trust kind of approach, as a way to manage who gets access to what, the idea of zero trust being that, inherently, you shouldn’t be trusted just because you are connected to a network. So you can use a VPN for defense in depth if you want to, absolutely. If you would rather have users connect through a VPN to get to Teleport, you’re completely free to do that, and we have a lot of customers and people who do that. But you don’t have to. And if you want to take that VPN headache away, there’s totally a feasible way to do that that’s completely secure, mutual TLS end-to-end, no inspection, those kind of things. You can do those too.
Gus: Question from Manoj here, “In environments that use multiple credential vaults, does Teleport support them as is, or is migration to certificate-based authentication implicit for those services?” I’ve said this about all these questions, but this is a great question too. We’ve had some really good ones here. Thank you so much for your thoughtful questions. I really appreciate these. So in these environments that use vaults already — Teleport is not a vault-based solution. It doesn’t support vaults. It doesn’t make use of them. So the answer to your question is, yes, migration to certificate-based authentication is implicit and mandatory for those. But this is part of what I mentioned with the kind of crawl, walk, run strategy, where you don’t necessarily need to cut over wholesale. The majority of services out there, modern services, do support certificate-based authentication. I’m talking most modern databases. I’m talking applications with JWT. I’m talking Kubernetes. OpenSSH supports certificate-based authentication implicitly. Windows as well, at the domain level and at the non-domain level. You can install an authentication service which will handle certificate-based authentication via smart cards. So a lot of the services. We tend to see the — people say, “Oh, I’m kind of stuck with using vaults,” and in some cases, for legacy things that have been around a long time and don’t support certificate-based authentication, that’s true. But what you can do is, with that phased migration strategy that you can do, you can migrate a large part of your access — anything that does support certificates, migrate that to Teleport. And what you’re doing by doing that is, you reduce the blast radius of your attack surface drastically. So if you’re going from 100% on a vault to 5% on a vault, or 10% on a vault, or 15% on a vault, that’s still a huge reduction in the amount of static credentials and everything that you have to manage. So that gives you a commensurate decrease in the amount of time and effort that you have to spend managing these things.
Gus: Another question by Augusto: “Can you use native apps to access server, e.g. PuTTY to access Linux SSH server or RDP for Windows?” So these are a couple of interesting ones. So PuTTY for Linux and SSH, absolutely you can. You can also use any SSH client you like, so OpenSSH. You can use Visual Studio Code with its SSH integration. You can use things like IntelliJ. You can use Paramiko, the Python SSH client. You can use Ruby. You can use all kinds of things. So if you’ve got an SSH client, then yes, in 99.9% of cases, Teleport will support the use of it as a client. So the actual experience for your end users doesn’t change much. They modify their configuration a little bit, but the actual day-to-day of that — they can change their workflow, going from signing in with PuTTY using a password from a vault to signing in with PuTTY going via Teleport with a short-lived certificate, and still get the same experience. And what actually changes for them is, they just don’t have to get the password out of the vault anymore, and they don’t have to copy and paste. All of that part’s automated. So absolutely, you can do that. RDP for Windows is a little trickier. In Teleport, to connect to a Windows machine, we have a thin RDP client which runs in the browser or runs inside our Teleport Connect application. So we don’t support the use of a native RDP client directly. There is a little bit of nuance to this. You can use it. You can expose server ports and use RDP directly if you want, just through TCP application access, but you don’t get the credential management there, you don’t get assignment of what users can log into what with Teleport, and you don’t get things like session recording. But if you use the Teleport native client, you get all of those things. You get management of the users that can connect. You get session recording. You get comprehensive audit logging. You get all of that. So you’ve got all of those things available to you.
Gus: Well, that was some wonderful questions today. Thank you so much for those. I think that’s it. That’s all the content I had. Thank you for your questions. Those were absolutely wonderful. And as Kat mentioned, we’ll be following up with the recording after this. Thank you so much for coming. I really appreciate your time, and I genuinely hope that you learned something. If you want to get in touch with me for any reason, there are ways to do this. I think I have this here. So if you want to email me, I’m — or you can contact me on GitHub. I’m @webvictim on GitHub. [email protected] is my email address. So if you want to email me any questions like that, please feel free to, and I’ll be happy to get back to you. It’s been a pleasure presenting for you, and I hope you all have a lovely day. Thanks so much.
More Resources:
Join The Teleport Community
