Experience Frictionless Access Without Sacrificing Security

Experience Frictionless Access Without Sacrificing Security

Are you tired of hitting roadblocks just when you need to make critical updates? You’re rushing to resolve an issue, only to realize you’ve lost access to the Kubernetes cluster or database you need. You file a ticket, wait for IT approval, and hope it doesn’t take days—while your deadline looms. Sound familiar?

Here’s the truth: IT isn’t the enemy. They’re grappling with mounting cybersecurity risks and compliance demands. But that doesn’t make your wait any less frustrating—or your workflow any smoother. What if you could cut through the red tape and get secure, instant access to your infrastructure?

Join our engineering and security experts as they dive into how Teleport transforms infrastructure access. Say goodbye to ticket queues and credential sprawl with a unified solution for SSH, Kubernetes, databases, and web apps. Learn how to implement Zero Trust principles while eliminating access friction and empowering developers to meet their deadlines—without compromising security.

Stop letting outdated access processes hold your team back—let’s build a smarter, faster, and more secure DevOps environment together.

Three Key Takeaways:

• Discover how to grant infrastructure access instantly while improving your organization’s security posture.
• Learn to eliminate passwords and credentials from source and build files for a safer development pipeline.
• Explore practical strategies for implementing Zero Trust in a way that boosts engineering productivity.

Transcript - Experience Frictionless Access Without Sacrificing Security

Introduction

Davin: [music] Welcome, everybody. I hope wherever you are, you are warm. Welcome to today's session presented by Teleport and DZone. And the name of the presentation today is Experience Frictionless Access Without Sacrificing Security. My name is Davin Jackson, and I'm the cybersecurity specialist here at eSecurity Planet, and I will be your host for today's session. We are excited to be joined by David Sudia, the Senior Product Engineer at Teleport. It's great to have you, David.

David: Thanks for having me.

Davin: Like I said, I hope you're warm as well. I know you said you don't have to shovel in the condo, but like I said, I'm glad you can make it here today. So a quick note before we get started, everybody, feel free to use this chat feature that you're already using telling where we're from to comment on the presentation as David is sharing. We'll also be having a Q&A session after today's presentation. So make sure you drop your questions in the Q&A section as they come up so we can have time to go through them after the session is — after Dave's presentation is done. So with that, allow me to welcome David Sudia to the stage.

David: Thanks, Davin. Yeah. Welcome to Experience Frictionless Access Without Sacrificing Security. We're going to talk about some of the issues that exist in accessing infrastructure today, some of the frictions and frustrations, and then some of the ways that we're trying to solve them. First up, we've just got a quick poll to put out to you and just kind of see where everyone's at right now. I think I go to a lot of conferences and conventions, and these are some of the things I hear the most from people as we're talking about these problems and just kind of — I was just at KubeCon a couple of months ago, and someone was going, "Oh, we submit these access requests." And then four hours later, we're lucky if the thing we actually get is — actually if the permissions we get actually let us access the thing we're trying to access because the paths to that access is not always even clear. And yeah, so just kind of interested to see what issues you all are having. Difficulty making requests. Time for approval is too long. It's good to see that at least you all are getting the correct permissions once they are approved.

David: More time for it to be approved is too long. Yeah, I think it feels like everybody's got a system for making their requests. But whether or not someone actually gets alerted, whether or not it's easy enough for those people to approve it and find the right permissions to give you, I think, is always something that takes up some time. So good to know. All right, cool. We'll talk about that stuff as we go through here. So let's kind of go through a little story. It's Friday afternoon. It's a dark and stormy night afternoon. You've got a bug that's surfaced in production. Customers are already complaining. You may not know exactly what the issue is, but you probably know exactly where the issue is, right? You've got your logs coming in, you're able to kind of figure out, "Okay, it's this database or it's the server where the issues are happening." You just need to be able to get into that database and be able to debug, run some read queries, like maybe get access into something that gives you the direct logs as opposed to in the SIEM or something. So you open up the ticketing system, you request access, and as we saw in the poll, you wait, right? It could be minutes. It could be hours. But as we all know, when prods down, seconds feel like hours. And so it just kind of keeps going.

Addressing the tension between security and productivity

