Why You Need to Ditch Passwords, Private Keys, and All Other Forms of Secrets

Why You Need to Ditch Passwords, Private Keys, and All Other Forms of Secrets - overview

Despite the steady drumbeat of news stories on security breaches caused by compromised credentials, 70% of teams still use secrets such as private keys or passwords to grant infrastructure access. In this webinar, we’ll cover why all forms of secrets are bad for you and your business, and why MFA is not good enough. We'll cover how the adoption of Passwordless Authentication and related hardware technologies like TPMs and HSMs fix a slew of problems, including making phishing attacks a thing of the past.

Infrastructure today is protected by secrets like passwords, private SSH keys, API tokens and cookies. They are all just secrets, and all forms of secrets are vulnerable to human error. Secrets can be lost, stolen, accidentally leaked or even traded on dark web marketplaces. Most engineers know this, which is why every SSH tutorial begins with instructions for disabling passwords and enabling private/public key pairs. But a private key is just another form of a secret. Encrypting secrets also does not help — it simply converts one form of secret into another. That’s why Passwordless is the answer.

That’s also why we’re excited to introduce you to how we’ve helped solve this problem with open source — through Machine ID and Passwordless Access in Teleport 10. Watch this webinar to learn how to:

• Move away from storing identity only as a password-protected electronic record
• Replace any static credential with more secure biometrics for people and hardware-protected enclaves for machines
• Reduce the probability of human error with private keys, API keys, etc.
• Embrace passwordless infrastructure to enable your organization to take a step forward in cybersecurity and protect your most valuable assets

Key topics on Why You Need to Ditch Passwords, Private Keys, and All Other Forms of Secrets

• There is always a probability of humans making mistakes. The surface area of your exposure to human errors is the fundamental component of infrastructure security.
• As the scale of computing grows, so does its complexity, often resulting in access silos.
• To protect against human mistakes, you have to move away from secrets completely. The mere presence of a secret anywhere in your infrastructure is a vulnerability.
• A very important component to secretless and passwordless authentication is ease of use.
• Teleport uses a secretless security model that uses Zero Trust architecture to prevent attackers from pivoting to adjacent systems even if they somehow establish a foothold.
• Teleport delivers identity-based access across a range of protocols and at the protocol level. It provides secure access to Linux and Windows servers, database clusters, Kubernetes clusters and web applications.

Expanding your knowledge on Why You Need to Ditch Passwords, Private Keys, and All Other Forms of Secrets

• Teleport Passwordless
• Teleport Machine ID
• Teleport Server Access
• Teleport Application Access
• Teleport Kubernetes Access Guide
• Teleport Database Access
• Teleport Connect

Learn more about Why You Need to Ditch Passwords, Private Keys, and All Other Forms of Secrets

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

Introduction - Why You Need to Ditch Passwords, Private Keys, and All Other Forms of Secrets

(The transcript of the session)

Ev: 00:00:00.322 Hello, again, and thank you for joining us today. My name is Ev Kontsevoy, and I'm CEO here at Teleport. I am also joined today by Ben Arent, our Developer Relations Manager. Ben is expert on all things security and all things community, here at Teleport. We'll be sharing a technical overview, and we will do a quick demo a little bit later. But if you're here today, my guess is that you would like to learn more about the newest release of Teleport, the Teleport 10. Specifically, you must be curious about the passwordless authentication and why this is so important. In today's webinar, we'll be talking about the risks associated with granting infrastructure access based on a secret. We'll see how passwords, private keys, API keys, they're basically all the same. It's just all secrets, and we'll explain why they don't really work that well. We also explain why passwordless access is strictly better, and we'll finally see how it works with a quick demo. So let's get started. Can we have the next slide?

Anatomy of an attack

Ev: 00:01:10.640 So first, I want to talk about what actually happens when your infrastructure is attacked because most infrastructure attacks follow exactly the same pattern. It all begins with humans making mistakes, opening the wrong emails with malicious attachments, the famous sticky notes with passwords and monitors. You could lose your laptop on a subway station or something. That is something that's unavoidable. Humans are reliably going to be humans, and that is how all attacks begin. This is why hackers never really break through crypto. They very rarely use zero-day exploits. They simply log in because they exploit human behavior. And the industry response to that is, what, we do training, we implement processes, we rely on bureaucracy, we implement monitoring. But at the end of the day, there is always a probability of some human making a mistake. So I think in terms of your exposure area, like the surface area of your exposure to human errors, that is the fundamental component of infrastructure security. Okay, so what happens next? Once an attacker exploits human error, that usually means that some kind of secret is being leaked. So secrets and human errors are uniquely connected because human errors are unavoidable and secrets leaking, that is the consequence of humans making a mistake.

