The Complete Guide to Teleport 17

The Complete Guide to Teleport 17

Scalable. Secure. Resilient.

Say hello to Teleport 17, the next evolution in secure infrastructure access management. From streamlining complex cloud deployments to delivering global mission-critical resiliency, Teleport 17 is built to handle the demands of modern enterprise environments.

👉 Scalable cloud integration with AWS IAM Security Center
👉 Nested access lists for effortless policy management
👉 Multi-region high availability with 99.99% uptime

Watch this on-demand webinar for more information.

Transcript - The Complete Guide to Teleport 17

Introduction & industry challenges

Ben: Welcome to today's webinar. Today is a pre-recorded webinar, so you're probably playing back this in the Simulive, but I hope that you enjoy it. And hopefully, it's interesting and exciting. Today, I'll be covering all things Teleport 17. We've been focusing a lot on AWS account access at scale and a complete guide and overview of Teleport 17. This webinar is mostly designed for Teleport customers, but if you're also new to Teleport, I'll be giving a short introduction. So to start off with, I always like to open my webinars with some sort of industry challenge and things that we're seeing. And this is from Datadog's State of Security report that long-lived credentials continue to be a major risk. Historically, we've seen this as SSH public/private keys. That's a long-lived credential. But as people move to the cloud, IAM users and passwords, another example of a long-lived credential.

Ben: And what we're seeing is that many organizations still haven't adopted federated authentication. And I'll sort of go into why that's important and what it is. 24% still use IAM. About half the people use federated access. So a lot of people are not leveraging the benefits of federated authentication, which also means you're getting short-lived credentials for your cloud provider. Across platforms, we see the same attack also from Datadog's State of Security, but this is the attack pattern that we see. Someone's credentials get compromised. This could be their username or password, or even advanced persistent threats trying to get the second factor. They get into the systems. They may do something as basic as crypto mining, or they may just steal data on the secondary market. And these are the top patterns that they're seeing. Interestingly enough, the usage of TOR/VPN addresses as a sort of getting into someone's network and using it to perform other malicious activity.

Understanding federated access

Ben: So why don't teams move to federated access? There could be a range of reasons. "Teams could be comfortable with IAM." It's likely where you got started. "It's faster to set up," if you just have one account. Some people might say, "Legacy systems use it." And I would probably debunk this — that it's not true. Almost all legacy systems can be upgraded to some form of federated access. The same with, "Some tools only work with IAM." If you're in AWS, you might be interested in AWS roles anywhere. And this also lets you use IAM outside of AWS. "Our old scripts use hard-coded credentials." And this is the same thing as the legacy systems needed. This is also kind of a very poor practice that older scripts should be moved to short-lived credentials. It's the same thing. "It's too risky to change a working system." But think of all the threats and issues that could happen if your account gets compromised. Some people might also think, "Hey, we're just five people. Federation is overkill for us." I will show you that many of the benefits outweigh it. And even small organizations can have huge footprints; like WhatsApp, before they got acquired, were 20 people but running millions of users through their system. Even if your team is small, the benefits of federation outweigh the overhead of running it. And yeah, same thing. We're too small for federation.

Webinar agenda

Ben: And so for today's webinar, I'm going to go into a quick introduction of Teleport. Going to be talking about how Teleport has made it easier for teams to use federation with just-in-time federated access for AWS accounts. Then I'm going to be covering the three main products in Teleport: Access, Identity, and Policy. And lastly, some platform updates. I will also discuss some breaking changes, things you want to do if you're upgrading or if you're a Teleport cloud user. Since this is a pre-recorded webinar, there'll be no live Q&A, but you can always ask questions of us in our community Slack.

Teleport Platform overview