David: And this is the reality that a lot of dev teams face right now, right? You have approval processes. You know that if you could just get in and look at the logs in that pod, in that database or something, you'd be able to figure out what's going on. Maybe you've got a hot fix that you feel like should work, but you've got to get approval to deploy, and then it's got to go through the whole pipeline. And you're like, "What if we could just sort of direct 10% of the traffic over here, but you can't get in there to do those sorts of things?" And that was something I always struggled with as a developer. My background is that I was a full stack dev for a while. I ended up in DevOps and then kind of becoming a platform engineer. And so kind of I've been on both sides of this, right? I've been on the side of, "I just need to get this stuff done," and I've been on the side of, "But I'm not supposed to let you," right? We have to have controls around here. Things get complex, right? Especially now, you may be somewhere where you're multi-cloud. You may be somewhere where even if you're not, you've got your dev and staging and production environments, and everything is microservices, and there's just too many paths to get through and figure out what access you need to have, where it should go. And there's that temptation of, "Oh, okay, let me just build in a workaround," right? Let me just save this SSH key locally or just hard code this API key into the code. And we all know how well that worked out for Uber, right? Having these keys and tokens and things makes it more difficult to secure.

David: It makes it more likely that something's going to leak eventually. But the reason that this happens, right, is because there's a lack of responsiveness. There's a lack of speed. People need to get their jobs done. If they're unable to get them done because of processes that exist, then they're going to find workarounds. On the flip side, the security teams, the platform teams are not trying to get in the way of developers, right? There's always this tension between security and productivity. And if it goes too far in either direction, you're going to have problems. And I think when I was a dev, it was always easy to sort of blame and rag on the security team. But security is important, right? And the trick is finding productive processes that let people do their jobs while also being secure. And the security teams are dealing with scale that has not existed in the history of building up security practices. And we see that for developers, we see that for DevOps and Platform. We're all struggling with this scale. But I think often security teams are not given the training and background unless they're coming from a dev or platform background, right, to deal with this kind of scale.

Security team challenges

David: I think in the last couple of years, we've all seen from the top down an emphasis on less people doing more, and that also makes all this difficult. We need to come up with more efficient processes. And I think one of the real things, right, is that at the end of the day, security teams are the ones who are accountable for very critical processes like SOC 2 compliance, ISO 27001 compliance, these things where if they go away, the business is really fundamentally impacted in terms of being able to get new or retain customers, in terms of running into problems with the government. And they're the ones who have to go sit down with an auditor and check the boxes and answer why something isn't being checked. And so that's one of the reasons that's really critical to them that these things are in place even when it is frustrating for the other teams. So you have engineering teams managing infrastructure across lots of different systems. You've got these distributed models. You have identity compromises coming up because we're hard-coding API keys or just having identity tokens and keys and stuff and secrets in the first place. And this is something I personally dealt with in terms of trying to manage this stuff, right?

Access controls causing the friction

David: We would buy a deployment platform like Harness or something and try to keep the secrets in there so that they were already going into a Kubernetes cluster encrypted. We were setting up one password and sharing so that at least the secrets were in if it wasn't like an API key or something, if it's a password, at least they're somewhere secure, but does still have access and trying to make it easier so that the secrets don't end up just sitting in a text file and someone's that they can pull up in their shell. It's just really difficult to manage. And really, at the end of it, secrets are one of the big problems here, and making sure that the right people have access to the right things is really difficult. I was talking with someone the other day and they were just going like they have a secrets management system, but the problem they were having and the reason they were talking to us was people keep getting access to the wrong secrets and then being able to keep them. And with everything so spread out, right, so siloed, you're having to manage a ton of systems. Again, when I was a platform engineer, we had permissions that people had in Google. We had primarily moved to go over to Google Cloud. But we had started on Amazon, and we still had some buckets and stuff in there. So we also had permissions we needed to manage in Amazon across multiple accounts. And then people couldn't make direct network connections to talk to applications and to databases and stuff if they were developing like in our dev environment, or maybe they needed to just run a quick request through prod to see if a fix was working or something.