Ev: 00:02:45.985 So then traditionally, the industry response has been secrets management, password rotation, processes, encryption, secure vaults. So we've been trying to reduce the number of secrets that are exposed to humans and therefore exposed to human errors. The next thing that usually happens during the attack once the attacker exploits human error, gets the leaked secret — maybe it is a browser cookie, for example, or a session token or something, or a private key. So then they establish a foothold. Now they have a piece of your infrastructure. It could be engineers' laptop, actually. And from there they try to pivot to adjacent systems. Traditionally, industry response to that was endpoint security and threat intelligence. So you'd go and purchase solutions that try to detect if an attacker is present on a vulnerable laptop, or lucky, you would have systems that try to detect the presence of someone outside of your organization within your network. This is how we've been dealing with infrastructure security traditionally.

Secrets don’t scale

Ev: 00:03:56.846 Next slide, please. And here is why this solution is no longer working as well as it used to, many years ago, because today, we are running compute on massively elastic and scalable cloud-native environments. So therefore the scale of your computing is growing, but the complexity of it is growing as well. So we're developing these access silos now. Consider, for example, maybe you have a MySQL database, just an example, MySQL database. Inside of the database you have a table with some very sensitive data, maybe credit card numbers, maybe medical records. So now consider how many ways are there to steal that data? How many doors are there that you need to protect? Well, you could access that data using database native protocol. It just connect to MySQL socket with username and password, and you can do like a select query, and you can read the data. So that's one way. So you need to go and protect that. So you need to make sure the database has authentication, encryption, authorization, all of this is set up.

Ev: 00:05:08.125 The second way to do it through SSH. You can actually bypass database security. You can SSH into the box, you do SQL dump, then you'll CP the file out so you get access to exact same data. But if you're using Kubernetes — you see I'm talking about complexity increasing because Kubernetes is a relatively new kid on the block. So then you could get into a Kubernetes pod using kubectl, and then you basically repeat the same thing you've done with SSH. That's another way. But also, MySQL has a Web UI, so there are all these kind of Web UIs that organizations use to manage their databases or to see how they're doing. So an attacker can possibly go through a Web UI, can exploit human error there. But if you're running on AWS, for example, you could do the same thing via AWS console, or you could use command line and AWS key to get into that environment. And you could do like a snapshot of EBS volume and get the same data that way.

Ev: 00:06:04.598 And it doesn't stop there. So if you have a CI/CD pipeline or if you have some kind of infrastructure automation script, something is doing backups of that database or does deployments, and that thing probably also has credentials to access this database. So you can go and attack maybe something like Jenkins, and from Jenkins, you can get into database. You see how many different ways are there to access that data. And I can actually keep going simply, because complexity is always increasing. I'm pretty sure, like in your particular case on your infrastructure, there could be other ways to access this, so. And every single one of these entry points has some kind of secret that is vulnerable to human error. Browser cookies can be used to attack two of these doors. So that is what's happening today. This is what you're dealing with. This is what you're trying to protect by buying solutions from all kinds of different vendors.

Remove secrets as food for human errors

Ev: 00:07:00.236 Next slide, please. So what are we proposing? Well, what we're proposing is not something that actually is a Teleport invention. This is what hyper scalers have been using actually for years now. So the companies like Facebook and Google and Rackspace, where we came from, the realization is that you cannot bring down probability of human error to zero. It doesn't matter how smart your engineers are — humans are kind of vulnerable to be making mistakes. Therefore, to protect against that, you have to move away from secrets completely. So we believe that just the presence of a secret anywhere in your infrastructure is a vulnerability. For this reason, Teleport, actually, from the beginning has been designed using what we call a secretless security model. So even before we get into passwordless authentication, it's worth repeating that Teleport, itself, doesn't really use any secrets under the hood.

Ev: 00:08:01.589 So Teleport agents, the hosts they run on, they don't really store any private keys on them. There is nothing like that. So when humans authenticate into Teleport systems, starting in Teleport 10, they use combination of biometric authentication, which is like your fingerprint, for example, plus a TPM on your machine. So which means that you have to be yourself, you need to have your own thumb with you, but you also have to have a device that's been registered with your company. You see, there is nothing to steal there. Even if an attacker somehow puts malicious code onto that laptop, there is no kind of credential that they can upload to their control center. And we do the same thing on the server side. So on the server side, identity is implemented using HSM. HSM, by the way, is a hardware security module. It gives a unique ID to each individual machine and that is what is being used for authenticating hardware.

The balance between security and productivity

Ev: 00:08:59.618 Next slide, please. There is another very important component to secretless and passwordless authentication, and that's ease of use. So every organization, including yours, always struggles with this balance between security and productivity. Actually, you could make your infrastructure extremely secure by not giving anyone access to it, but then nothing could get done. In most organizations, there are always these kind of two groups of people. You have engineers, they need to fix bugs, they need to run deployments, they need to launch new features, troubleshoot performance. They embrace change. And then you have the other group, the group that cares about security and compliance. From their perspective, it actually would be much better if everything is frozen in time. So there is tension between these two groups. And what happens sometimes is that organizations, they would adopt extremely strict and extremely inconvenient security methods, and that makes engineers unproductive. And what smart engineers do — and it's actually quite common in the industry — they just introduce their own ways of accessing infrastructure. So it's really common to be talking to a DevOps team. At some organizations, they will say, "Yeah, yeah, we purchased vendor solution X, but we actually don't use it because it's inconvenient."

