Teleport 13: Automatic Agent Updates, Simplified AWS Setup, Light Theme, and More - overview

Once again, it’s time for everyone’s favorite announcement: a brand new Teleport release! This release marks version 13 of Teleport and is packed with features, including a UI makeover, performance improvements, a few exciting previews, and so much more. Let’s dive in!

Watch this episode recording with Ben Arent, Teleport’s Director of Developer Relations, as he discusses what’s new in Teleport 13, including:

Automatic agent updates: Teleport 13 brings you a much-requested feature: upgrading your Teleport agents is now easier than ever, with support for auto-updating. The Teleport 13 auto-updater allows you to automatically update all of the agents in your Teleport cluster upon new releases.
Simplified AWS & RDS onboarding flow in Access Management UI: Lets you directly connect an AWS account and onboard RDS databases
Light theme for Web UI for those who prefer to have a brighter display experience
Cross-cluster search for Teleport Connect for a new search experience without having to switch between individual clusters
And a lot more...including TLS routing through ALB for Server Access and Kubernetes Access, Application and groups import from Okta to Application Access, AWS OpenSearch support for Database Access, and more.

Key topics on Teleport 13: Automatic Agent Updates, Simplified AWS Setup, Light Theme, and More

Teleport is a secure access platform for your entire infrastructure.
Teleport 13 is packed with features, including a UI makeover.
This webinar includes video contributions from various InfluxData engineers to explain the new features.
Updates in Teleport 13 include platform updates, server updates, Kubernetes updates, database updates, Windows updates, and application updates.
New Teleport 13 features are summarized in this webinar and covered in this post.

Learn more about Teleport 13: Automatic Agent Updates, Simplified AWS Setup, Light Theme, and More

- Teleport Labs
- Contribute on GitHub
- Join our Slack community
- Participate in our discussions
- Why Teleport
- Get started with Teleport
- Teleport Resource Center
- Teleport integrations
- Teleport documentation

Transcript - Teleport 13: Automatic Agent Updates, Simplified AWS Setup, Light Theme, and More
(The transcript of the session)

Ben: 00:00:00.598 In one more minute. All right. Enjoying the comments. I'm going to give it a few more minutes so everyone sort of comes in. I think we still have everyone coming in today. I'm really excited to do this webinar. Oh, Philippe from France. Nice. I have the same middle name and the same spelling. Thank you for joining us today. Nathan from San Jose. Welcome. Another Teleporter who's joined us. Excited to have you today. So give it a couple minutes or so, and then I'm going to kick things off. And as people get going, I will just do a quick introduction. So today's webinar is all about Teleport 13, and Teleport 13 is our 13th release of Teleport. And it's a bumper release with lots of different features in it. We're going to be covering a few core features, but I'm going to go over all of the platform features as well. Some highlights will be automatic agent upgrades, simplified AWS setup, a light theme, very exciting, and more.

Ben: 00:01:14.678 So just an overview for today. For today, I'm going to just do a quick Teleport overview. Just a small introduction to what this is. This won't be an "Introduction to Teleport" webinar, but it'll be a great place to get started. And I've split the Teleport 13 webinar into 6 different stages. So we have updates of the platform — the platform being just the core services and the CLI tools that we have — server updates, such as accessing OpenSSH hosts and infrastructure servers, cloud servers, and hardware; Kubernetes updates; database, Windows, and application updates; and a quick summary at the end. I'd also like to thank everyone who has helped make videos to contribute to this webinar. It's just going to be myself today, but I have five other devs — you can see all of their GitHubs here — who have contributed videos and features to the edition. And then Teleport is an open-source, open-core product. This feature release only scratches the surface for the contributions that we made. Over 276 people have now contributed to the Teleport project, and I'd like to thank everyone for their contributions.

Teleport overview: a quick introduction