David: And so we also had VPNs we were running. And then we had to manage access into the VPNs and have the correct stuff there. So consolidating this into one place, into one way of managing access is just so difficult, but it's also such an important problem to solve. And it doesn't have to be like this. What you want out of modern secure infrastructure access is you want a single source of truth for everyone and everything. You want everything to be in one place so you can see what you've got and who has access to what. And you want all your people in one place. And I actually say you want all your identities in one place, not just people, but also machines. You want your CI systems, your CD systems, automatic jobs that run. When things connect to each other, you want to have session-level encryption. You want to have session-level authentication. You want every single session to be authenticated, right? And that forms the basis of a zero-trust system, is that you are not allowing things to connect without some form of authentication. And that's one of my biggest problem with VPNs, right, is that a VPN is not zero trust. If you're in the VPN, it now becomes assumed that you are a trusted identity, and that is not ideal. You want to get rid of secrets. As I was saying before, the existence of secrets and tokens and keys is one of the reasons that breaches are so common, right?

Teleport Access Platform

David: If a token represents an identity, if an API key represents an identity, then that's very easily stealable or uploaded to GitHub. And you're begging for eventually there to be a problem. And so the answer to that, to getting secretless, is to provide a cryptographic identity to every single part of the system, to humans, to agents, to laptops, to servers, to workloads, providing some sort of certificate-based identity to things so we can say, "Yes, this is that workload, this is that person, and that is how we're going to provide zero trust access. We're not going to trust this IP address. We're not going to trust this server. We're going to trust this identity." And that's what we do at Teleport. We provide this platform that provides all of those functions. So at the root, we have access as part of the platform, and it has a certificate authority in it. It provides a cryptographic identity to humans, to machines, CI/CD processes, jobs and stuff, Ansible, that kind of thing, like I was saying before, and any human who logs into the system. And then those humans via roles are able to access infrastructure. And out of that access from those sessions, we have audit logs for the security team.

David: So they can very easily go through those audit processes and check off all the boxes and prove to auditors that these things have controls around them, session recordings, so you can go back and see what's been going on in a session and how people are using the system. And then we also have a portion that is really specifically based around identity. And that includes just-in-time access requests, which we're going to look at today. Device Trust so that if you get into the system, we're not just trusting the person. We're saying you can only log in and you can only access this resource from your work laptop or whatever device you want to provide that trust to as well. So providing an identity to a device. Access monitoring, so being able to go through and query these things and see what's going on, and identity locking, saying, "We think this person's account may be compromised," or "We think this resource, this server, might have been breached." And being able to go in and just very quickly lock everything out, lock that person out, lock that machine out. And policy, being able to look at and see flow visually through how your system looks and who can access what and how that changes. And that consolidation piece, putting everything in one place, whether it's on-prem, whether it's in a cloud, whichever cloud, whether it's in Kubernetes, whether it's a database, a server, being able to get all of your resources in one place so that you can do all of this that I've been talking about for every piece of your infrastructure, for every identity you have. And so let's kind of see that real quick.

Live demo

David: So in the poll earlier, I asked, "Okay, what are the biggest difficulties you have with access requests?" Some of the answers were, "Making the requests," but most of the answers were, "Time for them to be approved," right? And while nobody answered not getting the correct resources, my hypothesis would be that time to be approved is often a function of the difficulty of figuring out what permissions you need to provide that access. So if I think about back to my time as a platform engineer, if someone needed access to a specific S3 bucket or something, right? I'd have to go in, look at all of our roles, backtrack which roles can access that bucket. Are any of these roles going to give access to more than that bucket? Can I assign this? Do I need to go make a new role? And then finally, I'm able to give someone access to those things. With Teleport, it's far easier. So the underlying structure of this access request system is the role-based access controls that we have within Teleport. And just to look at kind of the structure of one of those, we have this `ar-dev-access` role, which is going to give someone access to every dev resource that we have. So you can see we've got database roles and users and desktop groups and which AWS roles it can join as, and what they have permission to do in Kubernetes.

David: And what that looks like for the user is this, basically. At the end, this is a dev user in our desktop app, Teleport Connect, that has all of the dev resources that it has access to generally. But we also have these other access roles. We have `prod-db- access`, right? And what this looks like is just scoped down to databases that are in our `prod` environment. And that is copied for Kubernetes access, for server access, right? And so you can have these specific roles that give much more tightly scoped permissions to things. And while these roles are a little bit more broad and just provide `prod` access, you can scope that down in a much larger organization to say, "Only the ones marked with [inaudible] prod and this team," or whatever other scope of responsibility your organization has. And then we have a role here called `prod-requester`. And this basically says, "Anyone with this role can look through resources as if they had those `prod` access roles." And so we can see what that looks like for the user here. If I'm coming in every day and I'm just using the resources that I commonly access, I would have this view. But I can also say, "Show me the resources I can request." And now we see I can request access to these two production databases, to this `prod` Kubernetes cluster, to this `prod` server.

