Teleport 16: Advancing Infrastructure Defense-in-Depth with Device Trust, MFA, and VNet

Teleport 16: Advancing Infrastructure Defense-in-Depth with Device Trust, MFA, and VNet

In this webinar, we will explore how Teleport 16 enhances security and simplifies secure infrastructure access through:

• Teleport Access:
  • Teleport VNet: A new feature providing a virtual IP subnet and DNS server to seamlessly proxy connections to TCP applications, eliminating the need for manual re-configuration.
• Teleport Identity:
  • Device Trust for the Web UI: Extending device trust enforcement to browser-based workflows for both desktop and web application access.
  • Per-Session Phishing-Resistant MFA for Applications: Adding support for per-session multi-factor authentication when accessing web and TCP applications.
  • Updated UI and Streamlined Access Requests: Improvements to the user interface, including a new notifications system and the ability to request resource access directly from the main view.
• Teleport Policy:
  • Access Graph Support for AWS, Okta and Teleport Resources.

Whether you're an existing Teleport user or exploring infrastructure access solutions for your organization, this webinar will provide valuable insights into leveraging Teleport 16 to strengthen your security posture. Join us to learn how these new features can help you secure access to your critical infrastructure, applications and resources.

Key topics on Teleport 16: Advancing Infrastructure Defense in Depth with Device Trust, MFA, and VNet

• The webinar started with an overview of the 2022 LAPSUS$ hack, a case which underscored the vulnerability of support tools and the critical nature of monitoring third-party SaaS tools and Identity Providers (IdPs).
• Within the Defense in Depth strategy, Teleport’s features map to security principles, particularly in scenarios where an IdP is compromised.
• The three core Teleport products are Teleport Access, Teleport Identity, and Teleport Policy.
• Live demos were presented on Teleport 16 features including per-session MFA, Device Trust, access control mappings, access management security, and access monitoring — all highlighting how Teleport’s features integrate to provide robust security for accessing infrastructure.
• Per-session MFA is an optional check that requires users to present an MFA token when starting a new session to access web and TCP applications.
• Teleport Device Trust allows Teleport admins to enforce the use of trusted devices. It can now be enforced for browser-based workflows for both Teleport Desktop Access and web application access. The Teleport Connect client must be installed in order to satisfy device locality checks.
• Teleport VNet enables teams to eliminate VPNs, while maintaining a VPN-like experience for TCP-based applications.
• The session covered best practices for user and access management, recommending just-in-time access requests, dual authorization for admin actions, and avoiding reliance solely on SSO identities for critical roles. These practices help ensure that even if an IdP is compromised, additional layers of security are in place to protect the infrastructure.
• Breaking changes in Teleport 16 include the Community Edition license update, MFA being required for all local users, and other changes.

Expanding your knowledge on Teleport 16: Advancing Infrastructure Defense in Depth with Device Trust, MFA, and VNet

• Teleport 16
• Teleport Access
• Teleport Identity
• Teleport Policy
• Teleport Device Trust
• Teleport Machine ID
• Teleport Passwordless
• Teleport Server Access
• Teleport Application Access
• Teleport Database Access
• SAML Identity Provider Access
• Teleport Workload Identity

Transcript - Teleport 16: Advancing Infrastructure Defense in Depth with Device Trust, MFA, and VNet

Introduction

Ben: Okay. So let's begin. So today we're going to be covering Teleport 16 and Teleport in general. The main theme is Advancing Infrastructure Defense in Depth with Device Trust, MFA, and VNet, which are a few core features of Teleport 16. And I'll go a deep dive into what Defense in Depth means and then also just go through an overview of all the features we've had in Teleport 16. I've been at Teleport for about five years now, since 4.0, and each release always gets bigger and bigger. So I may not cover everything in this webinar, but I will hope to cover a lot of the key features that we have in Teleport 16.

Overview of the 2022 LAPSUS$ hack

Ben: But I wanted to open with a short story about a 2022 hack that everyone might be familiar with. And unlike Mr. Robot, this is the home of the hackers. And would anyone like to guess in the chat which location this is? My accent is place of the country. Let's see if anyone's going to guess. But this is sunny old Oxford in the UK. And this was home to a ringleader of a teenage hacker group which managed to get access to a range of different systems, just generally causing chaos on the internet. And along their chaos on the internet, they came along a support dashboard and they were able to use a support dashboard to claim that they got access to Okta internal systems. And because they got access to these internal systems, they got access to the applications and services that Okta provided access to. LAPSUS$ was its name. This was quite well covered in 2022 and last year about how it worked and how this breach sort of rolled out.

