Secretless, Identity-Based Access

Secretless, Identity-Based Infrastructure Access - overview

Passwords are everywhere. Sometimes they are obvious — hardcoded in the code or laying flat in the file, but other times they take the form of API keys, tokens, cookies, or even second factors. Devs pass them in environment variables, vaults mount them on disk, teams share them over links, and copy them to CI/CD systems and code linters. Eventually, someone leaks, intercepts, or steals them. Because they pose a security risk, there is no other way to say it: passwords in our infrastructure have to go.

In this session, we'll go over passwordless authentication methods that can be used by your organization and how Teleport can help protect your environments using short-lived certificates.

Key topics on Secretless, Identity-Based Infrastructure Access

• Stolen secrets are the #1 cause of breaches, yet secrets are everywhere.
• The solution is to replace secrets with identity-based access.
• Teleport is an industry leader in passwordless and infrastructure-based access.
• Passwordless features are needed because passwords are a pain for users and a liability for both users and service providers.
• The business value of Teleport includes reduced risk, increased productivity, decreased costs and easier onboarding/offboarding.
• Teleport consolidates the four essential infrastructure access capabilities every security-conscious organization needs: connectivity, authentication, authorization and audit.

Expanding your knowledge on Secretless, Identity-Based Infrastructure Access

• Teleport Passwordless
• Teleport Machine ID
• Teleport Server Access
• Teleport Application Access
• Teleport Kubernetes Access
• Teleport Database Access
• Teleport Desktop Access

Learn more about Secretless, Identity-Based Infrastructure Access

• Contribute on GitHub
• Join our Slack community
• Participate in our discussions

Introduction - Secretless, Identity-Based Infrastructure Access

(The transcript of the session)

Michael: 00:00:03.375 All right. We can get started since we're being recorded. So thank you everyone for joining Nick and I today. Really appreciate you taking the time out of your afternoon, morning, evening, wherever you're located around the world to join us around secretless, identity-based infrastructure access today. Today we're going to be walking you through how Teleport enables organizations to decrease risk and improve productivity with the industry's only secretless, identity-based infrastructure access solution. So let's quickly dive in. And before we do, wanted to set an agenda. So first and foremost, my name is Michael Nowin. I'm an account executive here at Teleport, supporting the San Francisco area. Before we go any further, I wanted to let Nick take an opportunity to introduce himself as well.

Nick: 00:00:53.862 Yeah. Thanks, Mike. My name is Nicholas Bergam, and I'm a solutions engineer here at Teleport.

Business case for Teleport

Michael: 00:01:01.000 Awesome. Thanks, Nick. So as a quick agenda, what we have to cover is we wanted to define what the business case for Teleport is. Some of the people on this call might already be customers today and have an idea of how Teleport can help solve some of their key issues, some might not, so we wanted to help make sure that this is defined for everyone on this call. And then, afterwards, Nick will help define how Teleport is doing passwordless authentication today for infrastructure access, and we'll also walk through a demo on the surface login process and how we are accomplishing the passwordless state today. So setting the agenda at a macro level, we wanted to share the newest 2022 Verizon Data Breach investigation report, which found that the use of stolen credentials is the number one cause of data breaches, yet the majority of customers today are still using secrets like usernames and passwords to provide access to critical infrastructure. The 2021 State of Infrastructure Access report shows that static credentials like passwords are used to grant infrastructure access at 70% of organizations. Any secret like a password, SSH key, API token is a liability and needs to be removed, which ultimately prompts a question, "Why?" So there's a couple of problems with the way secrets are brought today. First is theft, because secrets like passwords, tokens, and keys are not tied to an identity. They can be used by anyone once stolen. The Colonial Pipeline hack, for example, was traced to a single stolen password. And it's not just passwords and private keys that are a targeted theft. Hacker groups are even buying browser cookies from employees of tech companies so they can impersonate a user's device without triggering second-factor prompts. Even when secrets are not stolen, they can be used in attacks. Overly permissive access policies also can enable credential misuse by authorized individuals. Again, according to the Horizon Data Breach, 57% of data breaches come from either internal or semi-internal actors such as partners.