Ev: 00:10:27.426 Next slide, please. So this security theater situation, this is what it leads to. So last year, the infrastructure access report came out by Schlesinger Group, so it's relatively recent. And they said that 53% of organizations have implemented new security methods. So they bought solutions, but those solutions, they failed to be adopted by employees, by their engineering teams. So what does it actually mean? It means that you have a multi-tenant building — that's your infrastructure — and you put a door, a really nice secure door in front, and then 53% of tenants said that they are not using it. So what are they using? Well, they're using something else. Effectively, they're using backdoors. Next slide, please. So therefore, the conclusion is that to be secure, access must be convenient. And passwordless authentication is actually one of these rare examples where you get additional security, but you also get ease of use, which is really, really important. So your infrastructure is secure only if your engineers actually love their access tools.

Identity-based infrastructure access

Ev: 00:11:42.483 Next slide. So let me walk you then how we address the initial sequence of events that lead to an attack. So, first of all, we recognize that secret-related human errors are unavoidable. Humans will always make mistakes, but you can bring down the cost of these mistakes to zero by getting rid of all passwords and all secrets. For this reason, Teleport uses a secretless security model. So we don't rely on passwords, no API keys, no private keys, no secrets of any kind. Then how do we prevent attackers from pivoting to adjacent systems even if they somehow establish a foothold, maybe using some side-channel attack using another vulnerable software? Well, to prevent that, we use Zero Trust architecture, like hosts that Teleport is running on — they do not listen on the network.

Ev: 00:12:39.053 How do we deal with these access silos that create operational overhead, and it's hard to deal with them because of talent shortage? Well, because Teleport gives you access to all of these protocols in one place. So in my example, with that MySQL table, that MySQL table would have been protected across all of these different ways of accessing it with Teleport because Teleport does support native database protocol, SSH, Kubernetes, AWS, all of that will be protected by the same authentication, same authorization, and same audit log. And finally, to avoid the security fear, secretless capabilities, this is why engineers love using Teleport, simply because it's convenient. So now, hopefully, I explained to you the rationale why we built it this way. Now, why don't we pass it on to you, Ben, and do a quick demo.

Demo time

State of infrastructure access (before Teleport)

Ben: 00:13:32.619 Thank you, Ev. Hi, everyone. My name is Ben Arent. I'm a Developer Relations Manager here at Teleport. And sort of to get started, I just want to set the scene, and I think Ev has done a great job of sort of setting the scene of some of the current problems. And it often starts as you have one AWS account, you have a small team, your team starts to grow, you have more people joining your organization. Next up, you sort of employ best practices, such as deploying a second AWS account for your production and staging environment. Then you suddenly have these credentials and secrets. You might have SSH config across accounts. MySQL passwords, Redis passwords. Then you go a bit more, you have more teams, more organizations. You build different tribes, the SRE, the developers, everyone needs to get access, but they're all getting access three different ways. And then last up, you add multiple cloud platforms and you add more users. It sort of goes on and on, you have AWS IAM, you have control panels, AWS kubeconfigs you have to worry about. And anyone who's kind of like being in the weeds, you know that there's so many different secrets here and different possibilities. And sort of what this looks like after Teleport, it's the same deployment, but instead of having all of these different silos and cloud providers that you go through, you go through one central place.

State of infrastructure access (after Teleport)

Ben: 00:14:57.902 And I think one thing I want to just hone on in this slide is all infrastructure is accessed via one single login, which is very important for user experience, getting out of the way. But one of the most important parts is all access is linked specifically to their identity. So if you would have people logging into it as EC2 user, there's not much visibility into which person or which machine access which machines or Kubernetes clusters at what time. And so that's one of the core parts of Teleport is linking to the identity. And we're going to sort of dive a bit more into how to get access using passwordless. So this brings us to the Teleport Access Platform. The access platform consolidates what we see as the four main essential access capabilities. The connection, as we saw accessing multiple cloud providers, the authentication which we'll dive into today. We're going to focus on passwordless authentication, but also through SSO identity providers, authorizing making sure that once people are in the system, they can have access to the right resources, or they can make access requests to get access to the systems they need. And lastly, the auditing capabilities to figure out which users in which system are doing what actions, when.

Infrastructure access using Teleport

Ben: 00:16:19.084 And as Ev mentioned, Teleport delivers identity-based access across a range of protocols and at the protocol level. We have access to Linux and Windows servers, database clusters, Kubernetes clusters, and internal web applications. There's sort of a lot here, and I think one of the best ways I'm going to show you is sort of a quick developer example. So I'm going to log in to just get started in my cluster here, and I've actually alias my login. And you can see here it's trying to authenticate me with Touch ID. Login. Okay, so I've now logged into my Teleport cluster. One of the first things I'm going to do is to show you the ease of the inventory. Here, I have an inventory of a range of hosts that I have access to. And so what I can do is — I logged in, and then I'm just going to SSH into one of my boxes and ebpf host. And within sort of two commands, I now have access to this host, and so I can go about my actions. Let's say I want to exit. I exit this host.