Ben: And I think one thing that's particularly interesting about this breach was sort of how this hack worked. Initially, it was sort of downplayed as a support portal that was hacked. What happened was most customers would have a support issue. Okta's support team were like, "Hey, can you upload a HAR file?" which is sort of a debug file just to see what's happening during that instance. And then they would use this to debug it and figure what's happening. Relatively innocent in the scheme of things, common practice for getting logs and understanding what's happening. But this group of teenage hackers got access to support portal and as they were digging around, they found interesting and creative ways to use this HAR file. And they used this HAR file to get a session token for a service account, and they were able to use the session token to access five customer accounts through a privileged escalation. This is sort of a very high-level overview of how this hack went down. There's lots of other great overviews. Okta has an overview and there's a few other security researchers that have gone into details about how this went. But I think one thing to take away from this is ways in which identity provider can be an access way and then the hacker can sort of pivot and get access to systems.

Ben: And I think these are some things you can learn from the hack. This is sort of my opinion. Support tools can be easy targets for hackers. Often, they could be outsourced. They can be a lot of sensitive information, whether it's like env variables. Some people might even send their password into a support portal. Some people might upload HAR files, which you may not know have sensitive data. It's also important to monitor and alert on third-party SaaS tools. One interesting, nuanced thing with this hack was it was initially disclosed by 1Password and Cloudflare, had seen some interesting changes in their configuration. And so it's always important to take those logs from third-party SaaS tools and alert and monitor on them. An IdP is a very tempting gateway into an organization. This is a bunch of teenagers from Oxford. And we've seen other patterns that people know that it's a potentially easy way to get into an organization, find a low-level account, get a more privileged account. And then lastly, I think now we can sort of assume always good to tabletop. If an IdP has been breached, how can you protect from this happening? And this isn't a particular ding on whether it's a SaaS provider for your IdP such as Okta or your self-hosting Entra. You can assume it could even be like an insider threat. What are options that you can do to assume if you're an IdP or user has been breached, how can you protect? And we're going to cover some of this today.

Webinar agenda

Ben: So today, our webinar is going to go in sort of four key parts. So I'll do a little quick introduction on Teleport for people who are new. I'll go over Teleport 16 covering Defense in Depth, platform updates, and then our three core products in our platform, which is Access, Identity, and Policy. Lastly, for existing customers, I'll cover breaking changes, and then I'll have a Q&A. And my name's Ben Arent. I'm Director of Product here at Teleport. Like I said, I've been here five years, so I've seen the product evolve over time. So I'd love to take any people's questions, whether you're brand new to Teleport or whether you're just getting started. So I'm going to kick things off with a quick poll and I am going to share this now. And this is just going to say, "Are you currently a Teleport user?" And you should see it come up in one of your tabs. Okay. It's open now. So people should be able to fill it in. Let's give a minute to everybody to complete it.

[silence]

Teleport: Quick introduction

Ben: All right. You got five votes. We go again up there. Let me just give you a little 30 more seconds to find the poll. Okay. So it looks like we have a mixture: a lot of people hosting on-premise, customers, one Teleport Cloud user, and then also equal amount of people here to learn more about Teleport. So hopefully in this webinar, we'll cover all of the items that we need today. So let me come back to my share. A little dance here, but we're back in it. Okay. So what do we do? So Teleport provides on-demand least privileged access to infrastructure on a foundation of identity security, zero trust with built-in identity and policy governance. And so what does this all mean? This all means sort of a consolidated access platform that combines sort of three core products: Teleport Access, Teleport Identity, and Teleport Policy, or providing a zero trust way to get access to your infrastructure and resources. So this could be your applications, your databases, your Kubernetes clusters. And we started in the world of just a more advanced bastion. And as the products evolved over time, we rolled out to two new products, which is Teleport Identity and Teleport Policy. Identity really helps around identity locking, access monitoring, access requests. Teleport Policy is all-around visibility into the access graph and enforcing policy. And Teleport Access is our sort of foundational level of a zero trust identity-aware proxy using reverse tunnels and leveraging cryptographic identities.