Ben: So the Teleport Access Platform, like I mentioned, is comprised of three products: Identity, Policy, and Access. Access is all about removing long-lived secrets and moving to more ephemeral privileges in your infrastructure. Also, moving to a more zero-trust networking approach. That you're not just using a VPN and it's a boundary. And then also tying all of the cryptographic identity down into users and machines and workloads so you know exactly which service and which users are performing which actions. For policy, this is all about governance and understanding the visibility of who has access to what in your infrastructure. We have a few additions that I'll be covering today, such as our new Crown Jewels feature and also our policy — not policy as code that was released at Teleport Connect, but SSH key scanning. For identity, this is all around moving to zero standing privilege, all about access requests, reviews, and other features which can provide Defense in Depth, such as Device Trust and Identity Locking.

Ben: I'm not going to go super deep into this diagram, but this is an overview for the infrastructure. You have your users, the services, on one end, all going through Teleport, communicating to our sort of core access platform and our Zero Trust Access Plane. Under the hood, there is an X.509 certificate authority with different CAs. We've actually upgraded the algorithms in Teleport 17. I'll be diving into that. And then it provides access to a range of resources. So we believe by using Teleport to consolidate access, you get a lot of benefits in your organization. Today, I'll be covering a lot on AWS, but we have solid support for all clouds, and we have a lot of customers, both on-premise and using bare metal.

What could federated access look like?

Ben: So what can federated access look like? I opened with this sort of a question around federation. And if you're using AWS federated access, as I go through the flow of this, might be more familiar to you. But what it comes down to is you often have groups within your IDP. So in your [inaudible] or your HR systems, as an employee comes in, they get a group within your system that might map to your Okta. We have added Teleport Now, which can provide a broker to AWS accounts. And then it can be the broker to say, "Hey, which roles and which accounts can you get access to?" One of the benefits of a system like this is — I'm showing the SRE group here. But once a year, finance might need to log into all of your AWS accounts and update tax information. You don't want to be giving Bob in finance long-lived access to all of your AWS accounts in a sensitive data position because if he was to get compromised, there could be a much larger lateral movement into your account. And almost the same for the SRE group of all of these three systems — do you need long-lived access to your production system, or do you only need it once a month when you're in your report or not at all? And so, by separating all of the concerns from your IDP to your AWS account, you get all of these extra benefits.

AWS IAM Identity Center Integration

Ben: So now I'm going to dive into our AWS IAM Identity Center integration. A bit of background. AWS IAM Identity Center. It's a bit of a mouthful, but it's a free offering from AWS that makes it much easier to manage multiple AWS accounts and AWS organizations. If you are not already thinking about multiple AWS accounts within your organization, I would highly recommend thinking about it. They're kind of free to set up multiple AWS accounts and multiple orgs. Some benefits can be by using multiple AWS accounts; you get separation of concerns from a security perspective. It's a fully isolated environment. But there's also cost concerns. So if you have different groups, you can more easily divide it. It makes it more easy to have playgrounds in which you could use AWS New. Can remove it at the end of the year and not worry about touching any critical systems. Our integration makes it much easier to provision users and groups within AWS Identity Center and then also provide just-in-time access. And you can also leverage your IDP. So if I go back to my diagram here, you may say, hey, "Why not just connect Okta to AWS Identity Center?" One of the reasons for this is you often want to group—Okta may be controlled by IT. Teleport can be controlled by your security or your platform team. And you also limit the scope of who has access to what in your infrastructure. And lastly, you can perform Just-in-Time Access Requests as well to get those roles.

Ben: So I'm going to do a demo here. So if I come in — let me log out. If I log in. Here, I'm using GitHub as my identity provider. But we can use Entra, Okta. All is supported. I log in. You actually see here I have a Device Trust flow, and now I have this locked. So one other benefit is I can't enforce Device Trust on my GitHub, but by using Teleport, I can say, "Hey, I've enrolled my device in Device Trust." So only this machine for some of these roles can get access to resources. So if I search, we saw it here. But for AWS, we have a range of integrations here. So we had previously supported AWS, and people might be familiar if you're an existing customer, in which you would map an AWS account and a role, and this would provide access to that specific role.