Ben: 00:17:36.368 I can do exactly the same thing for Kubernetes. So as a developer, I don't have to jump through all these other tools, and my access is very easy to log in. So let's log into my Kubernetes cluster. Let's run a kubectl exec. And within sort of a couple of commands, I now have access to my Kubernetes cluster. And so for your team to shove all this out, the developer experience is great, super smooth in the command line. But for any administrators — I'm going to log into Teleport here — this is the administrative Web UI which developers also have access to. And I'm going to dive into this a bit more in a second, but let me come to the audit log, the session recordings. You can see that I have these two session recordings that we had, which goes to talking about the auditing of Teleport. And we can play back these recordings.

Ben: 00:18:38.858 And one thing that's great about Teleport, these are actually full recordings, so you can copy-paste details and have that visibility into who's accessing your infrastructure. And the same is true for Kubernetes. We also have access to Windows hosts, which is another passwordless system that we provide access to. You have the same access to your database tooling, your Kubernetes clusters, and your applications all within one central place. And so if you go back to that diagram that I showed earlier in which you'd have multiple silos of infrastructure access, you don't know where to get the secrets or access, Teleport consolidates that all into the access platform. And behind all of this is backed by short-lived credentials.

Ben: 00:19:25.661 So I'm going to go onto my slides. And one thing that we're focusing on today is the access of embracing passwordless infrastructure. And we're going to touch on two parts. We're going to touch on passwordless for humans and passwordless for machines. Let's talk first about the authentication for humans. I think one thing that you might have seen already — I already showed you the passwordless login, and I think one of my favorite things about passwordless is it works best when it sort of gets out of the way. So, like, your iPhone using Face ID is a perfect example of passwordless. You don't even think about logging into your iPhone with your Face, it just works. But in the background, it's using passwordless authentication. And what has been lacking in the state of infrastructure access is it's been difficult to get that same user experience to get access into those systems.

How passwordless works

Ben: 00:20:20.038 So passwordless is based on a WebAuthn and a couple of open standards. And there's a great blog post here on our Teleport blog from the developer who built this, how passwordless works. And if you're really interested in going sort of super-deep in how passwordless works and how we implemented it, I'd recommend checking out this. But it's built upon two open standards, WebAuthn and CTAP, which is the Client to Authenticator Protocol. Some interesting things of note, you might see me using a Pin or a biometric YubiKey. The pin, while it looks similar to a secret. It is never left from the device. And I think that's why it's important that you have something that you have which would be, let's say, the YubiKey or your secure enclave and something that you possess like biometrics, such as your fingerprint or a really long pin.

Ben: 00:21:15.448 Okay, so moving on, I think we sort of touched a little bit on Teleport works both in the Web UI and the CLI. One thing that is pretty novel is most of the WebAuthn standards have been primarily focused on the browser. And I would say that Teleport is an infrastructure first because there's not many tools that provide the same compatibility for the command line tools. If you see here in this slide here, we have the Teleport logo. There are some things that we do around the signing of our tsh binary to sort of make this work seamlessly in the background. And I'm going to show you a little example of enrollment. I'm going to use my two favorite people in cryptography, Bob and Alice. And I'm going to go through the involvement of Bob as a DevOps engineer and administrator of Teleport and Alice as an intern. So we are logged in as Teleport admin, so we're going to just go about and create this new user. One of the first things I want to talk about is role-based access control. This is a very important foundation of Teleport, and it means that you can link identity with fine-grained access control. In our case, we have provided access to basically all of the Kubernetes labels but nothing else. We have this important search as roles for access for this intern role. And I'll walk you through this as we create Alice.

Ben: 00:22:49.503 But another important detail here is we have this max session TTL, and this means that once Alice authenticates into Teleport, her certificate is only valid for two hours. And after those two hours, her period of access stops working, and she needs to reauthenticate again using whichever method you need. And so we often see people deploy it for, let's say, eight days, like a working day, or even short, depending upon how people are working in their infrastructure. And then this is another important one. We have Ping Source IP, which is an enterprise feature. I'll go into this a little bit more later. So I'm going to just create the Alice user, and she has the intern role. Oh, I have Alice already. Let me remove Alice. So I'm going to be adding Alice here. And we have this unique enrollment link here. So just taking a break, I'm going to log out. Now assume I'm playing the role of Alice. I have securely obtained this invite link from my organization. So I'm going to get started.