David: So those are things where in the emergency on that dark and stormy afternoon, I could get in and be there, but I have least privileged access, right? I don't have access to those things unless it gets approved. And then we also have this role called prod- reviewer. And this is just saying, "This person with this role is someone who can approve anyone who makes requests through those other ones." And so, again, you can scope this down more closely to a team, right? You could have a number of people on a team who are allowed to review each other, but no one can just go in and do it on their own. I think anyone who's ever done any kind of platform engineering has deleted `prod` at least once, and that's me, right? You're debugging in dev, and you're running these commands, and you're like, "Let me delete this pod and see if deleting it brings it back up in a healthier state." And then you forget that you went in to look at the logs in prod, and you just deleted prod. And even if I had just had the pause of, "Hey, Nick, I'm about to request access to prod. Can you give it to me?" And I didn't just have standing access to production, right? That would have been so much not only more secure, but also just better in terms of me not accidentally bringing down proud for 15 minutes, right?

David: So yeah, that's kind of the basic structure of this. But let's see what this looks like in action and how it's solving those problems that we talked about earlier. So I am going to be here as the dev, and I'm going to say, I want to request access to this prod Kubernetes cluster, and I'm just going to click on that one thing. Now, again, I'm not requesting access to an entire role. I'm just asking for access to this resource. So this really simplifies things for the security team or whoever has to go through and approve these requests because they don't have to go through and figure out what role allows this. As I do this, Teleport's actually going to create a new role that just lets me access this thing. So I'm going to go proceed to my request, and all I want is the Argo CD namespace. And we're having a bit of trouble loading that, so I'm going to leave that one. I need Sam to approve this. I want it to start immediately, but I only need access for one hour, right? I'm just trying to get in and see some logs, and I don't need to — I don't need standing access to this thing. I don't need access to this thing for three days. And we're saying the Argo pods are failing, and I need to get in and not even sending logs, and I need to get in and figure out why.

David: And I'm going to submit that request. I'll go check mine out. And now if I come back to the admin side, well, and you might have just heard my watch go off because you can hook these requests up to several different systems. You could have them go into Slack for chat ops. In this case, I've had it go to PagerDuty, and I got a page saying, "Hey, this person's requested access to production," right? And I can come in here, and directly from this notification, I can read the reason that they gave. I can click here, and it's going to take me right into this access request. Now, again, this is not a request where I now need to go figure out how to provide this access, right? I don't have to take the time to find roles, to go figure out for Kubernetes, what certificate identity I need to provide them so they can access the API cluster since Kubernetes doesn't actually have the concepts of users and groups, right? I can come in, I can read this, I can either reject it, I can approve short-term access. I can do it immediately, or I could provide another time, and I'm going to say, "Please remember to end your access as soon as you're done," and I will approve it. So we can see that took a total of two and a half minutes, and that was with me explaining all of it, and not just going in and doing it as if it was my regular routine. If I come in here now, I'll just kind of hit the refresh button. I can see that that's approved. I can assume the role. I can log in again. And now I have that access.

David: So I am going to come back into my list of things I can get to, and now we can see I've got access to that Kubernetes cluster. Now, the other really cool thing about a desktop app — this is not the only way you can do this. And just to kind of give a little bit more context, if I come in as this admin user and say I want to connect to the `prod` cluster, I can also do all this straight from my terminal. I can just run a couple of commands. It will drop the kubeconfig into my shell, and I can do it. But if I just hit Connect within here, this will actually start up a shell. Using all of my local shell environment variables, right, it's loading my zshrc, so I can do everything the way I want to do it. I have access to my aliases, so I can just do `k` instead of kubectl, but it does it with all of that work already done. And I can just hit ‘`k get pods` and see, okay, here's my Argo CD server. Grab that and do logs, that, and I can get the logs coming out of this thing. I can do the analysis I need to do, I can check what the problem is, write it down in the notes, go start planning on how I'm going to fix this. And then when I'm all done with this, even though it hasn't been an hour, maybe this took me 15, 20 minutes in real life, I can go and drop my request. And at that point, I'm back to my regular identity. That role is gone, and I no longer have access to prod from anything here. I can assume it again, but I can also just say, "Okay, I'm done. I'm going to get rid of my own ability to do this." As that user, I can't. But I can do it from within here.