Ben: 00:02:28.028 So what is Teleport? Teleport is a secure access platform for your entire infrastructure. We started out accessing servers. And one thing that we found was that the way in which people were accessing their infrastructure lacked a few key things. And one thing that it particularly lacked was the addition of identity, and so people did not know who was accessing which machines when. And then the credentials were always long-lived. One thing that is unique about the Teleport access platform is it is "identity first." And so anyone who's accessing your cluster is tied to a SSO, or user identity. This is also true for CICD services with additional machine ID. You also know the identity of which machines are talking to other machines with zero trust, meaning that, beyond the network perimeter, the only way to get access to your resources is through Teleport. We are certificate based, meaning that everything is backed on X.509 short-lived certificates. These have a few interesting properties which help with short-lived access, for example. You will see some examples today in which I log into the Teleport cluster and I have a short window of access. And certificates are issued, and they also automatically expire, which is a very handy addition of it.

Ben: 00:03:50.274 Another core feature is just-in-time access. This also reduces the concept of zero trust, in which you follow the principle of least privilege. And so you only give people access to their resources for certain periods of time. And just-in-time access requests mean you can say, "I want to follow the principle of least privilege and only provide access for a short period of time." And lastly, since Teleport is an access proxy, we provide complete visibility into access for engineers and machines, who's accessing what. We have a complete audit log, which you can ship off to your SIEM solution. But today isn't an "Introduction to Teleport" webinar. We have a great video here, which we'll put in the show notes, to sort of go over the Teleport access platform from Phil and Alex. And this is a great place. If you're really new to Teleport, I'd recommend getting started here. And actually, since we're getting started, I'm going to just do a quick post-check to figure out where people are with using Teleport. And so I'm going to stop sharing quickly. And I'm going to share the poll. And you should be able to fill in. "Are you currently a Teleport user?" Looks like we have one vote. So it must be working. Okay, so it looks like we have some people coming in: mostly enterprise edition Teleport users and a few people exploring, learning. Let's give this a minute or two for everyone to finish. Get your vote in now. Okay, I am going to close the vote, but it looks like we have lots of customers here and a few people learning. So that's great to hear, and I'm hopefully going to cover a lot of features.

Ben: 00:05:49.383 Feel free to ask any questions in the chat as I go through the different features. I'll do Q&A at the end, but I'm also happy to answer questions as they come up. So let me come back to sharing my screen. Okay, so Platform Updates. Platform Updates is going to cover some of our core services. So for people who are existing Teleport users, this is around improvements to our auth, our proxy, our backends, our agents, our CLIs. One of the most important additions that we've added for long-term users is around automatic agent upgrades. And as we've continued to ship our product, we've had some of our customers say it's been tough to keep up with all of the features that we're shipping. And we hope that automatic agent upgrades will be a feature that will solve this. And I have a video here which I'm going to play that will show you an overview of this feature.

Platform updates

Miguel: 00:06:57.093 Hey, everyone. I'm Miguel, and I'm going to present automatic updates for Teleport agents coming in Preview in Teleport 13. With this feature, we are trying to address two use cases, two issues. The first one is for customers with large deployments. They have a lot of agents, and it's taking a lot of time, and they have to build automation to be able to update all their agents. And the second issue is for cloud because we are maintaining the Teleport cluster for cloud users. And we are updating the Teleport version, and we want them to update the agents, but they have to constantly update. And we have to chase them for them to update. So in order to scale better, we want to just be able to push the updates to them. So life will be easier for them because they won't have to update, and it'll be easier for us because we won't have to contact them.

Miguel: 00:07:46.757 In Teleport 13, we will support two deployment methods: apt/yum installation on systemd-distro, so Debian, Ubuntu, RedHat, CentOS, Amazon, Linux, and Kubernetes installation with the teleport-kube-agent charts. The feature was developed to be cloud-first, but it's also available for on-prem. It's just, for cloud, you have really minimal configuration; it's going to work out of the box, and you have Teleport Discover Support. This means if you open Teleport Discover and add a new node in the UI, you will end up automatically enrolled into agent automatic updates, which is not the case for on-prem yet. The UI integration might come later. And we are also not providing an Ubuntu package yet. This might happen next. The way it works: each agent has its own updater. The updater is a separate binary from the agent. We want the agent — let's say we push a broken version, and the agent becomes broken. We want the agent to be broken but the updater to still be able to update the agent. So this way, we can push a new version which fixes the issue and the agent will recover. We don't want to have to contact customers, so they have to run manual commands on all agents.