Ben: And as I kind of go through the demos, I'll sort of show what this really means. And I like to share this systems diagram. We have all of our users here, and we have all of our resources. This is sort of the combination of how all of our products work together, that we have end users, whether it's engineers, services, or end users connecting to the Teleport platform to get a range of access policies. Everything has session recordings, we have audit logs, and you can add on identity for such things as implementing zero standing privilege or the principle of least trust. So this can include just-in-time access requests or identity locking. And then our most recent addition has been Policy. This really helps you understand the whole chaos of all of your resources and teams and RBAC, and it can give you a visual understanding about who has access to what, and then you can sort of help fine-tune your infrastructure.

Teleport 16: Infrastructure Defense in Depth

Ben: So covering Teleport 16 infrastructure defense in depth. For Teleport Infrastructure Defense in Depth, this is around hardening infrastructure security, using Teleport to keep your critical systems and data protected in the case of identity provider compromise. So going back to our initial example that we started with, we assume that an IdP has been compromised. What can Teleport do to help protect you in the case of this happening? And we've published two sort of assets recently. One is we have this white paper, which is free and available to download. This goes through defending against an IdP compromise, and I'm going to cover a few of these topics. And we partnered with a security researcher, Doyensec, to go over how you can harden your infrastructure against SSO provider identity compromises. And this is also available on demand on YouTube. And this is a great sort of high-level intro into this. I hope to go a little bit more detailed into some practical tips and sort of demos of how Teleport can help you.

Ben: So starting here, so the evaluation strategy, thinking about what the IdP vector tree looks like. We start off with the most basic non-privileged account gets compromised. This could just be a, say, someone in accounting. They may have very sensitive data, but it could be application data, but they can't do much more. And as we sort of go down the chain, we have privileged accounts such as a admin. If these get compromised, it can get worse, so they have the ability to impersonate non-privileged users or spy on user activity. And lastly, if you have a full compromised identity provider, you can do such things as create new admins or you can impersonate other users. And so this can become a lot more chaotic. And this is sort of what we saw in the case of our Okta example earlier on. And so our security principles and features is mapping how Teleport features map to some of these security principles, starting off with ephemeral admins. This is following the principle of zero-standing privilege. Instead of having admins which always have admin access, you use access requests or dual authorization to get access to the resources that you need. So as an admin, I don't always have it. So even if my account gets compromised, someone can't use that to get something else. And dual authorization is a feature that we have in Teleport that means one or many people need to request access to that resource to obtain these permissions.

Ben: MFA for required actions. This means using a strong phishing-proof second factor. I recommend YubiKeys or Touch ID to further protect it. So even if someone's session cookie is stolen, use MFA token to do the next check. And in the case of Teleport, this could look like MFA for starting a session, MFA for admin actions, and then to go an extra layer, you can add Device Trust. So you're only trusting the TPM or devices enrolled. And then in Teleport, we have the setting, which is WebAuthn. And then lastly, we have access control mappings and IPE block binding. This is ensuring that user attributes are securely mapped to the identity provider to make sure you don't have any wildcards, or it's sort of statically typed so people can't sort of hack what groups you have. And IP pinning is another sort of key part of this, making sure that the IP that you have doesn't change. You don't suddenly go from a California IP address to one in North Korea. And there's a few other things that you can do, such as sort of fine-tuning roles and access lists.

Ben: So MFA required for protected actions. We covered this using per-session MFA, using a sort of strong hardware token, using access requests and dual authorization for privileged roles. I'm going to do a demo of this. And making sure everyone is enrolled in MFA. What's kind of nice about using Teleport with an identity provider is you can also sort of roll hardware tokens out to your engineering team, say, and have them really protected if they have more privileged accounts and not necessarily a whole organization, which if you have 2,000, 3,000 people in an organization, it can become logistically quite difficult to roll out hardware tokens at scale.

Demo: Per-session MFA