Ben: 00:24:08.936 And for this example, I'm going to log in with Touch ID. So we have this window here which pops up to verify my identity. You can use a USB key or this device. I'm going to just touch my finger. And now I'm in Teleport. So if I log out again now and I log in, it prompts me to log in as Alice. And you'll see that, actually, I don't have access to much, but I only have access to the Kubernetes cluster, and I now have access to two hours. Within that two-hour window, I have to log out and reauthenticate again. But one addition we've also added in Teleport 10 is access requests. So, Alice, while she's the intern, she might have to have access to other hosts, and so she can make the same request to our eBPF host if she wanted to and say, "I need to debug this host. Send it to Bob," and she can negate access request. So not only this provides even more fine-grained access to her infrastructure. Okay, so I think that's a good overview of Alice's role.

Teleport Passwordless – supported passwordless devices

Ben: 00:25:33.708 And I'm going to go back to my slides. So I think we touched a little bit on this. So for supported devices — I think I showed a few. I showed YubiKeys. We support YubiKey Bio and YubiKey 5 NFC, but also all other roaming keys such as Google Titan and SoloKey as long as they support the FIDO2 protocol. We support Windows Hello in the browser, and we're currently working on for the Windows Terminal, and we support Apple Touch ID as well. So there are like a few interesting limits of passwordless to be aware of. One thing we do recommend is setting up multiple YubiKeys or different authentication methods, maybe Touch ID and YubiKey. This can be useful, especially if you go across devices. Touch ID also has to be involved both in the Terminal and in the browser. And as I mentioned, NFC roaming keys, I prefer them over the biometric one. It makes it much easier to log into, let's say on an iPad or mobile device.

Limits of passwordless

Ben: 00:26:44.010 And one thing of note, certificates are still written to disk, such as in the case of Alice, she has a two-hour certificate for access. But you can also protect that from source IP. So if someone was to exfiltrate that certificate, it wouldn't work on another network because it's protected by the source IP. And we have documentation here that sort of goes into this detail of this feature. And then users must enroll different devices separately, so I enrolled my MacBook and my Windows host, it's fine. There is actually this addition which is called Passkeys, which is on the horizon of passwordless, which should fix this. And there's sort of some interesting additions in the world of passwordless.

Protecting against the wrench attack

Ben: 00:27:31.479 And last up, there's the wrench attack. This is an interesting attack which all, basically, systems are vulnerable to, and this is an interesting xkcd cartoon. And the idea is you can have the best encryption in the world, but ultimately, someone could go take a wrench, hit them on the head or persuade them to give their passwords. But there are solutions that protect you against the wrench attack for Teleport. So starting off with registration, when you send that surface link, you can also tie it to particular YubiKeys, and so you can get a certificate baked into your YubiKey, so only those ones issued or come from the organization. So that sort of fixes the involvement wrench attack problem to some degree. We also recommend sending a very long pin. Even with the biometric YubiKey, you will have a pin fallback. You can set pins, actually, for Windows Hello up to 127 characters. And while you might think the pin is similar to a password, the thing that makes it different is that pins never leave the device, and the pin also requires the TPM to work. And also, in the United States, long pins are protected by the Fifth Amendment, which biometrics aren't.

Ben: 00:28:49.773 Another addition is you might want to set up per-session MFA. So if someone was to steal your YubiKey, get initial access, this would still require them to tap the YubiKey or hardware token each time you start a session. Next up, we have access requests, which I sort of give you a demo of. You might want authenticate them in, but then get other people to check, okay, well multiple people need to approve this request to give them access as an extra check. And then last up, we also have dual- and multi-party authorization, which means one or multiple people need to join and be active on that session, both for server and Kubernetes sessions, and they can observe that session and if anything is going awry, they can terminate it.

Embracing passwordless infrastructure

Ben: 00:29:33.551 And we have some documentation here on our Dual Authz feature. So let's talk more about embracing passwordless infrastructure for machines. So I think one of the first things when you talk about machines, let's just break down problems of the password. All of these things — sort of static credentials — are passwordless-like. So database passwords — you might configure your database once. You don't rotate the password. SSH passwords and even SSH keys, once you sort of created them, you may not rotate them, and they sort of stay pretty static, the same as TLS certificates. We've sort of seen this in the world of — let's say, Let's Encrypt, really made it very easy to get short-lived TLS and SSL certificates, which was previously very difficult. So people would have very long processes for updating their TLS. And then also kubeconfigs can be static.

Passwordless for machines

Ben: 00:30:31.907 And then when we're talking about machines, we're talking about everything that communicates to your infrastructure, so whether it's physical servers, VMs, Kubernetes clusters, microservices, cron jobs, lambdas, IoT devices, these are all machines that might need to have access to your infrastructure. And I think one thing — we touched on identity for people being their biometrics. In the world of infrastructure, most things do have some form of identity. In the world of AWS, they have two forms of identity. It can either be a EC2 instance identity document, or it can be signed from get-caller-id. And this will prove that this server belongs to which account. And another example in the hosted world is using HSMs to show that, okay, this machine is property of this root trust.