What modern access means

David: There we go. And I can just come in and say, "This one," all right. They Slack me. They're done. I'm going to go delete this. And that one is now no longer valid. So we've taken all of that work that it normally takes to make these access requests and figure out what they need and how to approve them and fulfill them. And we've condensed that down to a two-minute process and made it very easy for the end user to take those permissions and go do the work that they want to do. And under the hood, all of that was being done with a cryptographic identity. When I log in to Teleport Connect or into the `tsh` command line interface, or when I log into the browser, I'm not getting a token. I'm not getting a key. Everything is based on a short-lived certificate identity that only lasts as long as I have those roles. In the terms of just generally logging in, you can see in this case, it lasts about three hours because that's when I logged in earlier to practice this, and I had to log back in. But you can set that. But the point is, like if I lose my laptop, I haven't even lost anything valuable because there's no secrets on the machine to lose. So that's kind of a quick overview of Access Requests and how we're solving this friction problem, and we'll bring it back here. So what this provides is phishing-resistant identity, right? You're locking everything down with cryptographic identities. In an ideal world, you're also making sure that people have to use MFA, either a key or a time-based token. In Teleport, we have switched entirely to some form of WebAuthN, right?

David: Whether that's Touch ID on our Macs or to hardware keys. And our CTO is very proud of saying that the red team that we have trying to penetrate us now is very frustrated because since we've switched over to that, they just can't break our identities, where they actually were able to do that for some people with TOTP. And in the end, what you've got is — not only can you not leak secrets, but you can't leak your identities either. You have all of your inventory of all of your infrastructure in one place, right? You can add AWS resources, GCP, Azure, on-prem, really anything you need to. Databases, servers, clusters, etc. Even the AWS console, you can put behind this so you don't need to worry about those roles anymore. Privileges are ephemeral. Our dev had standing access to dev, but you can say only for these things. It's also ephemeral in the sense that it only lasts as long as your default login time. So after eight hours, even that standing privilege is gone. But also, you don't need to have standing privilege. In an ideal world for me, even as sort of the god-level admin person running the entire platform, I don't want standing access to everything all the time. But if I don't have that, I need really efficient processes to get that access when I have to have it. All of the audits are in there, right? You have a comprehensive audit log for everything that goes through. All of this is going through a very high-performance proxy, and so we can check every single thing that happens. You have logs, you have session recordings, etc. And you can just get rid of so much infrastructure, right?

David: I can delete these seven VPN servers that I'm running that are beefy because they have so much network connectivity flowing through them. I can also just delete the mental overhead of maintaining those VPNs and keeping them up to date and patching all the security incidents that come up for them and making sure that the credentials to log into them are managed in the correct places and all of that, right? Any kind of bastion thing, any kind of legacy PAM tool, you just get to delete. So I'd invite you to come and try Teleport. There's going to be a link here in a second, but you can start up and really kind of start playing around with this. And one of the things I'd love is if you decide to do that, feel free to reach out to me. We have a community Slack, and I'm [email protected], which I'll put in the chat because, again, I'm a product engineer and I love hearing. And specifically, I work a lot on trying to make the initial experience and the product better and helping people get onboarded. So I'd love to know if you run into any friction. And yeah, thank you so much for watching.

Davin: All right. David, thank you for the presentation. One thing that sticks out to mind for me as someone who is a former red teamer, everything that you mentioned from the weak encryption or the hard-coded keys, the lack of oversight on which users have what privileges or not following least privileges, I should say. These are things that we all, as a pen tester, those are some of the things that I definitely look for.

David: You can just start the report by writing those down before you even go check the person's environment. Yeah.

Davin: Right. Especially when working in-house for an application security or working with the dev teams, those are typically things that you look for because a lot of the stuff are siloed. So I really like how Teleport kind of — I know no one likes to use the word single pane of glass anymore. But I really like how Teleport kind of has all of that in there where you can access all of those resources and it's fully encrypted. I really like the fact that they fix the MFA procedure as well. So good to know that you guys looks like you're working hand in hand with that pushing-left mentality with your red team. You're one of the few that's kind of doing it the right way. So that's awesome to hear.

David: There have been enough security companies that have been breached that were sort of like — if you're a security company and you get breached, you don't have a leg to stand on. So yeah, that is really important to us.