Ben: So I'm going to give a demo now of per-session MFA, and I'm going to log in here. And so this is the Teleport Access platform. You see I just logged in using my identity provider. In this case, I'm using GitHub. I have an inventory of all of my resources here that I can get access to. If I log into my Ansible host, you can see I've now accessed it. We have the same flow on the command line, and I see what's kind of interesting here is this one is a demo — oh, hold on. Is there a demo? There is a demo. Yeah. I came back in here. Okay. So let me rewind a little bit. I might as well log out and back in to show you. So this is sort of the gateway into Teleport. I'm logging in with GitHub, which is my IdP provider. You see I have a few hosts here. I'm going to access and log in using the Ubuntu Linux user. And I have access. This is our web-based terminal. We also have command line tools to provide access. But since this one is just a standard service, I have a user prod. So let me find a prod host, the Slack bot. And I'm going to share this tab instead. So now since this has the label prod, I've said any prod resource, I need to require multi-factor authentication. So this one says I need to connect. I have a prompt now to tap my YubiKey and now I have access to this host. And so that's sort of a demo of per-session MFA.

Demo: Device Trust

Ben: I'm just going to finetune my demo next to make sure I share more of my screen, and I'll do that for this Device Trust one. So I'm going to come back and share my whole screen. Okay. So okay. Hopefully, everyone can see this. I have your little chat window here. You can see how everything's working. Okay. It looks like we are rocking. Let me just rearrange things here and close my notes. So I'm going to log out as my Teleport user and log in as my sort of super admin. And since Teleport admin is sort of my core admin user, I've made it have Device Trust. And log in. You see, it's going to prompt me to add my hardware token. Let me just find my correct security key. I always have Touch ID, but I have my laptop closed. You see here we have now prompted our Teleport Connect.

Ben: Teleport Connect is a launched web session. We do this because this is how our Device Trust works. It has to ensure that we have sort of low level access to the TPM on our host. So we now have access and we're in. So you can see that this session is now authorized with Device Trust. And I can come into one of my servers here and access it. If I come back into Teleport, you can see now in my Audit Log, I have the Session Started event. In the Session Started event also has only my trusted device. This is the asset tag for my device that I have access to. And Teleport supports a range of trusted devices. We support Windows, macOS and Linux. Here we just have mostly Mac, but I have my Windows workstation as well, and it does the same process that you need Teleport Connect, which is sort of our desktop client, which I'll be using for another demo next.

Demo: Access control mappings

Ben: So access control mapping. This is the next stage we're sort of talking about, configuring the IdP to restrict role mapping, using non-editable unique username, using a group field editable only restricted to the IdP for role mapping, avoiding lax string matching. I kind of will. I can show you what this looks like. So if I create a new Auth Connector, you can see that we have this mapping. So this is sort of a strongly typed, but we also support wildcards and the like. So we would recommend using your attributes to groups to kind of keep them very tightly scoped. And yeah, here's my example of the role mapping. Let's come back. Oh. Yeah. So you can see we have Okta, we have the groups, so we're mapping basically anyone who's in an Okta group to be the `editor` user, the `editor` role in Teleport, and the access role for `okta-dev`. And so Teleport's RBAC is very powerful and flexible. I can show the MFA role that I had. So my one user had my per- session MFA and we've said, "Hey, for this user, we do a range of things." Device Trust is required. And "Require session MFA" is on. So there's a range of options. You can see things like, "Turn off SSH copy, disable clipboard for Windows hosts." The list kind of goes on. And then for my user, you can see we had required us the device, which also had that in.

Demo: Access management security

Ben: So Access Management security. Next up, we recommend setting up just-in-time access requests according to the principal of least privilege, using dual authorization for admin actions, ensure that reviewers are only local users, not SSO users. This is the case that solves the problem of someone gets access and compromises your IdP. They can easily then approve other actions in the IdP. By having Teleport in place, you have another check to make sure, hey, multiple people review this, which is a local user. You can enforce Device Trust and required MFA, which you may not have rolled out into your IdP because often it could be sort of a global permissions. And so you can really lock down Teleport and your IdP and sort of work together to really lock things down.

Ben: Another option is we have access lists to only local users avoiding SSO identities, which is a feature that you can use to provide longer-term access. And I'm going to show this demo now. I'm just going to see if anyone has any questions in the chat. Nope. I will be checking this intermittently, so feel free to ping anything in there. So now I'm going to open a new incognito window. Bob is my user. I have my check. And so what's interesting with Bob is you see everything is sort of disabled. And this means that Bob has access to view all these resources, but he has to request access. So we're going to build an inventory of hosts, a mixture of Kubernetes clusters, going to add a Windows server. And so I've added all these resources. You can pick a reviewer similar to the GitHub workflow. I'm going to say today — I'm going to just need access for one hour. I need to “Debug the prod env”. We have a few other options here, but we're just going to submit this request. And so you see I now have my request pending for all of these hosts and the request expires in three hours.