Teleport Machine ID

Ben: 00:31:29.201 And this is one of the features that we've added into Teleport, which is AWS node joining. You notice we have a name here, but this name isn't a secret because the instance is only able to join if it links to this account, and we prove the account can join by using get-caller-identity. And so Machine ID was created to solve this problem of machine-to-machine communication. So we looked at Alice logging in and getting access to a Kubernetes cluster. But you have many services. It could be a microservice talking to a database, it could be a CI/CD service talking to other ephemeral infrastructure. That communication has the same problems as Teleport.

Ansible setup

Ben: 00:32:10.218 And I'll just take a sort of a simple example, Ansible. Ansible is a common machine-to-machine pattern. It's an open source provisioning software which provides access and configuration management to systems. Often the way in which you set it up is you have one control node, you give an SSH config and a list of host files, you run, it updates all of your infrastructure. But what often happens is when you first configure Ansible, you might be using SSH private keys and public and private keys, which is a static form of credentials, because using certificates can be sort of difficult for sort of issuing and management. And then you run your playbook. And as we sort of discussed going back to F slide, this Ansible key is a perfect and very highly valued secret for hackers to get a hold on, because basically this key runs in all of your infrastructure and along with being a long-lived token. If someone exfiltrates it, you're not going to be rotating it. So it could have access for a long period of time. And even if it is compromised, it also can be difficult to rotate.

Ben: 00:33:19.534 Next up, you don't really have much visibility into this credentials, which system is using it. And so Teleport solves this with Machine ID. In the background, we have this little, small program called tbot that runs the service. I won't dive too much into details, but it runs credentials every 20 minutes. It writes the certificates to disk, supports CA rotation for fixing the rotation problem. And then also you have the list of all bots available. So the new way is interesting. It's pretty much exactly the same as the old way as far as Ansible is concerned, but Machine ID greatly strengthens the way in which credentials are used. And so Machine ID is only joined using an IAM token so you know that you've verified that the control node is the only one that has access to those certificates. And in the background, it's always rotating those credentials and you get visibility into it.

Ben: 00:34:16.810 And I can give you a quick demo of what this looks like. I'm going to just log in. I'm logging back in as Teleport admin, and I have my control node here. And Ansible is backed by running Ansible Playbooks. And so instead of one playbook here, which is going to be gathering facts and going to be running — as far as, like, an end operator is concerned, the user experience is the same. You could see it's pinging all of my hosts in my host inventory. But the addition of Teleport Machine ID is that you have a full overview of all of the noninteractive interactive sessions which Ansible does under the hood, along with having the ability to also terminate and stop this host from running.

Ditch passwords and secrets checklist

Ben: 00:35:29.557 Okay, so that's my little overview of my Ansible setup. I'm going to come to my last slide, just sort of wrap it up. It's always good to take a learning, sort of think about how you're thinking about passwords and secrets. This is like 101, but check your machines for lingering public, private keys. Investigate if certificates are the best way to provide short-lived access. Okay, and then talking about employees, consider rolling out YubiKeys or Titan tokens to all employees. There's been multiple attacks of both SMS or TOP apps being vulnerable and having something, your biometrics and the TPM is the strongest form of authentication.

Recommended next steps

Ben: 00:36:16.660 And then if your system does provide passwordless access, consider upgrading it. And then, as far as machine-to-machine communication is concerned, review how your automation tooling talks to each other. And then, last up, are the machines communicating using the principle of least privilege. And I think that kind of goes back to my Ansible point is that you might have this public, private key. And one thing I sort of skipped over in my Machine ID example is you can link your Machine ID access to a very fine-grained RBAC which you can also control separately from the credentials that you have. So for next steps, we have this document here, this page about passwordless. You can learn more. You can download Teleport. Teleport is an open-source tool, so you can also review the source code and see how we've implemented Teleport. And I think, Ev, I'll pass it back to you. You have a few closing words.

Q&A

Ev: 00:37:13.208 Thank you, Ben, of course I do. And we also have quite a few very interesting questions in the Q&A chat window. So I'll go over the questions that I have collected and as you're listening to me, feel free to add additional ones. So let's start with somewhat of a provocative question here. "Isn't the certificate just for background?" When Teleport authenticates you using the TPM on your laptop and your fingerprint, basically, after the passwordless authentication, the result of it is that Teleport issues certificates for all of your workloads. You get certificates for your databases, for your servers, for Kubernetes, for everything. So the question then is, isn't the certificate itself is a secret? The answer is yes, but this is not a static secret, which means that if it's — so let's just assume that attacker will use the wrench and kind of hit you with it and steal your laptop right after you just obtain certificate. So that certificate, first of all, it's pinned to the context of where it is being used. So it's pinned to the IP address that you have. So that certificate outside of your laptop is not going to work.