Q&A session

Davin: Yeah. You never want to be the hacker who gets hacked, right [laughter]? So you mentioned Teleport can replace VPNs. Can you explain how or why we would want to do that? Because, I mean, a lot of people look at VPNs and think, "Well, it's encrypted. It's an encrypted tunnel. It works for me." So why would you want to replace VPNs?

David: Yeah, totally. So at the end of the day, VPNs — you can go through layers of security, right? But at the end of the day, a VPN is not part of a zero-trust system, right? I think one of the things we run into a lot when people are coming to us and asking about the product and how things work is sometimes like we almost kind of say it's like legacy thinking, right? You're still trying to think in terms of the network boundary. And it's not unwise to still have private networks, right? But I think another thing to say that I didn't mention in the presentation is that — one of the ways that Teleport works is that every resource that you add is actually reaching back out to Teleport through a reverse proxy, right? So you can completely close off all public network access to that thing because it all flows back through the proxy. And so you can close off port 22, you can close off port 5432, whatever it is, and still have access to that thing. And that becomes zero trust, right? If you have no network access to a thing other than through a reverse proxy where it's reaching out, and any connection into that thing through the proxy is happening completely via certificate-based identities, then that becomes zero trust, right?

David: "I'm not going to trust this thing at all. I'm not going to allow anything in unless it's from an identity I trust." And VPNs, like I kind of alluded to during the presentation, they are a trusted thing, right? But they're a trusted thing that's just basically an IP address. And if someone can find a way into your network and spoof an IP address, then game over, right? Now you have lateral movement. And so yeah, I mean, I think there's a place for — I don't think any one solution is always the one-shot solution for literally everything, right? And then there are still times and places to run a VPN. But especially when you're talking about at scale, how many networks do you have? How many teams have to access those various networks at various times? And once you get beyond, "I've got my dev network, my stage network, and my prod network," they also just kind of become a nightmare to manage and trying to have network policies and firewalls between all of them. And it's just this whole category of thing you can just toss, right, once you've got that more direct connectivity that is identity protected.

Davin: Okay. Makes sense. All right. Let me look here. It looks like we have a couple more questions. And folks, if you have any questions, please go ahead and put them in the Q&A section so we can see them and get them over to Dave. So I noticed and well, I'm going to get into the question, but I saw that there's a lot of different modules and things that Teleport works with. So does Teleport work with AWS tools like their Identity Center and stuff like that?

David: Yeah. So we work with — we kind of work both ways, right? You can use Identity Center as so I should say provide a bit of context, right? You can use your SSO to create identities and login to Teleport. And Identity Center is one of the ways you can do that. But you can also use Okta or anything else, right? But we've seen a lot of people now moving into AWS Identity Center away from other IDPs, and especially after some recent breaches. And one of the big advantages of that, right, is that if you're — okay, so the example I showed, we had 20 users we've created in that Teleport cluster, but you have 1,000 engineers. And what you really want is just to be able to bring in your org structure in some way, right, where you import all those identities and they already come in, in the groups that you've already assigned. Most organizations have already done that work. And so that's one way that you can bring all those users in — is through Identity Center, through a native integration we have with them. And then all you have to do is assign roles within Teleport for what they can access. And then the other way it goes is that, like I was saying earlier, you can put the AWS Console behind Teleport where you can provide roles, restrict those to Teleport roles, and they can only get to the console through Teleport via approved methods.

Davin: Nice. Okay. Looks like we have one more question. Again, we do have time for more. So if you have any questions, please put them in the Q&A section. Let's say we have an SSO tool that already requires MFA. What would be the added benefit to using Teleport with that solution?

David: Yeah, that's a good question. So I think it's just about depth at that point, right? And I would say that this more applies to the point that you have — like that you're using TOTP or goodness forbid SMS as your MFA, right, now that we know how compromised the SMS infrastructure is. But I think one of the things is like once you get in with your SSO provider, you are authorized for a certain amount of time as that identity, right? And one of the things that we added this year to Teleport really following one of the major IDP breaches was the ability to do things like per-session MFA, right? So even if someone is able to compromise your account in your IDP, if you get into Teleport at that point, A, we make it mandatory that you use MFA for admin actions, like creating new roles, deleting roles, editing them, adding new resources. So anybody coming in, they have to recreate your MFA access in order to do anything that would allow them privilege escalation, right? And then the second piece of it is — we can also enforce per-session MFA. So every time you want to access that server, you have to tap your key again, or you have to put your fingerprint on again. And so it locks it down even further to more granular actions than just, "I am this person. I'm in." Right? And yeah. And that's one of the ways we hope to kind of address that issue.