Ben: So coming in, now you can pretend that I am the administrator. You can see that Bob's request has come in. "Hey, debug the prod environment." If I come back to my Teleport admin user — actually, I need to log out my Teleport admin. My SSA user is my approval. You can see Bob's request. I can say — I can review his request. I can approve for short-term access and start immediately. Submit the review. Also, you can see here requiring a hardware token, so protecting my GitHub user. If you come back, you can see it has been approved. And now for Bob, he comes in here. He can see his access requests have been approved. He can assume the role. Now he's assumed the role. He can get access to the resources so he can log into his hosts and sort of go about his sort of day-to-day. So I previously worked in much larger organizations that sometimes the [inaudible] flow could take sort of weeks to get access to different systems. And I'm going to say this is a much smoother experience both for server access. It also works for sort of applications that you support. Basically, anything that's protected by Teleport, you can use Teleport Access Requests.

Effective identity threat response with Teleport

Ben: I can come back to my demo. Then lastly, we want to make sure that we have sort of threat response with Teleport. This is making sure that we are using Teleport Identity to see which events are coming. Probably send them to a SIEM to alert on them. Considering such things as like Moderated Sessions, this means that you need to require multiple people to join a session. So if I come into Teleport, you might see that we have active sessions. What you can also do is — I don't have permissions, but you have the options to join as a moderator or a peer or an observer. And so if there's a really highly sensitive system, you could say, "Hey, I need three moderators on this prod box," and they can also terminate the session as well, which is very handy for some compliance frameworks.

Demo: Access monitoring

Ben: And then, yeah, detection and instant response strategies. We actually have a great blog post that has just gone over this. Also worked with Doyensec, and this is using our Access Monitoring feature. Access monitoring is part of Teleport Identity and this lets you — there's a few built-in reports, and we have our query editor. Come back and it gives you a report about — let this run for a little minute. And it shouldn't have picked 90 days. Okay. Here we are. And so it's a built-in report that gives you an overview of SSH sessions with weak security. So these are ones which don't have access requests or Device Trust. People using long-lived secrets. Kubernetes calls. If you're using a weak group such as `system:masters`. And all of this — this is just our built-in report. Under the hood, it's Athena database, so you can sort of customize this looking for specific controls. If you look in our Doyensec blog post that I just had on the last slide, that will go over specific ones that you can target, mainly for sort of IdPs, and you can alert on.

Teleport 16 - platform updates

License update

Ben: So Teleport 16 updates. I can take a little break here, see if anyone had any questions. No questions. So everyone's still with me. All right. Let's go to Teleport 16. So there's a lot in here. I won't go through this, but I'm going to go over core platform updates, Teleport Identity, Teleport Access, Teleport Policy, and the Teleport overall platform updates. One thing that I won't cover is — one addition we've added is a multi-region deployment blueprint using CockroachDB. For our customers who are self-hosted and you're looking for a very high availability option, I'll definitely recommend checking this out. I don't have any content in this presentation, but check out the blog post. We link to that template that's available on GitHub. The rest of these I'm going to go over in the rest of this presentation. So one big update we changed with Teleport 16 is that we've changed our licensing, starting with Teleport 16. Teleport Community Edition is sort of free and available to use for personal hobby use with no restrictions. But if your company has less than 100 employees or less than 10 million, you can use Teleport. If you have more, you're sort of in breach for our license and you need to reach out to us. There's a few other details about the specifics — license that's changed. We've gone over this a few times. I definitely recommend checking out our blog post that covers this. We will also stop distributing compiling AMIs under the Apache 2 and switch to the Teleport Community Edition license. And what does this look like for the end users? When you do upgrade to Teleport 16 and you are using Community — I use this in my home lab, for example — you just have one message that you need to approve. It's pretty easy. And then otherwise you'll see in the UI we just highlight whether you're on Community Edition or whether you're using Teleport Enterprise.

Teleport VNet