Miguel: 00:09:01.801 Either the customer for on-prem setups or cloud sets the maintenance window in Teleport, and Teleport advertise this maintenance window to all the agents. The agents are reporting their maintenance windows in a file or Kubernetes secrets, and the updater is checking the secrets. If we are in a maintenance window, the updater knows that it can try to update the agent if there is a new version. The updater will try to update the version in two other cases if the agent is an LC, because, let's say, for example, we pushed a broken version and updating a new version might fix the issue. So we want to update if the agent is an LC. We're not going to disrupt anything anyway. And if the new version is more critical — let's say we have a security issue which is currently being exploited — we want to fix all agents as soon as possible. So we can flag maintenance as critical. Once the maintenance is triggered, we are going to look at the version. It's hosted in the S3 bucket. The updater gets the version and compares the version with what is currently running. If the version is different, it's going to use apt/yum, or for Kubernetes, it's going to update the deployment to be able to update the system, the agent. The updater is triggered every 30 minutes at most, so it means we have one hour-long maintenances. And we know that at least one tick will happen during the hour window. We have one difference for the Kubernetes agent updates. The updater is also verifying signatures because apt/yum are doing signature validation and Kubernetes does not. So we have —

Ben: 00:10:43.945 Oh, apologize here. I meant to pause it here. I know this video is actually a little longer than I first remembered. So one of the key takeaways with our automatic agent updates is we have functionality to also update the agents. But also, if there's a security issue, you can force do an update. And there's a fail-safe way. I know the audio was a bit high here, so this one is also available. I'm going to share this one afterwards, and probably it's going to keep on going. I'm happy to answer questions for the agents. I think the other ones will hopefully be better and a bit clearer for future videos. So moving on. For light theme, this is a relatively small addition. Interesting enough, when I first started to Teleport, Teleport was naturally a light theme, but now we have the option. In Teleport 13, it is a default, but there is a dropdown which you can set light theme per operating system. One other addition we have here is TLS Routing Layer7. And let me share this video here.

Server updates

[webinar contributor]: 00:11:59.198 So the doc is getting reviews. This is my local copy. So you should expect some changes in the TLS routing migration page and also here at the [inaudible] routing under the architecture section. So I'm trying to add some diagrams explaining how things work, but [inaudible] that, now, [inaudible] single prompt mode [inaudible], just a single port. So here's my [inaudible] AWS application [inaudible] 443. And the public certificate comes from the AWS ACM. This is my password domain. And I also have developed [inaudible] application access. So the [inaudible] this target group is in HTTPS protocol. And there's only one target group. One needed. Now let me go to the [inaudible] proxy, YAML. So I have my [inaudible] in the same on [inaudible]. So the [inaudible] is enabled here. And then the proxy servers only need a single port and a single public address. So notice that we don't need to provide any certificate as well. The proxy can serve [inaudible] certificate because all the public traffic come to the load balancer as a real [inaudible] certificate from the ACM.

[webinar contributor]: 00:13:44.176 Now we have logged in through tsh. The first thing: let me show the tsh profile. TLS routing is enabled here. But also, you can see connection upgrade is required, meaning that tsh detects that my type of cluster is behind a Layer7. So for a regular setup, when there's no LB, this should be false. Server Access. Server Access should be the same as before — we can do `tsh ssh` the same way. Or if you want to use SSH client, you can use `proxy ssh`. Same thing as before, just when this proxy [inaudible], automatically does the version upgrade. Application Access. So for cloud applications like AWS, Azure, GCP, they're already using a local proxy. So no usage change there. Same thing for the TCP app, where you use a local proxy. So now if you do an app login on HTTP app, there's some small usage change. tsh will no longer suggest using curl directly with key certificate to talk to premium proxy directly. So now tsh will suggest using a local proxy similar to TCP app. For Database Access, you can use `tsh db connect`, which automatically uses local proxy on the background or you can create a local proxy separately with `tsh proxy db`. The usage will be the same. For Kube, Kubernetes access, so we also need local proxy. So we implemented `proxy kube`, similar to other local proxy commands. So we can do this. For example, it will give you a temporary config. So you can just export it and then here you can use your Kube application as normal. And now the traffic will go through the local proxy. So I'm not showing the web UI here because the type of web UI, because the Teleport Web UI, everything should be working as the same as before. Yes [inaudible] —