Davin: Yeah. The hacker in me doesn't like it, but the security professional definitely likes the idea of the per-session MFA because if you can crack — like you said, if you can crack MFA, especially with SMS these days, that's the keys to the castle right there. It's game over, right? You already have the credentials, now you have the MFA. [crosstalk].

David: Yeah. And it's like in the presentation I was mentioning, there's always that tension between security and productivity, right? And our overarching goal and ethos is to find the middle of that tension, right? And like you're saying, I mean, as you're saying, as the hacker, you don't like it. I also think as a dev, I don't like it, unless it's easy, right? Unless it's as simple as tap my key, tap my touch ID, Windows Hello, whatever, right? And I can just and it's not, "Hold on, let me open up one password and grab this code out," right? Yeah, just trying to make it as frictionless as possible.

Davin: Yep. So we have one question. Someone said, "I am a new joinee in trying to understand the joining process and the steps or if there's any documentation or any URL for it so they can understand the step-by-step process of connecting to Teleport." And then we have a couple more questions after that. So I guess you could start with that one, and then I'll ask the other questions.

David: Yeah, totally. So if you want to get started, you can go to goteleport.com/docs. One of my favorite things, as a developer person, about our website is if you also go to goteleport.com, there is an engineer tab right at the top. So you can just be like, "Oh, cool. I can just go right to the part that I care about." And then it'll get you right in and get you new steps. There's a two-week trial you can do to get just a trial on our cloud product, but we also have self-hosted and all that air-gapped if you need it. And that's where you really want to just reach out to our team. But you can just get started and get going. And I know our docs are pretty good on getting people in through the first part. And like I said before, if you do that and run into problems, let me know what those problems were.

Davin: Yep. And again, it was goteleport.com/docs.

David: Yeah, /docs.

Davin: So the next question was, well — what VPN does Teleport use?

David: Yeah. So there's maybe two ways to interpret that question. And Richard, you can put in the chat or something. I'll just do both, right? One of those is like, "Does Teleport the company use a VPN?" No, we use Teleport. And then the other way that could be interpreted is Teleport built on a VPN? And the answer is also no, right? So the architecture here is you have an agent, and this is going to get to Richard's next question as well about what gets installed in the customer's resource you're accessing. So on any given resource, you install a Teleport agent, right? And that can provide SSH access. It could be in a Kubernetes cluster and interact with the Kubernetes API. You can run a service in your Amazon account that is able to — that has permissions to discover everything and govern access that way. But you install a proxy agent somewhere that has connectivity to the resource, and then that proxy does a reverse tunnel out to the rest of the Teleport proxy network. And so we wrote it. You can go see it. And the part of the product is open source, github.com/gravitational/teleport. And you can kind of see how it's built. But that proxy then is what governs all the communication. So we are not based on VPN technology. Again, because VPNs are based on passwords, are based on tokens, and we are completely 100% based on time-limited X.509 certificates.

Davin: Yep. Okay. And then it looks like Richard had a couple of other questions. I'm not sure if you're able to answer this one, but he asked, "What MSPs are currently using Teleport to provide services?"

David: Managed service providers. I don't know. Yeah. I don't know that I have that list to hand at the top of my head, but I'm sure that one of my wonderful backup producer-type people is sitting backstage right now, Lexi, and I'm sure that we can reach out to you soon with that information. I just don't have it in my head at the moment.

Davin: And then the last question was — is Teleport just an approval system for identity?