Ben: Our AWS Identity Center Integration sort of goes one step further and makes it easier to get access to multiple accounts and multiple users. So here you see this would be a very familiar flow. I have mapped my users and groups in AWS to get access to these resources. So if I log into this account as my support user, you can see I'm a support user, and I am now federated. And so we have this federated information. Another benefit of using federated access is there's more CloudTrail events. There's more information, which you don't get if you're using a root user or IAM user. Same, you can also get access to access keys.

Access Lists & Nested Groups

Ben: The integration is primarily managed through Access Lists. There's groups that you add which have `on-aws` that denote if they can get access to. And then this makes it easy to add and remove and then also audit. If I come in, I can show you what one of these look like. That you have the account assignment, and then you have the permission sets that you provide access to. So that is an overview of our AWS IAM Identity Center integration. Next up, I think I just touched on this briefly, is our Access Lists. This is the ability to create multiple groups. For example, I have company-wide access for all my users. And then I also have a Nested Access List. So I can add my engineering team, which might have more privileges than my company-wide access. And you can nest this up to 10 times. And this makes it very easy if you're taking your IDP, your Okta, your Entra, and you have these logical groups of nested access, you can map the same thing. And this is also supported with our Okta dashboard as well. So yeah, like I mentioned, we can go up to 10 levels deep. And this would be a common pattern. So you'd have your top level, your engineering department, your front end. This makes it easy to have logical groups of your organization mapping to Teleport roles within them.

Datadog Integration for Access Requests

Ben: Another feature we have. So as people move to Access Requests, this is the ability to make short-lived access to resources. You see now we've integrated it within our UI. My specific user isn't making an access request, but for a user that was limited, this would be marked out so they can make an access request. It would go into a list of access requests. I don't have any open right now. But you also need to have a way to alert people quickly that they need to approve or deny the access request. And for this, we've added a couple more integrations. We've added our Datadog integration. Datadog has an incident response feature, same as PagerDuty, and we've now added this into Teleport as a one-click integration. So Datadog here, and these are some of the other ones that we also support. How to use it? It's relatively simple to check out documentation, but you just sort of create an API key, you create a service account, and then you get access, and you get those alerts in your Datadog.

Application Access & Multi-Domain Support

Ben: So moving on to one of our next products, we have Teleport Access. You may have seen here, for people who are long-term Teleport users, we now have Access, Identity, and Policy. These are our three main products, and it makes it easier to understand all three of them. For example, access is all around our users, groups, and roles. And then we have our resources here. One addition that I'm going to dive into for Teleport Access is our new multi-domain support for web applications. It's a bit of a mouthful, but this allows us to support the Backend for frontend (BFF) pattern, which is a way in which an app can require access to API services using cores and pre-flight headers. This was a very heavily requested feature, and I'm really glad that we have built it. I think the best way to show this is to demo it. I have my Backend for frontend app. So I have these two APIs, and then I have my frontend. If I launch this, you'll see it kind of goes through, and now it's starting to use different APIs. And so here my Analytics API is at [email protected], which I can load directly. But prior to this, CORS wasn't set up, so it wouldn't load. So now we fully support the Backend for frontend pattern, which makes it much easier to sort of build and prototype and support this setup.

Ben: If you want to try it, I have an example. My code that I've shown here is on GitHub, which makes it easy to test. It's primarily a Flask and a React application. Just a note here — since I'm going through this, when you set CORS, you also need to set support's credentials as `True` for it to pass down. And in Teleport itself, there's the new addition of required apps, which means that it prefetches these two apps before it starts. And then you can also set CORS on the app itself and what methods you allow or which headers you send. And yeah, Pam's reminding me here this was a very heavily requested feature. Issue 17588. There's a lot of activity here. Lots of thumbs up. This is also a good plug. Teleport is an open source, open core company. If you have an issue or a ticket, you can just come to us and create an issue. And so I'm glad that we have resolved this, and I'm excited to see how you adopt it.

Machine ID & Workload Identity