Ben: 00:16:11.619 So just to summarize here. For people who are longtime Teleport customers, you're probably aware that, previously, there were many port requirements. For configuring, setting up Teleport, you would set up different ports for databases, Kubernetes clusters, Kubernetes. The Layer7 TLS routing just gets that down to one port. But because we're going through one port, this is why we have the client proxy. And so you'll see, if you're running MySQL and disconnect, you don't connect over — I think it's 3306. You connect to your local proxy, and then you get access to Teleport, and this gives you access. And so for anyone, this makes deployments much easier. So you can just use an ALB, and then you don't to have to set up a separate — and also, if you're in your home lab, if you're using traffic, for example, it just makes your configuration much easier as well. Teleport Connect is a tool that we use for — it's a client tool for accessing clusters. We shipped this for Windows, Mac, and Linux. We actually have lots of Windows users using this since the native Windows tool's kind of limited. One of the other additions of Teleport Connector is it makes it very easy if you need to access multiple clusters and switch between them on your day-to-day. And one thing that we've made, in addition, in Teleport 13 is this UI for accessing and connecting, sort of our new wizard, which will hopefully make this as a quality life improvement. People who are in Teleport day-to-day, it makes your much easier. So if you haven't tried Teleport Connect, it's available in both our enterprise and our community edition. I'd highly recommend checking it out and using it to access your cluster.

Simplified RDS onboarding

Ben: 00:17:59.323 Another platform update is we simplified our RDS onboarding. RDS had certain requirements around IAM roles. Once you've configured this, there's a few options for making it easy to enroll those databases. You do still need to set up a sidecar and configure some IAM policies, but we hope that this should make it easier for you to involve resources. Another addition is Headless WebAuthn. We added this in 13. This is actually an interesting feature, especially if you don't have access to do a WebAuthn-passwordless access on a host. We actually have a new channel in our community slack called #demo, and there's a great video there from our CTO, Sasha. And you can see that he has started to do a `tsh scp` from a host `headless` to another host. And he has this URL here. So he starts this on the host. He gets a window on his local browser to execute that command. And so you can transfer files between two hosts without having to go into that host and connect to it. So I'd highly recommend checking this out. Headless can also work if you have SSO providers, which you can't get access to if it doesn't support WebAuthn natively, and there's a few other additions which make it very helpful.

Teleport Assist demo

Ben: 00:19:22.435 And Teleport Assist. Teleport Assist is available both in Teleport 12 and Teleport 13. This was launched last week, and this is our edition with GPT-4 to get facts on your infrastructure and generate commands and scripts on your behalf. So just to show this, I'm going to do a demo. I'll just share my screen again. Okay, I'm going to share this window. Okay, this is going to be better. Okay, so as for Teleport, we're going to log in with my GitHub identity provider. And now, in this dropdown, we have a third edition, which is Assist. And Assist knows about your infrastructure, and it can answer questions all around Linux and your servers. It can generate commands and scripts for you.

Ben: 00:20:18.470 And so for example, let's say, if we wanted to transfer two files — and we want to create a one-gigabyte file, so I'm going to create a one gigabyte file on staging boxes. And let's say I wanted to test this. It's thinking. Because it uses GPT-4, it takes some time. And just to note, this is my own cluster on — and this is also a community edition. This has found no nodes. This does look like a bug since this is a beta feature. But I'm just going to talk through it. So you can see here, Teleport has the option to connect to host using labels and then also execute a command on my behalf. This won't execute since it wasn't able to find my nodes for some reason. As with all new product releases, the demo gods may not shine lightly.

Ben: 00:21:24.638 But I have a few other examples here, like using netstat, for example. And you can see we have the user, or the principal, which logs into this host. And it provides the context. So let's say you want to know about netstat for production traffic. It can also explain what these commands do. And we're really interested to get your feedback on using this to augment your day-to-day flow. Maybe this just keeps you in Teleport; you don't have to go to stack overflow to get the answer. And this feature is only available in our community edition and Teleport Team. Teleport Team is our new self-service edition. We don't currently have this in Enterprise, mainly for compliance and security reasons. But if you are an enterprise user who's really interested in using this feature, we would love to hear about your use case and options. So next up, server updates. Chugging along here. I have a next video for Teleport Agentless supporting OpenSSH.