Michael: 00:03:04.079 And then, finally, secrets are complex to manage. Because of the clear risks, organizations are even implementing complex systems to manage all of these credentials like secret vaults. Not only are these systems expensive and time-consuming to manage, but they exacerbate the risk of credentials by putting them all on a singular place, literally creating a treasure trove for hackers. And even then, 86% of organizations today report they cannot guarantee ex-employees can no longer access their infrastructure. So I'm curious. This is obviously a rhetorical question, but for those on the call listening and maybe those who will be hearing this on YouTube later, if any of these stats resonate with you and your organizations: how are you working on solving these types of solutions — or creating a solution for this today?

How Teleport defines and does passwordless

Michael: 00:03:49.917 So at Teleport, we believe the solution to this problem of secrets is to replace them with identity-based access. Identity is based on who you are, not what you have. It can't be downloaded, uploaded, or lost. And as a result, identity-based access is immune to human error that results in most breaches. With identity-based access, there's a couple of advantages that has over secrets. We're going to list three that we wanted to cover. First, when you tie authentication for machines and people to identity, there are no credentials for hackers to steal. Unauthorized access is protected using a combination of biometrics for people and security enclaves such as TPMs and HSMs for machines. Once authenticated, a user or machine receives short-lived certificates that automatically expire, so a stolen credential can't be used for days, weeks, months without detection. And finally, identity-based access enables developer workflows because engineers don't have to check out credentials before doing their job or wait to be granted access into a system. So we wanted to also show this slide and give you an idea of the depth and breadth of the customers that are working with Teleport today to help implement identity-based infrastructure access. Teleport is trusted in production by customers who care about moving fast while also maintaining a best-in-class security posture. We have customers ranging from the Fortune 500 all the way to the newest startups looking to adopt a certificate-based approach, and soon, hopefully, our passwordless approach.

Business value of using Teleport

Michael: 00:05:20.923 So what is the business impact of using a platform like Teleport? First, companies that are using Teleport dramatically reduced their risk. On average, according to the IBM Data Breach report, it cost $4.2 million per record. This shouldn't come to a surprise as many on this call. And this can come in forms of lost customers, fines, reputation, no damage, and other various costs. By removing the number one cost of data breaches from your environment — secrets — companies can save millions of dollars in legal fees, potentially [inaudible] damages, by simply using Teleport.

Michael: 00:05:55.050 Second, developers are more productive using Teleport. Checking out keys all day long is simply disruptive to the developer workflow, so is also waiting for access to critical systems. Some estimates put the productivity cost of context switching at 20% of a full-time employee. Teleport customers, on average, with about 100 engineers and a fully loaded cost of $150,000 per year per engineer can save around $3 million by removing context switching due to juggling credentials and waiting for access. Logging in one time in the morning and getting direct access to all the resources a developer needs, allowing them to focus on coding and generating other revenue-specific activity to help your business remain secure and compliant.

Michael: 00:06:35.176 Third, Teleport releases the need for credential vaults, VPNs, legacy PAM solutions, and other network-based solutions that are being pushed, helping deliver concrete savings while also simplifying your tech stack. One customer, in particular, of Worldcoin, saved one week a quarter on server maintenance simply by replacing their homegrown bastion solution with Teleport. And finally, Teleport simplifies developer on and off-boarding. The day a developer starts, they receive access to the infrastructure resources they need to do their job. And the day they leave, all access is fully revoked. There's no more zombie credentials floating around. So previously, we talked at breadth of some of the customers that are using us today. We wanted to focus on one in particular, DoorDash, and how Teleport's helped them impact their bottom line by moving to an identity-based infrastructure access strategy. So DoorDash, for those who aren't familiar, is a leading food service delivery service in the United States. Their market leadership over the past couple of years has gone through extreme hypergrowth, both in the engineering headcount department and their infrastructure footprint. A little bit of background on their environment. It's a heterogeneous cloud environment made up of multiple Linux services, Kubernetes clusters, and databases. And as the company began to scale, the problem they began to notice was that it became a burden to manage access with their own homegrown solution. And like we said, as the company grows, you can only imagine how much more difficult this will become. So when they began looking for a solution, they decided to partner with Teleport to help consolidate access for all engineers and infrastructure resources using a single identity. So in addition to being able to focus on their core business, DoorDash improved security with more granular RBAC, session recordings, developer productivity with SSO integrations, and just-in-time access for their teams.

Teleport consolidating the four essential elements of infrastructure