Ev: 00:38:27.835 Also, a certificate has a TTL, time to live, which is configurable. So if you're not that paranoid, you can set it to eight hours, which means that the certificate becomes useless the next day, which is also actually a big deal so which means that a lost laptop is not a problem. Or you could have a much shorter interval for the certificate to be, for example, one minute, because what that does, it essentially issues you a single-use certificate that you can only use to complete one operation. Additionally, the certificate scope could be reduced in time during the session — I'm sorry, not time but permissions. The certificate might only give you guest access, and then when you try to access, let's say, a server or a Kubernetes cluster or database, if you don't have permissions, the access request will be sent behind kind of transparently to your manager or to your peers, and they will see that Alice is trying to access this thing, and they would have to approve or disapprove it.

Ev: 00:39:26.442 Additionally, as Ben mentioned, you might have even more paranoid setup where you actually need two certificates to complete sensitive operation, meaning that you would be given access to database, but only if your manager is also accessing database at the same time and watching you do whatever you need to do, so this is called Dual Authorization. And finally, someone correctly pointed out that you can configure Teleport to require passwordless auth every time you do something sensitive. So if you want to do like a pseudo command and then Teleport will tell you again, "I need your fingerprint again," which makes that certificate useless for sensitive operations. But it is a form of secret. That is true, but it's, extremely, a contained secret.

Ev: 00:40:13.751 So the next question is, "So is Teleport something similar to Keycloak? Does it create a single point of entry to get access to infrastructure?" So, for those of you who are technical, I'll just give you an engineer description. Teleport is a drop-in replacement for SSHD because it started its life, originally, as a better implementation of SSH. But in 2022, Teleport now supports numerous protocols, most popular databases, Kubernetes. It supports Windows. It supports web applications. And the way it works, it's a combination of identity-aware access proxy. So essentially it's a proxy that requires your certificate to be in the wire, and if you don't have it, then it performs [inaudible] authentication. Then the second component is a certificate authority. That's the thing that issues you certificates. And finally, there is an audit log.

Ev: 00:41:08.708 You can run Teleport in a proxy-only mode, which means that you basically need like one host, and that becomes an [inaudible] jump box for your entire — jump box for your entire infrastructure. But if you want to get advanced capabilities such as session recording, then you'll have to run Teleport on your actual workload. So you have to replace SSHD on your machines or put it inside of Kubernetes. So there are two deployment methods, lightweight and the full deployment. That is what Teleport is. So it replaces VPNs. It replaces all of your jump hosts. It creates a single, extremely secure, extremely convenient to use door into your computing environments.

Ev: 00:41:45.642 Next question, "It feels like the only way to actually achieve password secretless authentication is simply ask for credentials biometrics on every single user interaction with the resource. Otherwise, you always have some kind of temporary access credential, which is a certificate." Yes, absolutely correct, very smart question, very smart observation. And that is indeed something Teleport supports. So you can configure it for extremely sensitive resources to always require passwordless authentication for every sensitive operation. Next question, "Can Teleport replace bastion hosts and VPNs? Or are these still necessary with Teleport?" No, Teleport replaces all of these things because we believe that, in general, secure access cannot be enforced on a network level. So any kind of secure access solution coming from a vendor that is a network vendor, just cannot really do what needs to be done, because Teleport works on application level. So Teleport works on SSH level, Teleport works within your database, within Kubernetes, so we believe that network don't matter at all. So Teleport architecture assumes that every single host, that Teleport is running on is running on a public internet. So there's no difference between VLAN or VPC or public internet. So we call it complete Zero Trust. So every host is absolutely secure, and you cannot get into it from anywhere.

Ev: 00:43:08.240 Next question, "How does an org migrate to passwordless from secret-based access?" So Ben shared a checklist, things that you can consider, and there's going to be a recording of this webinar, so you can go take a look later. But in practice, because Teleport now has massive number of users and we have some very well-respected engineering organizations on our website that run in Teleport, including Nasdaq Stock Exchange, for example. The way that most of them have adopted this technology is one problem at a time. This is why we partition Teleport offering into server access, Kubernetes access, database access. So you might probably want to start with your most recent projects, particularly, around Kubernetes. So if you're adopting Kubernetes, well, make your Kubernetes clusters passwordless, then extend it to SSH protocol for machines that Kubernetes runs on. Then if you start using it for databases. So basically, one workload at a time. Yes, it does take time, but we are in an infrastructure security in DevOps world. We like to be careful. We like to be conservative.

Ev: 00:44:26.593 Next question, "I like the idea of minimizing the number of entry points. What if you guys get hacked, would, then, they have access to everyone's internal infrastructure?" Perfect question. Sometimes we get this question from a single source of failure perspective, too, because they would say, "Well, now you're replacing all of these different entry points with one giant entry point, what happens if it fails, or what happens if it gets hacked?" Well, think about it from probability perspective. From a security point of view, having one door is strictly better because probability of that door being hacked is lower than probability of one of thousands little doors get hacked. So yes, everything and everyone can get hacked. And there is such thing as zero-day exploits.