[silence]

Ben: 00:22:53.410 Okay, hold on. It looks like this audio is not playing, so let me just change my options here.

Teleport Agentless/OpenSSH

Andrew: 00:23:10.894 Hello, my name is Andrew Fever. I'm a software engineer here at Teleport. And today, I'm going to quickly talk about a new feature coming in Teleport 13: registered OpenSSH nodes. When you register an OpenSSH node, it will appear in your inventory, here in the web UI as well as on tsh, and will allow you to set labels to those nodes. And so you can use role-based access control in them. So here I have already created a node resource file here, and I'm going to register it. I assigned a random UUID for the name to make it unique. I gave it a label here: admin only. So I can show you that RBAC works later. I signed its IP address and hosting. And now, I am going to register this resource with Teleport. All right, it's registered. So now I need to create a host certificate for this SH node that Teleport will trust. I'm going to set the principles for this certificate to be the OpenSSH node, UUID, and IP address. So we can connect using any of those names. And then this will create a host certificate and write it to Ubuntu host, so.

Andrew: 00:24:53.129 All right. And so now I am going to export the OpenSSH CA from this Teleport cluster, which will be needed for the open SH node. You'll see why in a second. And now I will move all these files over to the node. All right. Now let's go over to the node here on the SSH session on the OpenSSH node and move all of these files we just copied over to etc/ssh. And those should be there. All right. I'm going to make sure to set the permissions to be more restrictive so that OpenSSH doesn't complain when its host certificates and CA keys and everything are to open. All right. I'm going to edit sshd config and tell it to trust keys signed by this OpenSSH CA, because when you connect from the web UI TSH through the Teleport proxy to register OpenSSH node, Teleport — or this is telling the open SH node to trust keys from this Teleport cluster. But it won't allow anyone else to connect using random other keys, just through Teleport, which is trusted. And this is just saying that the host certificate that we generated earlier should be used. Else, if we use the default host key, then Teleport won't trust this node.

Andrew: 00:26:39.585 All right. Let's go ahead and restart. `sshd`. And if we go ahead and refresh here, see this node here? And we should be able to connect. There we are. All right. Now, I remember how this has this label here: admin only. Well, let me log out and log in as a different user. This `user user` isn't allowed to access node with the "admin only" label. And as you can see, it doesn't even show up here. Well, let's see what happens if we try to connect to it. `logout` as the admin user. I'm going to log in as `user user`. Now, if we try `tsh ssh spacehook` — well, I can't, though. If we try ssh here, it should fail, yep, because the Teleport `user user` is not allowed to access nodes with the "admin only" label. And if we connect here again, you can see that this session recording will be available.

Kubernetes updates

Ben: 00:28:25.922 Okay, so I'm just going to pause here into the end. And so one thing that is a unique addition of Teleport Agentless and this flow that we just saw is, while Teleport did provide access to OpenSSH in past versions, you wouldn't get the ability to see the servers in the Teleport UI, or get the audit log or session recordings. So this is a much more powerful feature and extension of integrating with OpenSSH on boxes, especially for our customers who don't have the ability to install the Teleport agent on that host themselves. Okay, so chugging along here. On Kubernetes updates, there's not a huge amount of updates I'm going to give you. Primarily in 13, we were focused on performance updates, improving our helm charts. We also added distroless images. We switched package manager to AWS's container image solution. So there's a few options here. We build them all for Linux. ARM. So distroless can be very helpful. And there's other tools that you can use to access those hosts as well. And another addition: if you are using Kubernetes and haven't tried it yet, I'd highly recommend checking out our Teleport Connect Preview for this feature.

Database and application updates