Michael: 00:08:28.388 So how do we do it? The Teleport Access Platform consolidates the four essential elements of infrastructure access that every security-conscious organization needs: Connectivity, authentication, authorization, and audit. Our platform unifies access policies for engineers and machines using the same identity-based approach. And it's not only more secure — it improves engineering and developer productivity. For the purposes of this webinar, we're mostly concerned with the authentication piece, so we're not going to really be diving into the authorization, the audit, or the connectivity. That being said, if you'd like more information after this webinar on a more holistic overview of Teleport, Nick and I are happy to get you in touch with the correct people within our organization to help provide some sort of demo or walkthrough, answer any questions as needed. Taking it a step further, we wanted to highlight and show, beyond the four pillars, the five different protocols that Teleport currently supports out of the box today. So we bring these capabilities deep to your infrastructure and at the protocol level. So for instance, Server Access down here at the bottom gives you ability — or the visibility — into all SSH sessions down to the kernel level. Teleport Kubernetes Access can help enforce two-factor authentication, kubectl exec commands. Database Access can perform and enforce table-level roles and show every query that hits your Postgres, MySQL, MongoDB, or other various databases that we support. Application Access can provide that VPN-like replacement for internal apps you might not want to expose publicly, such as an AWS Management Console, Grafana, Jenkins, GitLab, and more. And then, Desktop Access gives you a modern, passwordless access for any sort of Windows, servers, desktops with session recordings. So from my perspective, this will be the last slide I share, and then I'll pass it along to Nick, but we always like to end on this and just kind of harp on the fact that Teleport is an open-source product, and we want to share this because we really believe that it speaks to our DNA. When you typically compare or when other companies compare us and Legacy Solutions, they'll notice one key similarity in their approach as opposed to ours. They tackle this secrets problem by creating enterprise solutions that were more or less cumbersome and catered towards checking boxes for either security or compliance and didn't necessarily prioritize the end user. At Teleport, we created a solution from the ground up with the DevOps and engineering SREs in mind, and our founding engineers themselves came from this type of world and have experienced these problems firsthand themselves. We truly believe this is what makes us different and why being open source is so important to us. That being said, as an open-source product, we have a free open-source version that anyone can use at any point in time. To set up, most of the features that we're going to share today are stuff that you can use right out of the box, aside from a few enterprise features. So I'll pause there and pass the presentation over to Nick.

Why passwordless is needed

Nick: 00:11:27.010 All right. I appreciate that, Mike. Yeah. So I'll just go ahead and transition now over to maybe a little bit deeper dive into what the certificate-based access and particularly the password-less access flow looks like, which is a new feature in our latest release of Teleport, so let's get started on that. Essentially, passwordless refers to the authentication without passwords using procedures that are as secure or better than password-based flows. For example, using Biometric proof of identity in conjunction with proof of presence. And usernameless is another term that often is kind of paired with this, which refers to the authentication where the user doesn't have to identify themselves in order for the procedure to start. So it's a common property of passwordless flows, but it's not necessary in order to achieve them. But in the context of this presentation, passwordless is employed to mean both no passwords and also usernameless. And as I mentioned earlier, this is a feature that is available for preview in Teleport 10. Our latest release came out this week, time of as of this recording, so it's going to be Teleport 10.0.2. So feel free to check it out if this is interesting. A question that you might be thinking is: "Why is there a need in the first place to change the way that we've been looking at authentication?" And while passwords are a pain for users, they're also liability for users and service providers, the historical standard for passwords has been based on complexity, length, and uniqueness. So those three have been kind of the trio for the longest time. So how difficult it is to guess a password or how many different character sets it uses such as alphanumerical, capital, lowercase, special characters is what complexity is used to describe. And this, paired together with length, are designed to reduce the likelihood of brute-force attacks. But as these complex words and phrases get longer and longer, it's increasingly difficult to remember for the user. The standard not long ago was 8 characters in length, which increased up to 12, and now 15, and it just keeps getting longer. So the last piece is uniqueness, which means that the passwords should not be used anywhere else for access, and this is also a time-based requirement. So reuse of passwords is also frowned upon in order to have a unique password. This is to limit the damage in the event that a password is compromised, but it makes the ability to remember each of these long complex passwords even more of a challenge. And on top of all that, you could have the most complex, the longest, and the most unique password. But in the end, it's going to have to be rotated on a constant basis. So our approach, as opposed to some of the other ones that are out there, such as vaults, which are those treasure troves that Michael mentioned of credentials just waiting to be found, is more of a password-less methodology which aims to eliminate them for day-to-day authentication while still providing a better usability, i.e. a fingerprint scanner, and better security such as public-key-based authentication.

Certificate-based approach