Ev: 00:45:17.397 Now, the question, can Teleport be hacked? How confident are we with our technology? I can only say that we're confident enough to develop it in the open. So Teleport is open source. We're working on it in the open, not just so you could see every single line of code we've written, but we're also sharing design documents. We have discussions with security teams from all of our customers. So when you are running Teleport, you are consuming a product, which is a product of collective intelligence, of multiple security teams across the industry collaborating in the open. So that's the best we can do. Additionally, just to make sure that we're not exceeding kind of our own limits, because we're also humans, we periodically invite independent security companies to do audit line by line of Teleport source code, and we publish those audits. So we take the vendor trust issue extremely seriously. That's all I can say about that.

Ev: 00:46:19.704 Next question, "Are access requests timeboxed?" Yes, they are indeed. In Ben's demo, you saw that Alice could send an access request, and it could be made that she needs to provide access reason. So then we call it sometimes intent-oriented access. And if Bob decides to cut access in the middle of the session, he can do that. But also, you could have sessions that require two or more people to be online at the same time. If someone disconnects for everyone else, access is automatically revoked. Another question, "Our organization couldn't integrate Teleport easily with database tools like Navicat." As far as I know, Navicat is a web-based administration tool. Yes, it is possible that there is a workload. We're not easily to integrate with. But at the same time, Teleport, now, is becoming incredibly popular infrastructure solution. So engineering team like doubling year over year. So I would encourage you to look into this again because we're working hard to make sure Teleport seamlessly works with the most popular things. And —

Ben: 00:47:29.183 I think you also have to create a GitHub ticket and issue feature request. Come to your point, we're open source company, so if there isn't an issue already. You can also join our community Slack channel. And if you've tried it and it hasn't worked out, we're happy to sort of help and debug it for you.

Ev: 00:47:46.612 So that's right. So looking at other questions, "Does passwordless work with Okta over IdP?" Not in this version. So today, if you want to use passwordless capabilities of Teleport, you would have to use Teleport's own — basically, you would have to use Teleport as IDM, moving forward, that will likely change. Next question, "Are you planning to add passwordless auth for tsh on Windows?" Ben, are you aware of — what's the time?

Ben: 00:48:19.929 Yeah, it's coming, I think.

Ev: 00:48:21.417 Coming.

Ben: 00:48:21.359 I think in a very recent release, maybe like 10 dot something. I know it's almost finished, and I think it'll also support Windows Hello, which, to be honest, was one of my favorite passwordless, Windows Hello. Just like looking at the camera, logging in and getting access to your infrastructure definitely feels more sci-fi than tapping a YubiKey.

Ev: 00:48:40.041 Yeah. Next question is, "Is there a way to test out Teleport without buying a license?" There are two ways you can do it. You can download open source version Teleport. So all of the capabilities shown today are available there. Or you can go get yourself a free cloud evaluation account, no credit card required. You go sign up for a trial, and you have, I believe, 30 days to play with Teleport. Next question, "I completely agree that this is a very good approach with short-lived certificates, already reduces help so much security compared to forever lasting passwords, and it's also very nice. I was not aware of passwordless authentication that requires auth every single —" ah, okay, that was not a question. That's a compliment. Thank you very much.

Ev: 00:49:26.506 Okay, next one, "Do you have any recommendations on protecting our infrastructure against employee computers which are compromised with malware and such, something that has been dealt with?" So, as I said, simply moving to this short-lived certificate already dramatically reduces your risk profile. But there are a few other things you could do. So not all malware is the same. So when a hacker has full control over someone's machine, it's really hard to protect against it. But we do have certain capabilities that make you less vulnerable. For example, if you want to make sure that there are no cookies, because cookies is another kind of major liability in infrastructure, because compromised laptops that cookies and active sessions is the first thing that attackers go after.

Ev: 00:50:23.229 So Teleport has a capability called Teleport Connect. It's basically a browser. So it's based on top of Electron, if you know what that is. So it uses a browser engine to give you access to your infrastructure. But we've modified it that instead of using cookies and redirects, which is a traditional method of parsing identity using browsers, it only uses certificates. So it enforces certificates for everything. And for this reason, there is kind of nothing to steal. And as I said earlier, the other capabilities for you to protect against completely compromised laptops is Dual Authorization, which basically means that no engineer, no employee by default, by themselves, alone, can do anything critical. You could always have this thing that someone needs to be watching what they do. So that basically means that like two people in the organization needs to be compromised by the same attacker at the same time, and one of them just happens to be the manager of the other.

Conclusion

Ev: 00:51:34.135 Any other questions? Any other questions, one? Any other questions, two? Any other questions, three? Well, if there are no other questions, we're going to go ahead and conclude this session. So if you're not already using Teleport, we encourage you to go to our website and either download an open source version or sign up for a free trial. Or you can request a custom demo with our excellent solutions engineering team to see how passwordless can remove human error from your organization and protect your infrastructure. Thank you so much for joining us. Have a wonderful rest of the day.