Ben: Machine ID and Workload ID. This is all about providing access to machines and workloads to provide access. A few things that we've added. One is TPM support. This is a new join method that allows you to enroll machines and bots using the identity of the TPM. If I come to my join token here, you'll see I have this TPM join token. And this makes it much easier for bare metal users to not worry about moving short-lived secrets to different hosts to enrollment and just using the certificate of the TPM itself. We have also added support for JWT SVIDs, which makes it much easier to enable machine-to-machine authentication across clouds. And then SPIFFE federation as well for Workload ID to make it easier to have trust identities and support other SPIFFE-compatible integrations. There's a couple of other webinars on SPIFFE and Workload ID. If you're sort of new to this, I'd highly recommend starting there to learn more.

Modern signature algorithms

Ben: So our platform. The platform itself has had a few updates. I think the key thing I want to cover today is our update to our signature algorithms. We have now moved to RSA 2048 and ED 25519 by default. My new cluster — I started so I can show you the CAs. And if you use, yeah, `tctl status`— it's an easy way to figure out. So you can see all of the algorithms that we have. The host CA differs. For example, for IDP we use RSA 2048. And for our host and user CAs, we use EDE 25519. But we also support a range of other algorithms. And I think one nice thing I like about this feature is we don't make you pick the specific algorithms. Instead, we let you pick a suite. And so you can have a legacy suite, a modern suite, a FIPS suite, and a HSM suite. And the engineer on this has put a lot of work in to make sure that we have great compatibility upon all of those. The main benefit is it's both faster and more secure. Faster, meaning if you have a very large cluster, there'll be some performance overhead on the auth server. And we also provide some compatibility with systems which don't have RSA 2048 yet.

Ben: For FIPS, we still distribute the FIPS binary. As they use a specific cryptographic binary, this will be specific for people who are going through FedRAMP. And then we'll update the algorithm as well to FIPS v1. When you're updating, root/leaf order shouldn't matter. They can still trust each other using different suites as well, which is a nice addition. Technical limitation — it is a breaking change. And if you are upgrading from older versions to newer versions, as we always recommend, check out our upgrading guide. But you must do a CA rotation if you want to change the algorithm. But one nice thing is you can do it one at a time. So you can just rotate one of your CAs, make sure that it works, and then sort of update everything as it goes. And there's a range of tools that make it easier to upgrade your CA, especially in larger clusters, to make sure everything gets updated. And yeah, check out our docs here on CA rotation. There's a range of different options that you can do to initiate it. Yeah, you can do a semi-automatic rotation as well. And then we also have options to roll back a rotation in case anything was to go wrong. So everything is there from an operator's perspective.

The Crown Jewels feature

Ben: Okay. Our last product I'm going to cover will be Teleport Policy. And I want to dive into the Crown Jewels, not the king's crown jewels. Crown Jewels are critical assets in your infrastructure, which you see as important. It can be a resource, a database, a user, a device. And when any activity happens upon that thing that you deem a Crown Jewel, we will more closely monitor it and create audit events. Okay. So I think this is a good time to just show a demo of it. So if I come down to Teleport Policy here, I have a few Crown Jewel matches here. Let's pick my `topsecret` db. So here I have a query, which is matching on any alias of the name `topsecret`, and I have my database. If I come into my Crown Jewel matcher here, see some of my changes. You can see as a result of myself changing some of my group membership, it highlighted that I changed this group membership, and now I have access to the top-secret database. I was doing a lot of change before this webinar, and so that's kind of why it's a little noisy. But this is a very helpful tool to see — identify changes — what's happening within your infrastructure. Everything else also sends as an audit event, so you can send this off into your SIEM. We also have this nice addition now, so you can view it in policy, see what change happened to get a better understanding about what happened to the change.

SSH Key Scanning

Ben: Okay. So I've done the demo. Another addition that we worked on was this release. We have added support for SSH Key Scanning. One thing that we've noticed with different teams is that they have adopted Teleport, but they've still noticed that their teams have put SSH, sort of, backdoors effectively into their system. While there are networking ways in which you could sort of block them and only require Teleport in, most teams don't necessarily want to lock down their systems 100%. And some teams do want an SSH key, but they want to know which SSH key is on it. So we've now added support to add SSH keys and scan for sort of SSH keys in your infrastructure and potentially highlight hidden access patterns.