Ben: 00:29:54.821 Database updates. One addition is our RDS setup. I'm actually not going to play this full video, but I'm going to just talk you through it. This RDS setup lets you create the IAM policy that's needed to connect to those instances. And hopefully, if you are new to providing access to those users, this will make your setup and experience much smoother. Another addition is our open search. Let me see this one. OpenSearch is a database forked from AWS for Elasticsearch, and it lets you provide this similar access. This is on our YouTube channel, providing an overview of accessing the open search integration. It's the same setup in which we were using the proxy to go through Teleport to get access to the OpenSearch image. And as with all of our database editions, we have the ability to capture requests and see which commands will run. Application updates. Teleport 13 added the edition of our Okta integration. This is an interesting addition to Teleport Application Access because, as we've added more features, you may have seen we started off with just providing secure access to your Jenkins, new Grafana instances, your very developer-centric tools. Then we added support for cloud APIs such as AWS CLI or GCP. And the Okta integration is the edition with the Teleport 13. And you can provide access to your Okta applications using Teleport. And Mike has this video. It's going to go into some depth about how its integration works and how you can also use Teleport as an access request provider to provide access to those integrations.

Mike: 00:31:56.192 Hi, my name is Mike Wilson. And I'm going to be briefly going over the new Okta integration feature for application access that's introduced as part of Teleport 13. Just to start, I've got kind of a bare Teleport 13 cluster here, where I've just got this singular application demo. This doesn't point to anything in particular. Now, I don't have the new Okta service running on this cluster yet, so I'm going to start it up. To set up the Okta service, you'll need an API endpoint, which is basically the organization URL used to log in, along with an API token, which can be configured as part of the Okta administration panel. So I'm going to go ahead and start up the Okta service, and this will take just a moment. I have this pointed to a dev Okta instance, which doesn't have a whole lot on it. So if I refresh, I have a few applications that were populated from Okta, as well as if I go into access requests and I click on user roles here. Here are some of the user groups that were populated from Okta. In the access request here, we're going to be able to use these to actually request group access. I'll get into that in a moment. To kind of demonstrate this, I'm logged in as a local user, Teleport admin, but to get kind of the full benefit here, let's log in as myself.

Mike: 00:33:52.318 So this user doesn't have any permissions on this instance, or it doesn't have any permission to the Okta applications and Okta groups that were just synchronized. If it did on login, it would be granted access to those. So whatever applications and user groups a user has been given permission to on login to Teleport, those permissions will be reflected within Okta. So going back to my local user that has kind of access to everything, if my Okta user that I just logged in with has access to this Slashdot application, then the Okta service would actually go hit the Okta API and grant the user access to that. However, since we don't have any built-in access here, we're going to request it. So first thing I want to do is just kind of show — here's our Slashdot application, which is just a simple bookmark application. There's no people or groups assigned to it. And I also want to briefly go to the groups here. And we're going to be requesting access to this additional-group. Also, just to demonstrate, I've got what would be the link to our bookmark application if I go ahead and try to request it. I get, "User is not assigned this application."

Mike: 00:35:43.289 Okay, so I'm going to create a new access request here. I'm going to go into the user groups. I'm going to request access to this additional role, and I'm additionally going to go in and request access to our Slashdot application. Okay. So my request is pending. I'll go ahead over to my local user who I've given permissions to go ahead and approve these requests. So I'll approve this request, and this will take just a moment. But if we go into our application now, and check the permissions, I've been assigned. If we go into our groups, for additional-group, you'll see that I've been assigned here as well. Now that I've got this, I can assume the role here just using the regular Teleport UI for role assumption. Head into applications. Launch this. And the bookmark app works as expected and takes me to our Slashdot homepage.

Mike: 00:37:09.440 When the access request expires, this will be cleaned up as well. Just one more thing I forgot to mention: upon synchronization, when the Okta applications and user groups are synchronized to Teleport, there's a notion of Okta import rules, which can be set up by Teleport administrators. And these rules can be used to apply specific labels to applications and user groups. So when I was mentioning before that when a user logs in, they may or may not have access — or when a user logs in, determining access to user groups and applications, this is done through Teleport's regular RBAC, which uses these labels injected by the Okta import rules to make further determination.