Ben: So next up, we have Teleport VNet. So VNet is a really interesting feature that we've added, and this really extends a VPN-like experience for Application Access. And so it creates a virtual IP subnet with DNS for Teleport apps. And so what we notice when we talk to our customers is they still had lots of applications, which is still in a VPN and they want to get rid of their VPN, but there's certain things that they need like a VPN-like experience in a sort of a zero trust way. And this really helps people migrate with a very seamless regular DNS experience. And I'm going to sort of show you some examples of what this looks like. And so some key features, automatic TCP connection proxying, improved user experience for sort of non-browser clients and scripts. We have custom DNS support. We have a few technical details here using TUN Interface and gVisor networking stack. Our RFD is always a great resource. Teleport is an open-source, open-core company. You can sort of understand how everything is made by going to our RFD repo. And it's built on all of our principles. So using Teleport Connect, using our RBAC system — everything sort of integrates quite tightly and nicely as well.

Ben: So for this one, I'm going to share this video. Let me share again because I want to make sure that — I need to share a tab. I think this should share audio. Teleport VNet [inaudible] implements Defense in Depth by moving any application into a private network with the additional protection of role-based access control without having to reconfigure anything. As an example, my company, Asteroid Earth, is running a self-managed GitLab instance. Right now, the instance is available in the public web at `gitlab.asteroid.earth`. I've been tasked with moving it into a private network for a few reasons. First, even though the instance is self-managed and private, we have some repos and organizations misconfigured as public, so non-authenticated users can still view some of our data. Additionally, we use Okta to authenticate, but with the recent compromises of identity provider vendors, we need to implement a Defense in Depth strategy, or even if our IdP is compromised, our applications are protected via network access. I could use a VPN, but in the past, I've had a hard time getting those configured for the non-technical teams and getting them to remember which VPN to connect to for which environment, etc. And a VPN would let anyone on it access any of the apps available on the network. There are several other internal apps that non-technical folks shouldn't be able to access. I want role-based access control to make sure that even on the internal network, only approved people can reach this instance. I want to make it easy for both the engineering and other teams to keep accessing it the ways they always have, whether in a browser or via the command line. And I want to do all of this without requiring changes in Okta or in the GitLab instance itself to avoid a complex migration.

Ben: Teleport VNet checks all my boxes. Let's see how it works. To add the GitLab instance to Teleport, I add a simple section to the Teleport agent running on the server. I tell it to forward traffic to the local host on port 443 to maintain HTTPS and provide the instances URL. Then I add a VNet configuration to my Teleport cluster, letting it know that for any requests on the domain `asteroid.earth`, it should look through available VNet applications. Now I'm going to delete the DNS record for `gitlab.asteroid.earth` and remove the firewall rules allowing web traffic to reach it, completely removing it from the public web. I can no longer reach it via a browser, and the ability to query the API while unauthenticated is gone. Now, as a user, all I have to do is open Teleport Connect. A VNet connection is activated automatically. I can open a browser, go to Okta, and access the GitLab instance as if nothing changed. I can open a terminal and access the API or use Git commands seamlessly. Encrypted traffic is still supported using my original certificate. When I quit Teleport Connect, my connection is gone. Best of all, there is role-based access control governing all of this. A user who does not have a role granting them access to this application won't be able to reach it. Teleport VNet allows you to take any application private governed by role-based access control with no changes to the application or how your teams use it. Try it today at goteleport.com/signup.

Teleport Connect

Ben: All right. Thank you, Dave. He's one of my teammates who made this. It was a great video. And I'm going to try a live demo as well because it's Thursday. What else are you going to do? Do some live demos. So let me come back to my slide. Okay. So let's do the demo. So I'm going to introduce Teleport Connect again. Teleport Connect is a multi-operating system desktop client for Teleport. We find that people really like this experience. You have a dedicated desktop application. I'm logged into my cluster. It's now required for Device Trust, but there's a few other features that you get, such as if you quickly want to launch access to different apps. I'm going to be focusing on minio. And you can see here, minio has two parts. We have a TCP app on the minio-api, and we have minio SSH server, and we have the UI. So if I launch the UI, this is the minio UI object store. But I'm not interested in just the UI. I'm interested in the API. And so what I'm going to do here is — we have VNet is on — I'm going to connect and so say, "Connected via VNet using this IP address." So now if I come to my terminal. If I `curl` this endpoint, you see our access denied. And so we have some request hitting this endpoint. It probably won't match here in the browser, but I'm able to connect using just `curl`. And I have a small Go program here.