David: Yeah. I mean, I think that is a major component of it. I'd say that there are a lot of other features here that I didn't really show off today because we've only got so much time. The other ones that I could list off are there's the audit logging and just general record of everything that has happened that's really valuable for security teams. The identity locking where you can just come in and say, "Actually, this identity needs whether it's a machine or a human — like you're no longer allowed in the system for the next four hours while we figure out what's going on." There are really advanced ways of managing and governing access through the roles, but also, as I mentioned, through your IDP, you can bring in all those groups and then use those groups to do things. One of my favorite features that I wasn't able to show today is based off all those logs and stuff. We have a number of customers who at the annual audit just sit down with Teleport [inaudible]. And when the auditor is like, "And how many people logged in with Root this year?" You can literally just pull it up and say, "Show me all the sessions where it was Root and we didn't require MFA and we didn't require Device Trust and all the other components around this," and it'll come up empty and cool, box checked. Right? So there's a lot of powerful stuff around there. And yeah, I mean, I don't know. I could do a webinar on all the features. So I think go check out the website. We've got really good overviews of everything. Start up a trial if you want to kind of get in and click around and see it, and. Yeah.

Davin: And I expect having those tools like that will make the in-house security a lot more streamlined and efficient as well. Because if you're able to see that, at that point, you can kind of say, "Hey, we need to cut — let's nip this in the bud here or let's figure out what we need to do to fix it," so.

David: Yeah. One of my favorite just like direct examples of that, right, is every startup, every company starts with the CTO creating every account, right? And then the CTO ends up with admin or god privileges on everything that starts up. And one of the things we did with our policy products was the thing that kind of gives you a graph of who can access what, right, and kind of calls out like, "Here's the number of permissions." As we turned it on, and our CTO had 1,000 permissions. The next person down had 30, right? It's like we had done this really good job of putting in all these access and policy controls except, "Oh, right, the person who created all the accounts." And so that was something we were able to instantly just be like, "Cool. Let's go turn all this — let's go turn all that off." Right? And so that has been rectified. And if Sasha's identity were compromised now, we're not totally messed up.

Davin: Awesome. Awesome. Because I said, I mean, [inaudible] phishing is still a thing, so that would definitely be —

David: 100%.

Davin: All right. So it looks like we have any other questions from the chat? We have a couple more minutes if anybody has any questions they want to ask, Dave, before we head off. What APIs are published so that Teleport can be integrated into another product?

David: Into another product. So I think the most common use case we see with this is people want programmatic ways to add resources or to — yeah, I mean, so another one would be sending off our logs because, again, we are just one source of logs, and most places have more than one source of logs, right? So you can ship all of our logs off to your SIEM via Fluentd, or we have direct integrations with a couple of others. And then, yeah, I mean, we do provide some APIs for programmatic management of access requests for the things that we don't have pre-built integrations for, that kind of thing. I'd say go to goteleport.com/docs and we have docs on the APIs that exist so you can see kind of how that might fit into your system. Or if there are — without knowing the products you want to integrate with, it's harder for me to kind of get into detail there. But again, reach out or join the Slack or yeah. But yeah, I think the docs are a really good place to start there. I'm trying to think of any other good way to answer that. Yeah. And then, I mean, I think another thing there is just people request integrations all the time. And as we see lots of people requesting them, we always just build direct integrations where we can with other things. GitHub, GitLab, Datadog, PagerDuty, as you saw earlier, which is like a two-way. I didn't think I went back and did this, but when I approved that request and Teleport, PagerDuty resolved the incident automatically. And yeah, we have a lot of two-way integrations like that.

Davin: Awesome. All right. So we have time for one last question. So if anyone has any questions they want to ask before we wrap up. Going once. Going twice. And all right. All right, Dave. So thank you for the presentation again. Teleport looks awesome. But where can people go to learn more about Teleport and the work you guys are doing over there?

David: Yeah. Well, I mean, again, I'll call out there's the resources that are in this webinar. Definitely grab those and download them. And again, we have a community Slack you can get to through goteleport.com. I think there's a community tab that you can click on and get an invite to the Slack. Or otherwise, if you're trying to get a broad overview of the product, definitely just goteleport.com is a great place to start. And beyond that, going to the /docs page is the next best place to really dive into the details, especially if you're looking for API integration and getting more in the weeds like that. And then, like I said, just going to /signup that's here on the slide. We'll get you in direct contact with us, and you can tell us what you need.

Davin: All right. That's great. So thanks for that. Everybody watching, I hope you found the session valuable and informative. If you do have any questions that you didn't get a chance to ask today and you would like more information, please don't hesitate to reach out to David and the team at Teleport. Once again, my name is Davin Jackson. I want to thank you for joining Teleport in DZone today. And I hope you have a great day, and I hope you have a great rest of your week. Take care.

David: And thank you, Davin. Thanks for moderating.

Davin: No problem. Take care [music].