Ben: So if I come back into my user here, you can see here within my Teleport Policy — oh, actually, I just updated my user on this host. So I think I won't be able to show my full SSH Key Scanning demos. But if I come back here, you can see that I have my machine, which is matched to my one through Device Trust, and it's detected a private key. On the host, it runs the scanning every 10 minutes. And what's interesting in this is it can find things such as all authorized keys. And I found it interesting that it found some [inaudible] keys which were left after building sort of my [inaudible]. And it can detect other keys that are left and have access patterns. And so if you're doing a quarterly review, it's a good place to come in, say, "Hey, why do we have 25 authorized keys on this box? What's their responsibility, and what's their job, and why are they on the box?"

Ben: There's a few limitations or features. We know we only send SSH fingerprints on the host. Device Trust is required to scan SSH keys on the machine. You can run this using a `tsh` key scan tool, but we would recommend using an MDM, sort of a Jamf, running this sort of daily to figure out which keys. And you can pick the directories of where you want to scan. For example, you might want to scan the downloads folder to make sure, "Hey, are people creating EC2 hosts and downloading the private key instead of using their existing one?" And also, the scanning doesn't scan on the hosts. It only scans for authorized keys on the hosts. Our team, I'm Director of Products, so we are looking for teams concerned about SSH backdoors. If you're interested in this feature, please reach out. My email is [email protected].

Entra and GitLab integrations

Ben: Two other integrations for Access Graph that we've added have been GitLab and Microsoft Entra. GitLab is all about understanding who has access to which repositories and projects and what the permissions are. And Entra is the same thing about understanding your access policies, groups, and users' membership. This can also be very helpful to going back to our initial question about federated access. And once it's added, here's a screenshot of my GitLab setup; we put in other information. So we know that my user didn't have two-factor. What are the permissions that I have on my user? And you can map this to that repo. If you're interested to learn more about policy, I have also recently created a policy lab, which is available and free to try. This has a few resources in Teleport Policy. Just go to goteleport.com/labs to try that out.

Breaking changes

Ben: Okay. Coming up here to Breaking Changes. As with all our releases, we post our improvements and breaking changes on our GitHub release page. First one, always use the same client as the cluster version. With our signature algorithms, especially using `tctl`, it's a little bit more finicky between 16 and 17. So just make sure if you have two clusters that you are using the right client against the right cluster. This webinar should be out the same time as Teleport Cloud is upgraded. I believe that's December 15th, depending upon your release schedule. So you would want to make sure that all of your team also have updated clients as well. macOS assets have been updated. We have now packaged and unified our Teleport and `tsh`, which also supports Touch ID now, so there's no separate `tsh.pkg`. We've enforced stricter requirements on SSH hostnames. I had a case of something that wasn't fitting these requirements. It will still show up in Teleport, but I had to update my name for it to fully show up. It was showing the Teleport internal ID. And we have a few security updates. So for a while, we've been trained to remove passwords and users without authentication, like a second authentication method. So for Teleport 16, multi-factor authentication is required for local users. And this release is the last time that we allow one-time codes for per-session MFA, moving to a hardware key approach, which is much better.

Next steps

Ben: So, any next steps? So if you are new to Teleport and you want to learn more, you want to try it out, check out the lab that I have, or you can just sign up for a 14-day Enterprise trial. If you have any questions, join our Slack channel. Upgrade your cluster to Teleport 17. This is a legacy from last time. And yeah, Teleport Cloud trials should be — an account should be — updated by December 15th. So if you have any questions, like I said before, please join us at goteleport.com/slack. This is our community Slack. There's a whole community of people and Teleport employees who are happy to answer any of your questions. Okay. That brings me to the end of today's webinar. Thank you for joining, and thank you for being a Teleport user or customer or showing interest, and have a great day.