Ben: For people who aren't familiar, minio is sort of an S3-compatible file store. What's kind of interesting here is I am leaking my access key and my secret. Generally, very bad practice. But in this case, the only way to get access is using Teleport VNet. So no one else on the internet can actually access this DNS record. It's only available to me who's been authenticated and accessed through Teleport. Still, I should have this in some other secret management, but it's not the worst thing I'm doing. So I'm going to run this code and you can see I have one VNet bucket. All this is doing is it's just using my API keys, using my endpoint, and then we have access. So if I come back into Teleport itself, in my audit log, you can see that I have connected to the API and I made the request under the hood. This is sort of the app URL. This is kind of what we were mentioning around, mentioning like DNS records. It has dealt with all of the proxying on behalf without having to worry about it. And this could be helpful because you can add sort of multiple applications to get a very seamless experience to connect to them. Another addition is we have Device Trust and everything else added into this VNet demo as well.

Performance improvements at scale for SSH

Ben: So next up, I'm going to talk about some performance improvements at scale for SSH. We've added a new SSH multiplexer for machine-to-machine communication using Teleport Machine ID. For people who are new, a lot of my flow that you've been seeing, I've been clicking the UI or have been using the terminal. But about three years ago, we noticed that people wanted the same access rules for machine-to-machine communication, such as scripts running, CI/CD services. And Machine ID was introduced to issue short-lived certificates for these machines. And I'm going to give you an overview. I think one classic example is you have Ansible. And so Ansible is a tool using just OpenSSH. So if I run my playbook here, this is just kind of pinging all these hosts. It'll be pretty familiar for people who are familiar with Ansible. And it's easy to kind of show what's happening under the hood in my audit log. So you can see instead of my user, you can see that my Ansible bot has performed all of these commands on these hosts. You can see this is sort of how Ansible works — it sort of uploads a file and then executes it to complete that. The thing that is different with Ansible is — let me first show you my Ansible config. Pretty standard. We have just the standard SSH config. But the one change for SSH config is we now have this addition of a new service type, which is multiplexer, and then we also have a proxy command which uses this new `fdpass-teleport`. If you have downloaded Teleport, you see that this is a new binary that's available, which is a much smaller Rust-based binary just for this specific use case of improving connections for machine-to-machine connectivity.

Ben: And so yeah, if you haven't used Teleport in the past for sort of many tens or hundreds of thousands of SSA connections, you might run into memory issues. We have noticed up to 200% memory reduction. This generally improves performance as well. And then you can learn more as well going to this tbot `ssh-multiplexer`. Let me just come in, see if there's any questions coming in. All right. Let's keep on rocking. All right. I've given the demo. Another bonus addition is we've now added support for kubectl in the UI. So if I come back to my Resources, I have my cookie cluster. I'm going to connect. Previously, you would connect — let me just make my terminal a little bigger for everybody. So let me log in. One other thing that I can note out here is when you’re logging in on the command line, we also have Device Trust and [inaudible] enabled. `tsh kube login cookie`, and then I could do `kubectl get pods`. First connection is connected. And so this would be the standard flow. People who have used Teleport Kubernetes Access will be familiar. But now you can also have the same experience in Teleport itself for just exec’ing into pods, which can be a very helpful tool just for some quick diagnostics and debugging.

Teleport 16 - Breaking changes

Ben: A few breaking changes. We have the Community Edition license. This has already been changed. I know a lot of people who've been in Teleport for a long time have already reached out to us, so I'd like to thank everyone who's done that. For people who are running self-hosted, if you haven't had a new license file in the last year, we'll do another license check. So it's worth just checking in with your account rep to make sure that you have an up-to-date license file prior to the updating because it will do a validation on startup. So if you are just doing your rolling startups, this could be one reason why it may not start. MFA is now required for all local users, which is, I think, a great security addition. I would recommend picking up a bunch of YubiKeys, an easy way of making it very simple. Incompatible clients now rejected. This is very handy if you have lots of people in your organization using Teleport running into weird bugs. You have to have at least one major version difference, at least for the tsh client. It's a few other permissions on DynamoDB and everything else we've documented in our change log as well. I'd recommend checking that out.