Ben: 00:38:09.052 Okay, so that's a great overview from Mike for our Okta integration. Just a note. We use Okta internally, and I think one pain that we go through on a weekly basis is following the principal release privilege, but you always need to get access to an app. And the workflow for access requests with Teleport makes it a very smooth experience. And this feature is in preview, but we're really interested to see how sort of DevOps teams and infrastructure teams will use this together to sort of really limit or also maybe provide a greater access to systems but using access requests. One other feature that was added as part of this was Teleport as an identity provider. Actually, my last webinar was on this topic. And so if you're interested, go into our YouTube; look at our archive. And I went over — how you can use Teleport as a IDP as well.

Windows updates

Ben: 00:39:06.589 Okay, we're almost near the end here. We're coming to Windows updates. Windows has had a range of performance updates for people who haven't looked in a while. In 12, we added non-AD Windows hosts so you don't need to connect to Active Directory. But in Teleport 13, we added this new handy feature: TSH recordings export. And this lets you export the Windows session recordings for offline playback. And this is on a per session recording basis. Come into my cluster. Log in. I can give you sort of a quick overview. Let me log in. So I've logged in on my Windows host. If I play my host and get the [inaudible] — start a session. And I'm going to exit. In my session recordings, you can see how my host here — we did add the ability to speed up the playback. The tsh option is available using the command line tools. So I actually have to come back to my slides.

Breaking changes

Ben: 00:40:32.438 And then, breaking changes. As with all major releases, there's always some breaking changes that I'd recommend you check for upgrading. These are in our change log here: some behavior around joint tokens; CA rotation no longer has type all for advanced users. And so I'd recommend you familiarize yourself with these changes before upgrading. Okay, so thank you for hanging in there. I'm going to do a quick poll to summarize. So I'm going to share the poll and open it up. And so off this overview today, let me know what features you're sort of interested in trying next.

[silence]

Summary

Ben: 00:41:30.706 Okay, looks like we have, "TLS layer 7 routing and automatic agent upgrades." Looks like automatic agent upgrades is the number one. Let me give you a couple of minutes to think. And also, "For the Okta integration, that's great to see." And I'm really interested to see how people use this as well. Okay, and I stop sharing; come back to my slides. So a bit of presentation. Boom. Okay, so the next steps: I would recommend checking out a documentation for people who are really interested in the agent upgrade. There is documentation for this. I might as well just bring it up. Well, actually we launched a new search. Hopefully, we'll deliver the results. "Aren't we having information here on the agent upgrades?" You do have to be using the app for the repo. I don't think I necessarily covered it that strongly. And then also the Teleport kube-agent chart would also upgrade. It's great for Kubernetes users. This document placement page has an overview of what you need to do for the upgrades and an example of manually running updates as well. So for people who are interested, I'd recommend checking that out.

Ben: 00:43:07.281 Come back to my slides. For the people who are new, try Teleport Team. If you just want to try Teleport Assist and you're an Enterprise user, you can just try Teleport Team. You can try it free for 14 days. Download, try Teleport 13. And also, we always appreciate a star on GitHub as well. So now we're sort of at the end of today's presentation. We have 15 minutes left. If anyone has any Q&A questions, please put it in the Q&A box or just in the chat, and I can answer them.

[silence]

Ben: 00:43:52.380 All right, seems like we have a shy crowd today. I'll give it one more minute. People typing up their questions —

[silence]

Ben: 00:44:11.311 — send them in. There's a Q&A box on the right-hand side, also the chat as well. All right. Looks like everyone's — oh, here we are. We have one. So Clinton, we have, "When will Teleport 13 be rolled out to cloud customers?" It is going to be rolled out on, I want to say, June 5th. We actually have an overview in our documentation that says the dates. Yep, June 5th. 13.1. Another additional thing about cloud is we have hosted access request plugins, and so you don't have to host them yourselves. And then, also coming, is advanced audit log. It's going to run out too on that day.

Ben: 00:45:06.852 Okay. Any other questions? All right. I'll give it a couple more minutes. Okay, I think I'm going to call it early. Thank you, everyone, for joining. I know we've had people from France and Texas. I know [it's still late?] in the day. Thank you so much for joining today, and hopefully this was a helpful informative webinar. And if you have any questions, please join our community slack if you haven't already. This is a great place to learn more about the release in real time. It's free to join, and all of our engineering team is there available to answer questions. All right, thank you so much for joining, and I'm going to stop sharing. And yeah, so have a great day.