Nick: 00:15:16.383 Teleport's approach to solving secure authentication and authorization is by issuing these short-lived certificates to each user. The authentication takes place in your current IDP, and Teleport is able to read the groups and attributes assigned to users in your organization, and it uses that information in order to assign unique certificates with strict RBAC controls. So in this way, you not only are able to manage the identity of users in one location, but Teleport automatically adjusts and is able to change the access that's permitted to the users as their roles change within your organization and you update your IDP. Passwordless provides the ability to authenticate without passwords, and that's it. We can end here. But while we're really excited for the potential for this feature here at Teleport, it's important to note that it doesn't necessarily remove them altogether from the system. While it may be possible in the future, the industry is still ways away from being able to achieve this kind of passwordless nirvana, so to speak. So passwords are replaced with public-key-based authentication, which is backed by web authentication. Specifically, we rely on both user verification and user presence to do away with passwords. So for both of these terms, important to kind of maybe dive into what these mean. User presence is the most basic configuration, and it's nothing more than a call that prompts the user to touch the security key or interact with the authenticator in some way. And user verification is another call where the authenticator verifies that this user is authorized to use the authenticator and signals to Teleport whether the user verification was successful. So in a typical multi-factor authentication flow, the user verification is performed via password, and the user presence is performed by entering a one-time password or tapping a hardware key. But in a passwordless flow, checks are likely pushed to a single device such as a hardware key using a pen and a finger tap. And sometimes, they're even reduced to a single gesture depending on what hardware capabilities you have, such as a fingerprint scanner. Pins are essentially a shift from server-side to client-side passwords, and they arguably provide better security because it is harder to remotely compromise a hardware key, but they have a similar user experience. So while we may elect to restrict passwordless use on biometric-capable devices, the reality is that even those devices have pin fallbacks. So pins aren't truly absent in the passwordless system. And the final components to this authentication method is resident keys. So during a regular web authentication flow, no key material is actually kept within the authenticator. In order to make passwords viable, the authenticator needs to actually store the key, which is archived — or which is achieved through the resident key or discoverable credential, a web authentication feature. And creation and management of resident keys is commonly pin-protected and forced by authenticators themselves.

Nick: 00:19:06.344 So I'm kind of a visual person, so I'd like to maybe go through what this authentication looks like visually. But authentication looks pretty similar to our well-known challenge and response protocols with one key exception, and that is that the initial challenge is created without knowledge of the user identity. So because the user is unknown when the challenge is generated, in the first step, the server has no knowledge of the registered devices, meaning that the decision to attempt the passwordless login actually comes from the user. In regard to the next step of authenticator interactions, it's important to note that the user may have multiple credentials attached to Teleport, and authenticators are capable of returning multiple assertions, one for each applicable credential, thus allowing the user to pick the desired credential for login. And finally, in the last step of authentication, we require the web authentication user handle to be informed along with a signed challenge as recommended by the standard. So another way to think of the password-less flow is it allows Teleport to handle the burden that is typically passed on to an IDP for local users. So I know this is a lot of theoretical information that is pretty new for this release. So if there are any kind of questions that come up after going through this, please feel free to drop them in the comment box, and we'll do our best to make it clear in the demo, but happy to answer any questions that you might still have at the end. So adding this feature to your Teleport cluster is incredibly simple. In fact, it's really as easy as adding two to four lines to your configuration file if you already have one designed. In the latest release of Teleport 10, you actually have the ability to enable or disable this feature, and you can also enforce it by default on users if that's what makes sense for your organization. But one thing to note is, for current users, that any cluster in Teleport that currently relies on web authentication is also capable of passwordless.

Demo on cert-based login and passwordless

