Overview of Teleport 12: Device Trust and Desktop Access
Overview of Teleport 12: Device Trust and Desktop Access - overview
Join us as we showcase the latest features of Teleport, the first identity-native infrastructure access platform for engineers and machines. Teleport delivers phishing-proof zero trust for every engineer and service connected to your global infrastructure by replacing insecure secrets with true identity. In this episode, we cover:
- What’s new in Teleport 12
- Support for Windows servers and desktops, including non-AD connected workstations, desktops and servers with a demo
- Identity-native proxy that extends beyond infrastructure primitives to provide scoped access to cloud providers, including AWS, GCP and Azure
- Support for 4 new databases — AWS DynamoDB, AWS Redshift, Azure SQL Server and Azure Flexible Server
- Per-Pod RBAC for Teleport Kubernetes Access
- Teleport Device Trust, a feature that provides enhanced security by requiring trust of devices before granting access to resources
Learn more in this blog post.
Key topics on Teleport 12: Device Trust and Desktop Access
- An attack typically involves a sequence leading to a breach: humans making mistakes, attackers exploiting human error to steal secrets, attackers establishing a foothold, and pivoting to adjacent systems.
- The probability of a secret leak grows with scale and complexity.
- By having a central place for both your services and engineers, you can consolidate all the rules and access controls for them, and also identity, into one central access platform at Teleport. When you access all of the resources you have, you can fine-tune how you give access to those resources.
- Teleport is an identity-native proxy in which everything can connect. All of your infrastructure connects to Teleport, and so do all of your engineers and machines. And within Teleport itself, we have an audit log and RBAC engine.
- From expanded Windows and Kubernetes support, to a preview of a brand new feature (Device Trust), Teleport 12 is loaded with improvements and new capabilities that make it easier than ever to securely access your entire infrastructure ecosystem.
Expanding your knowledge on Overview of Teleport 12: Device Trust and Desktop Access
- Teleport Passwordless
- Teleport Device Trust
- Teleport Machine ID
- Teleport Server Access
- Teleport Application Access
- Teleport Kubernetes Access
- Teleport Database Access
- Teleport Desktop Access
Learn more about Overview of Teleport 12: Device Trust and Desktop Access
- Teleport Labs
- Contribute on GitHub
- Join our Slack community
- Participate in our discussions
- Why Teleport
- Get started with Teleport
Transcript - Overview of Teleport 12: Device Trust and Desktop Access
(The transcript of the session)
Ben: 00:02:16.235 Okay. So I think now's probably a good time to kick things off and start today's webinar. My name's Ben Arent, and I'm a Developer Relations Manager here at Teleport. And today I'm going to give you an overview of Teleport, Teleport 12, and a lot of the features, but mainly going to focus on Device Trust and Windows access, which are two new additions to Teleport. But I'm going to start with a small story to start or end your day. This will probably be a very common sight for many people, either through COVID or working from home: you're working on your desk, you're looking out your window; all of your colleagues around the world obviously like Teleport. And this is sort of the standard practice for people working remotely. Modern workforces work from home. They work anywhere. They might bring their own devices. You're looking out the window, trying to figure out why your build is broken. And as you end the day, you might relax. You pick up the latest Gone Girl movie, a good thriller. But you recently learned about your home lab, and you've just installed Plex on your machine. And so you are using Plex to stream your media from one device to another. It's super smooth, it's super cool, super streamlined. It's a great home lab server addition to add.
Ben: 00:03:53.176 But as you're relaxing, something's happening in the background. And you may notice that something isn't quite right with your machine, and suddenly things are going a bit slower, a bit awry. And the next thing you know that your security team says, "SIEM alert is going off, and something bad is happening with your infrastructure." And then the next thing, you realize — oh, your whole database and keys are suddenly on the dark web, and someone has access to your infrastructure. And you think, "Oh, I was just sitting at my home desk looking out at the view, trying to watch Gone Girl, charge, and relax." And you might think, "Ben, this seems like a crazy story. Why would you start with this?" I start with this story because this is pretty much the scenario that happened with LastPass earlier this year. It turned out LastPass had a vulnerability in which a senior DevOps engineer had installed Plex, which had a remote code execution. The attackers had installed a keylogger; they got access to his master password vault. Then they managed to get access to their cloud environment, which was S3. And unfortunately, they also had encryption keys to LastPass backups. And so what we have seen is — this isn't just LastPass; this is also other companies. CircleCI also had an instance earlier this year in which an engineer was a target of an attack in which an MFA-backed hardware token was taken from them.
Anatomy of an attack
Ben: 00:05:28.153 And last year, unrelated, I interviewed their CTO, Rob, and we talked about securing CI/CD. And I will read this quote from the podcast verbatim. You can scan this QR code and get access to this podcast. And so I'll just do that. "And so understanding that no matter how strong our systems are and how well-designed your software is, there are pathways for people to perform actions. And you have to think about the human element in your environment." And I think this is a great example and a great introduction into the anatomy of a common attack that we see. And so these are common approaches in which a sequence is leading to a breach. A human makes a mistake — you may unwittingly, unknowingly, make this mistake. In this case, for LastPass, it was installing an outdated version of Plex on the same machine that they use to access production environments. An attacker exploited this error and managed to steal a secret. They got a foothold in their infrastructure and then pivoted to adjacent systems to get access to the keys. And there's many responses. So there's training process visibility. For example, phishing is a common way in which humans make mistakes. Just by clicking a link, bad things can happen for people.
Secrets do not scale
Ben: 00:06:47.779 And then exploiting secrets. So people often have secrets management or vaults, and then they might get that secret, and then they use that to establish a foothold and get into adjacent systems. And what we found at Teleport is that secrets don't scale. The probability of a secret leak only grows with scale and complexity. And for example, let's say I have to take a very simple example of — you wanted to give someone access to a database table, let's say a Postgres table. Not only do you give access to the database protocol to get access to that database, you might give them access to the machine itself. So you have to protect your SSH. This database may be running Kubernetes, so you might need to protect the Kubernetes API. You might be using a console, so for example, pgAdmin, to administer your database. You also need to protect this, and then you also have the raw infrastructure itself. For example, AWS Console. And then you also have to think about all the other things which also interact with that database table. For example, your CI/CD service might read or update those tables. And so you can see, very quickly, just for one database table, there's so many secrets that you have to need and protect.
Ben: 00:08:00.033 So before I dive into Teleport itself, I'm just going to get a quick poll here to see and launch it. Okay, so I need to stop sharing. And I'm going to present this poll. And so this is just a poll to say, "Are you currently using Teleport?" So I can get a gauge of where the audience is, so I can tune the next part of the webinar for everyone. So you should see, in the right-hand side, under poll, you can enter this — so let me know if you can find the poll. Okay. Yep. The result's coming. I'll give it a minute or two. Okay, great. It's surprising, actually. It's great to see a lot of Community Edition Teleport, which is our open-source version, a mixture between Community and Enterprise, and then some people currently evaluating, and then seven people who are new and just want to learn more about Teleport. So a nice blend, and it's great that people that are already using Teleport are here today. So I'm going to go back to my slides.
Before and after Teleport
Ben: 00:09:30.804 And so for people who are new to Teleport, this might be the case of your current environment. You might have multiple services, multiple infrastructure. You probably have a mixture of tools which you've either inherited over time or have adopted. You might have a bastion, a jump box, some legacy PAM infrastructure. And we see this as very common. As sort of teams grow, you have a range of infrastructure and resources that you need to get access to, but it sort of creates this big web and this big mess. And once people have deployed Teleport itself, which is an identity-aware access proxy, it centralizes everything. And there's many benefits to centralization. One is — by having a central place for both your services and engineers, you can consolidate all of the rules and access controls for all of these things, and also identity, into the one central access platform at Teleport. And then when you access all of the resources that you have — so let's say, your servers, your Kubernetes clusters, your databases, web apps — you can always fine-tune how you give access to those resources. And if you haven't centralized things, as you know, let's say, if you have multiple cloud providers, there's just more possibilities that someone could get a foothold and access your infrastructure. And one thing that Teleport does is — we remove secrets. And so as we go back to that example of LastPass, human error obviously revolves around secret service, passwords, private key, session tokens. And one thing that's core to Teleport is the security model does not use secrets. The agent is stateless. You can use biometric authentication. We use short-lived certificates. And as we are going to go today in — we're going to go further into using HSMs in the data center or TPM near your client for Device Trust.
How Teleport works
Ben: 00:11:26.711 How Teleport works. This is just another extension of that previous diagram. As I mentioned, it's an identity-native proxy in which everything can connect. All of your infrastructure connects to Teleport, and all of your engineers and machines connect to Teleport. And within Teleport itself, we have an audit log and RBAC engine. One thing that's also very popular with Teleport is identity provider support. So instead of managing all of your users, you can use an external SAML or IDP, for example, GitHub in our community edition or, let's say, Okta in our enterprise edition. And then you can use those external groups to define who can get access to which infrastructure. But when an engineer goes about their day — and we'll show a demo — you log in; you can just use your standard tools. So you can use kubectl or tsh. Lastly, in this diagram, you see we have just-in-time access. I'm not going to touch on this too much, but this is sort of a great feature that Teleport provides to allow you to implement the principle of least privilege. So only people with limited access — you can give people very limited access, and they can request escalated privileges.
Introducing Teleport 12 and Teleport Device Trust
Ben: 00:12:42.301 So Teleport 12. Today, that was a little quick introduction into Teleport itself. Now I'm going to dive into Teleport 12. So I'm going to start with Device Trust. We actually released this blog post just today. Hopefully, someone can put this in the chat. And one thing that we've always been working at Teleport is sort of going beyond the perimeter security model. This, for people who aren't aware, would be — historically, companies used VPNs. And then, about a decade or so ago, Google came out with their BeyondCorp paper to say — and the ideas of the Beyond Court paper was you can't trust the network. So you can't just use a VPN as a strong perimeter. And Device Trust is another security model that also improves the BeyondCorp model; by also only adopting, certain devices can get access to your infrastructure. And I'd highly recommend reading this blog post. And I'm going to sort of go a little bit over what Teleport Device Trust is. So Teleport Device Trust is a new feature added in Teleport 12. It allows you to only allow registered devices to access your infrastructure. And for example, in the case of the LastPass example, if that individual was using his home workstation to access company resources, this wouldn't be the case because Teleport Device Trust only allows company-issued or enrolled devices to access your infrastructure. And it does this through using and saving the private key in the secure hardware store. And so if there is even any malware, you can't exfiltrate it, you can't get the session token.
Device Trust demo
Ben: 00:14:27.207 We currently have preview support for MacOS. This is in preview. We have Windows support coming in Teleport 13. And another piece of early feedback that we've got is Jamf Environment support. Jamf's a very common enterprise tool for Mac for enrolling your fleet quite easily into Device Trust. So I have a video here. I'm not going to play the video, but you can view it on your own time. But once you have added a device, there's a whole enrollment ceremony. Once you've completed the enrollment ceremony, you get an asset tag, and you know which device is accessing which infrastructure, and you can enforce it. So I'm going to show a little demo here. Let me share my terminal. Let me make this a little bit bigger for everyone. Okay, so I'm going to show just one thing off Teleport itself. So I'm going to start off by logging into Teleport. You see, I'm using this command line called
tsh login proxy. In my other window — you can't see this, but it opened up a little browser window. I was already authenticated, and so now I've logged in as
benarent, which is my username. I have access to these roles and these logins. I have access to Kubernetes. And for example, now if I take my Teleport Server Access, I can view all these machines. I can
tsh ssh [email protected]. And like that, I've already got access to the host. And so this just makes the developer experience and workflow super smooth for accessing infrastructure. And everything gets also audited and collected as well.
Support for Windows servers
Ben: 00:16:26.827 But for Device Trust, one of the important things you need to do is, for Mac, you need to make sure that — we have this
tsh touchid diag tool. This kind of lets you know whether your machine, and also the binaries that you have, support Teleport Device Trust. And so this is a great way of debugging whether it has been added or not. If it is turned on, you will see it on the
tsh status. I currently don't have the extension turned on since I just enrolled a new machine, but it'll show up here that Device Trust is turned on. And that's a little short overview of Teleport Device Trust. So let me stop sharing, come back to my presentation. Next up, I'm going to be talking about Windows servers. So we added Windows server support, I believe, in Teleport 8. When we launched this, it required all of these servers to be added to an Active Directory domain controller. Since then, we got feedback that we wanted people to add one-off hosts to Teleport. And now you can add individual hosts which aren't connected to AD. And so this could be one workstation that's in a sort of factory somewhere, or this could just be just like one isolated server on EC2, which you use for managing certain jobs. So for people who don't even have a full Active Directory domain controller, you can use Teleport Server Access. Some of the features which I gave us: we have clipboard support, cross-OS folder sharing, session recording. And we've also made some improvements to session playback and performance improvements.
Ben: 00:18:21.110 Okay. So let me log into Teleport using the web UI. I have to change my window again. There's lots of changing. And so this is the proxy that most people are granted with. I have GitHub set up for SSO, but we also have options for passwordless as well. So I'm going to log in to Teleport. And you'll see here this is the same inventory that you saw on the command line. I have all of my hosts here, my servers. I have some applications which I've added to Teleport. So for example, my Grafana, my Jenkins, my Metabase dashboard. I have one Kubernetes dashboard. I have a suite of databases, which I'll also dive into later in this webinar. And this is what we came for — is Desktops. So here I have one desktop. I'm going to log in as administrator. It's going — oh, hold on. I opened it in another tab. So you can see, here, I am now on a Windows server. So I can run, for example, the calculator. I can just go about standard ask such as Windows Paint. And you can see, we've definitely improved the performance. It's much more performant than the other versions of Teleport. I'm not going to save this.
Ben: 00:20:04.970 We have clipboard support. So if you wanted to get your server logs — let me just open actually Notepad. Hello. Good. I have the ability to copy and paste. So notepad's enabled. We also have options for directory sharing. I can show you how directory sharing works. So if I come to my downloads — let me find a folder here. So I've now shared a folder. Unfortunately, you can't see this with our webinar platform. But in my PC here, you can see I now have cat photos on Teleport. This is the folder sharing that we support. And so you can see the folder sharing up here. It's directly sharing. It's turned on. And so this makes it super easy to both copy logs and then also copy files from your Windows servers or export them. This is just a dog working on a computer, not the most important log. And so now I'm going to disconnect from this session and close this tab.
Ben: 00:21:31.712 Now I'm going to show you some of the auditing capabilities. And so one thing you'll see here, we have all this information for the audit log. So you can see, we have clipboard data. We have directory sharing under our session recordings as well. We have a full recording of the session. Let me share the window. This can make my — I think this should make this easier. I'm going to play the session. You can see the session plays, and this is the session we just had. So we just increased and improved our playback. You can increase the speed. As you can see, I went to the “hello world." I got the dog, and that's the end of my session. And so this is a very powerful feature to know what happened during the session along with the audit events and a great addition to Teleport Server Access. Just a note that the non-AD or passwordless login for local users is only an Enterprise-only feature for now. Hopefully, we should extend this to our Community edition. But we're starting with our Enterprise, and so we're open to feedback and we'd love to hear what you say.
Ben: 00:22:56.088 So going to just look at the chat here see if anyone has any questions. Okay, I have some questions here. Service support for Linux. We don't currently have this on our roadmap, but there is a ticket. As I'd recommend — at Teleport, we're an open-core company — check out our ticket in GitHub issues. And then "Would Device Trust also work for Teleport Cloud?" Device Trust should work for Teleport Cloud. I think that they upgraded last week, so you should be good to go. I think the documentation has been updated. Well, also, if you're working with someone on support, they're happy to help as well. And so we have another one around "What's the release schedule for Teleport 13 for device enrollment, but using Windows." This will be in — it's like a three-month window. But often, we'll do an early release and we love to get feedback from users. So if you send me an email, [email protected], happy to get you connected with the team. We're sort of very open in the way in which we develop our features.
Ben: 00:24:31.745 All right. So I take a quick pause from questions and then kind of keep on rocking. Okay, so we've gone through the Teleport demo. Oh, and then we have this video here. You can click this link or scan this QR code. This goes over how you set up the Windows access preview. One nice addition: we have this exe, which you just sort of install, and it makes the setup very smooth compared to our non-AD environment. Okay. Next feature I'm going to be talking about is GCP CLI support. For a while, we've supported AWS CLI and AWS Management Console. This feature lets you basically provide access to your AWS resources and such. You'd see, in my applications, I have a dev account. I can share an AWS role to CloudWatch. This is a very limited view, and so this lets you provide a very fine-grained role that people can assume to get access to AWS and only certain resources. And so this is a very useful addition. Once we added this access to the web console, people asked us to add support for the CLI, and so you can use this for AWS CLI. And in Teleport 12, we added Azure and GCP.
Ben: 00:25:56.839 And I'm going to do a GCP demo. So let me come back into my terminal. So I'm going to do apps. We have this Google Cloud. So I'm going to do
tsh app login google-cloud-cli. "Your services account has been added." This is a service account, which we've set up to assume. Then we have this new command, which is
tsh gcloud, and so I can list my instances. And I can list my instance. This is the Google Cloud telling me I have a “n1-standard” running. And you have access to the full suite of options from GCloud, depending upon which role you share. So this is a great tool for, let's say, you just want to give people a very fine role for just the instances or maybe just a big query, everything. Of course, it goes through Teleport. And we have a full audit log as well. And so if I come back into management here, you see in my audit log I have a new data chunk that a GCP session was started on which cloud and which user assumed this role. And so greatly reducing how you have to sort of share and have that one centralized place for Teleport to give access to your GCP roles.
Teleport Database Access
Ben: 00:27:35.605 Okay. Chugging along. Next addition, we have Teleport Database Access. I did a count yesterday. I think we're around like 32 supported databases. We have a full list in our guides here, Database Access guides. We added four new ones in Teleport 12: AWS, DynamoDB, Redshift, and Azure SQL server and Azure Flexible Server. We have all the guides here. There's multiple ways in which people deploy Teleport. I personally like a sidecar model in which I run the Teleport database service alongside the database. This is very common, especially if I have a Postgres or MySQL in a private subnet, and I need to get access to it. It's a pretty common problem with a database service. And going through Teleport, it means you never have to open up any firewalls to all of your employees. So it makes that whitelisting and firewall problem much easier, and then everything sort of goes to Teleport.
AWS DynamoDB demo
Ben: 00:28:36.635 So let's do a demo again. Okay. So back into my terminal. Okay, so this is a similar pattern. So I do
db ls. Yeah, I have all of my databases here. Just a note for — you might see these labels. Labels is a great primitive that you use for RBAC. For example, you might add certain people only have access to the staging environment or the production environment. These can also be dynamic. They can update based upon certain maintenance windows. See my server tags. We can pull in AWS tags as well, automatically. And so for people who are maybe just starting out with Teleport, I would highly recommend checking out our RBAC system and our labeling system in combination. So let's get back to our database. So let's log in to DynamoDB. So you see, your connection information for database DynamoDB has been saved. You can start a local proxy for my user. So I'm starting
tsh proxy db --tunnel. I have my role, and then this is the name of my database. DynamoDB.
Ben: 00:30:08.253 And then, so you can also specify the
--port flag. Use this command line, which you can use for both a database GUI or a CLI client. And so what's kind of interesting here is you see that this is an endpoint pointing to local host. So I actually need to open up a new tab here. Oh, this one's way smaller. And then you'll see that this says — oh, it needs a requirement. So let's just describe endpoints. And then here we have — so this is describing the endpoint that we have and the cash period. And so this has access to all of the options that you have. The range of flags. I don't know what the rest of the commands — I think I need to describe what I wanted to do. But that kind of gives you an overview of the connection. Another important thing. You see here we have the database certificate. This certificate is valid for nine hours. This is also configurable. And this is sort of also a strong fundamental of Teleport, that every certificate and access that you get issued is valid for the period of time that you define. And so for my role, I have nine hours, which is a great working day. And this also solves the problem of, let's say, someone's computer was stolen. If they got access to that machine, they would have to revalidate and get access to their infrastructure to get the new certificate. And so these short-lived credentials and certificates are very helpful. We also add this extension to Machine ID, which is another feature.
Additions to Teleport Kubernetes Access
Ben: 00:31:55.720 Okay. So let's come back to my slides. Okay. Let me see. I have some questions in the chat. Okay. I think I'll probably answer questions at the end. I'm going to just keep on trucking. Another addition to Teleport 12: we've made some great additions to our Kubernetes Access platform. We've updated and refactored our Helm charts, which has also split out how we deal with the auth and proxy. I'd highly recommend checking that out if you have previously upgraded this documentation. One thing I'm going to focus on, which is a new addition in Teleport 12, is per-pod RBAC. This is super exciting, and this makes dealing with sort of RBAC much easier than linking to Teleport roles. And then, also, we have a lot of performance improvements. So for people who are new to Teleport, this is what a role looks like. One addition in Teleport 12 is this edition of a Kubernetes resource. In this example, we're only allowing pod access to production with a web app with this regex and any pod in the development namespace. Previously, you'd have to create groups or Kubernetes users. This means that you can provide very fine-grained access to your resources without having to worry about internal mapping in Kubernetes itself. So let's show a little quick Kubernetes demo.
Ben: 00:33:43.096 All right, back in my terminal. And so it's the same flow: you can list, and then you do
kube login. And so I can do
kubectl version and
exec into a pod I have here. Okay. [inaudible] point. So now I'm in my Kubernetes cluster, but I've also exec’d into a pod. And so you can see, my developer experience is super smooth. I'm just using basically
kubectl to go about my tasks. And one benefit for people who have rolled out Teleport into their organization is that all of this information is also captured in the Teleport audit log. You can see I started a Kubernetes request. I sort of list the version. I did a
GET. I also started a session, and then along with sort of Session Recordings for servers, we also have Session Recordings for
kubectl execs as well. Okay. So there's the example of the session playing. And let me come back to our demo.
Ben: 00:35:23.370 So I'm going to just quick launch a quick poll here. So for all of these things I've demoed, is there any features that you plan on using next? I think the poll might be in the second tab, beyond the chat. Okay, give it a couple minutes. Okay. So it looks like we have a lot of “Device Trust”, which is great. Some “Per-pod RBAC”, some “Windows Module”, and some “AWS/GCP/Azure CLI”. So kind of a good blend across the board of features. And so next steps: for people who are new, we have a 14-day trial. Could just go teleport.com, sign up. You can also download and get started with our Community edition. Go to Docs, getting started. And then also we have our GitHub community and our Slack, which is also — we're an open-core company. You can create issues, and we're happy to help you out.
Ben: 00:36:53.374 So now I know we have lots of questions. If you could ask them in the Q&A, I know we have still a good bit of time that I can help answer. So Eric, "RBAC. You plan to add role inheritance and overriding?" For this question, for RBAC, I would recommend checking out our documentation. It does get kind of complicated and because creating an RBAC engine to provide the right amount of access can be complicated that you need to test it. We actually have a project called Predicate, which is available in our GitHub, and this is a way of sort of testing how RBAC rules work. That might help answer your question around inheritance and overriding. Generally, we wouldn't want to. We generally take the view of deny access more than allow it, from a security perspective. So in that case, we wouldn't allow overriding. And so it's also sort of a balance about how to get your RBAC in the right way, but we're also happy to help.
Ben: 00:38:07.942 We have one around Cloud Access Service Broker. I'm actually not super familiar with CASBs. And this is probably something that I'd have to get back to you on. I'm happy to follow up. Let's see — what else do we have? What’s the timeline for Linux devices? If this is a specific question — I don't know if this is Linux. Oh, is this Linux Device Trust? I believe this is also on our roadmap, but one thing that makes it a little difficult with Linux is — the way in which it works for Windows is that we use TPMs, which are trusted platform modules. I think support for different Linux distros — the way in which they sort of securely boot and use TPMs — can differ. And so I think if you have a specific Linux distro in mind, that would be something that we could kind of investigate and look into.
Ben: 00:39:10.970 Okay. So I think that's a lot of the questions. Any other ones in the Q&A, please add them in. Okay. Anything else? Let me see. Yeah, the presentation will be shared. We have the docs too. Okay. It looks like we're at the end here. Okay. "TPM should be usable with RHEL or Ubuntu, I guess." Yeah, so I think probably Red Hat Linux or Ubuntu — I mean, we'd love to work with Ubuntu. Probably, Ubuntu Pro likely has something. If you have a large fleet, what we often see is a mixture of mainly MacOS or Windows Teams really nailing down access. "Have you tried Windows-managed AD over GCP and tried to connect AD Windows Desktop to Teleport?" Yes. That should work. Managed AD is kind of finicky. I've only tried it with AWS. Probably, best thing is create a message in our Slack. We'll try and get into it.
Ben: 00:40:35.233 We have found that sometimes you need to add the root authority or change some permissions in Active Directory, and not all managed AD. Because it's managed, they don't let you change them. And so we can kind of look into that, but sometimes, they won't let you do that. Okay. I think that's likely the end. So I would like to thank everyone for joining. Thanks, Kat. She's added our community Slack in the top. It's great to have so many Teleport Community and Enterprise users today. Thanks for joining. And hopefully, I'll see you in three more months for the next version of Teleport, but there'll be many more features released in the interim. I recommend following our YouTube channel, also joining our Slack, and also subscribing to our newsletter. So thanks for joining.
Join The Community