Ben: Okay. So now we have our last poll and I'm going to open it and share it. Which features are you sort of interested and excited to try? Oh, one other thing I didn't mention is `tctl` for Windows. This is a tool for sort of administering your cluster. It's a very helpful tool. New integrations for Teleport policy. I can probably share this quickly. [inaudible] share your Ansible file. Yep. All right. We have one VNet. We've had one for Teleport Policy. I'll show you this quickly since we had one vote. See people coming in. A couple more minutes. And you should see in the — it's next to the chat. There's a Polls selection. Oh, one love for the multiplexer. And the person who works on this will be very excited. Okay. A little bit more per-session MFA. Okay. Well, the one feature I didn't show is getting most of the love. So I guess this is a sign I should show off Teleport Policy for a little bit. All right. Let me get one more vote out of you. I think that's it. That's good. Okay. I'll stop sharing, but I'll keep it open.

Ben: Let me come back and share my screen again. I think I can actually share my tab. Okay. So let me come in. Okay. So we've kind of gone through the Resources view. We have access management. We talked a little bit around access monitoring under identity. Oh, another addition we didn't talk about is session and identity locking. This was added in previous ones, but it's another very helpful tool. So along with locking users, you can lock devices, MFA devices, servers. This can be helpful from both a security perspective, but also operational. Let's say you don't want people logging into servers during a core working hours. This is a very helpful way to just enforce those rules. And then Access Lists. This is a tool which we didn't cover but basically lets you add people for a much longer period of time as well. And Access Graph is an addition to Teleport that gives you an overview of who has access to which resources. So for my user, you can see all of my actions and which resource groups I have access to. So especially if you have a large amount of hosts, this becomes very helpful to say, "Hey, who has much longer standing privilege than they should?" And you can start thinking about putting those people into user groups.

Recommended next steps

Ben: So you see Bob, Bob's great because Bob has zero standing privileges because Bob had to do the access request. So this is a good overview and we've added a range of new integrations. So we have AWS, Okta, Entra, and GitLab, and we're working on Azure and GCP as well. So if you also want to understand those third-party services, this is also a great way to get started to understand what do all of your IAM policies and access relationships look like. And so you can sort of start understanding the problem and then looking at reducing and moving to zero standard privilege. Okay. So next steps, you can try Teleport Cloud — people who haven't tried Teleport. You can join our Slack channel. This is Community Slack. It's a great way to answer questions as you get started. Now is a great time. We're on actually 16.1 now. Good time to upgrade your Teleport cluster. I would definitely check, make sure you have an up-to-date license file. If you're using Teleport Cloud, updates have already begun this week. You just want to make sure that you are using automatic updates on the agents as well. And you can set your maintenance window and work routine there.

Q&A

Ben: So now we're going to move to the Q&A. I think we have 10 minutes. I know there's been a few that have come in. So you can either ask in the chat or in the Q&A box. All right. Lexi is promoting our next webinar. Thank you, Lexi. Any Q&A, any questions, I'm happy to answer them. See, we have some people. Don't be shy. Even in the chat is good. All right. I did cover a lot of content today in lots of different areas. Like I said, I'm hanging out in the Community Slack channel. Our team is always here. We have a great SE team. We just have a great team in general. So if you have any specific questions, we're more than happy to help answer and go sort of deep into anything that I covered today — okay, here we are. We have one. They've changed how to share it. But oh, here we are. Okay. Here we are.

Ben: Is the Docker Compose file somewhere for Teleport setup?

Ben: Yes. This should be available in our Teleport repo. We've also moved to — we sort of cleaned up our Docker images recently as well, but I believe our Docker setup should be all up to date. So just check out our Teleport repo and I'll give you in the examples repo that they'll be available there. All right. Any other questions? All right. Here we are. Yep. You're welcome. Happy to help. All right. I think everyone's ready for their morning coffee still. I think I will. So I will wrap this up and get on with that. But I'd like to thank everyone for attending today. And like I said, if you have any questions, I recommend checking out Teleport, join our Slack channel, download it, run in your lab. We're always here and happy to help. Caleb, thanks for joining. All right. Okay. Everybody. Well, have a great rest of your week, and happy teleporting.