Nick: 00:21:28.195 So at this time, I'm going to depart away from the slide for a bit, and we're going to be able to see what this all looks like in action. I'm going to go through a little bit with the setup through the web UI of creating different user logins. Prior to that, we're going to go through what it looks like with the standard SSO integration flow being issued certificates. And once we have created a user, we're going to use the web UI to go ahead and set up a YubiKey for passwordless, and then we're going to go ahead and test it as well from the CLI and make sure that there are no loss and capability functions. So with that being said, I'm going to go ahead and transition here. And like I said earlier, if you do have questions that come up, feel free to drop them in the comment box. We're happy to take those. So a typical login looks something like this, where you first enter in the proxy information, which is publicly available. You have local login options, but you also have single sign-on options. I'm going to use GitHub, and since already authenticated, I'm actually dropped into my resources automatically. So if we come over to the web authenticator, you see it's actually pulling all the information from the groups that I'm in within GitHub, and it's giving me different access accordingly. So all this is handled automatically when you update users within the IDP. It's automatically updated within Teleport. And if I wanted to create a new user, all I have to do is come up to the user section over here, go to create new user, and I'm just going to create a new one for myself. And we just assigned certain roles that are predefined. So I want them to be able to have access and request additional access if needed. We save that, and it automatically generates a URL that we can share with that individual. So the time to live on this is set for one hour, and so we can Slack this over to the user or send them an email, but I'm just going to go ahead and copy it and open up a new window. So as a new user, if we just go ahead and paste it in here, we're actually welcomed by Teleport and prompted to get started with the passwordless registration. So I could either do the typical password entry, or there's an option that is new on the bottom right here to go passwordless. And all I have to do is — since I have a YubiKey, I'm going to just name it accordingly and set that as the device name. I'm going to go ahead and make the proper selection, and I am prompted to create a pin, and one more tap in order to gain access. So registration was successful, and I can now continue on to the dashboard without ever having to enter in a password. And as you can see, if I come over to the team and look at the users, this user has those roles that I had predetermined earlier. And I can now access accordingly the resources that are open to those roles. So what this looks like from a command-line-interface perspective is if I exit out of here and just go ahead and open up a terminal window, just execute your simple tsh login, designate the proxy, the user that you're logging in as, and the authenticator. So typically, if you were using an SSL integration like Okta or Microsoft Azure AD, you would also put that here instead. But since we're doing passwordless, that is the new tag to enter into the login. So I just go ahead and hit enter. It's prompting me to hit my security key, enter my pin, and again, complete the login by hitting my security key. And login was successful, authentication.

Nick: 00:25:58.159 So we have some metadata here on my certificate that I was issued such as the time to live on [inaudible]. Again, this is adjustable according to the role that I'm assigned, the timestamp for when the certificate was issued, and then also the different access resources that I have. So that is pretty much it for the demonstration. What I'll do now is I'll just go ahead and transition back over. So essentially, we're able to cover a lot. But in summary, Teleport uses short-lived certificates in order to supply organizations with the easiest and most secure way to access all of your infrastructure. Certificates are a much simpler and more secure method of authorization than the current [inaudible] access security, and the ability to integrate with the current SSO flow makes for a much better user experience as a whole, as we saw, is very simple, very fast. Passwordless is our latest feature that we encourage you to check out and test for yourselves as well. It's available to the open source version, so feel free at the conclusion of this or after watching this video, if you're on YouTube, to take a look at GitHub or join our Slack community where you could actually post questions and learn more from our open source users. And that's about it for our scheduled content. So at this time, I'm going to go ahead and stop sharing, and we'll just go ahead and take a look at some of the comments that are in the Q&A section.

Q&A

Michael: 00:27:43.210 Saw one come in, Nick, just now. They asked, Which authentication devices are supported for passwordless?" Would you be able to expand on that?

Nick: 00:27:55.532 Yeah. Right now, we support YubiKey, Windows Hello, and yeah, some biometrics as well. This is the preview, so it's constantly expanding, but those are the three main capabilities that will be your bread and butter as far as passwordless goes.

Michael: 00:28:19.693 Okay. Another one just came in. Does it make a difference which browser I am using when using passwordless authentication?

Nick: 00:28:41.184 Yes. So the registered devices that you use are registered per browser on Mac, OS. This is due to the Monterey 12, I believe, operating software. So it is browser-specific, and something to also note as you go about registering your devices.

Michael: 00:29:02.010 Cool.

[silence]

Michael: 00:29:19.853 I'm not seeing any more questions coming in, so I'm wondering we'll give anyone another second to see if they want to type anything out. But with that, hopefully, everybody on this call was able to get some type of good information from both Nick and myself. Whether you use Teleport today or are planning on evaluating us in the future, again, we're happy to help answer any questions. We highly, highly encourage you to check out our GitHub, the open source version. Download it. Play around with it. Enjoy the Community Slack channel to obviously answer any questions that you have today. So with that, not seeing any other questions, Nick, anything else you want to add?

Nick: 00:29:58.364 No. I think that's it from my end, so thank you everyone for joining today. I appreciate your time and look forward to seeing you in the open source community.

Michael: 00:30:07.559 Thank you, everyone. Have a good day.

[silence]