Introduction to Teleport

Introduction to Teleport - overview

Want to know how Teleport’s Access Platform technology replaces VPNs, shared credentials, and legacy privileged access management technologies, improving security and engineering productivity? Learn more about Teleport’s Certificate Authority and Access Platform for your infrastructure so you can:

• Set up single sign-on and have one place to access your SSH servers, Kubernetes, databases, Windows desktops, and web apps.
• Use your favorite programming language to define access policies to your infrastructure.
• Share and record interactive sessions across all environments.

Key topics on Introduction to Teleport

• Teleport is the easiest, most secure way to access your infrastructure.
• Protecting modern applications requires mastery of four essential elements of infrastructure access.
• Teleport Access Platform unifies access policies for engineers and machines using the same certificate-based approach.
• Teleport is open source, and this speaks to our DNA.
• Legacy solutions tackle the access problem by creating cumbersome enterprise solutions that cater towards checking the boxes for security or compliance and don't necessarily prioritize the end user.
• Everything gets an identity, and that's how we achieve the zero-trust model. The certificate authority is responsible for providing that identity to your users and resources.

Expanding your knowledge on Introduction to Teleport

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

Learn more about Introduction to Teleport

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

Introduction - Introduction to Teleport

(The transcript of the session)

Anadelia: 00:00:00.227 Hello. And thank you for joining today's webinar. Today, we're going to be talking about the introduction to Teleport. And before we get started, just a reminder that this presentation will be recorded and everyone who registered will receive the recording. Also, I want to let you know that if you have any questions throughout the presentation, please submit them through the Q&A section, and we will cover them at the end of the presentation. And now I'm going to hand it off to Dan.

Teleport at a glance

Dan: 00:00:33.575 Thank you, Anadelia. Hello, everyone. Thanks for joining us today. My name is Dan Morris, enterprise account manager here at Teleport. And joining me is Jay Perez, senior solutions engineer. I'm going to walk you through how Teleport is the easiest, most secure way to access your infrastructure, regardless if it's a bare metal server, cloud, container, Kubernetes cluster, Windows machine, or desktop. And then I'll turn it over to Jay to take you through a quick demonstration so you can see the product in action. Let's get started. So a little bit about Teleport. We were founded in 2015 by engineers at heart that are former Rackspace, Google, NSA alumni, with the main mission being to enable engineers to access any resource anywhere in the world. We have over 200 customers, and our core business model is open source with enterprise features and a managed cloud offering. Our difference is our cloud access platform technology that consolidates access across all your environments into a single login via your identity provider, Okta Active Directory, etc. We just raised $110 million Series C, and we have seen adoption in partnership with organizations like Nasdaq, IBM, Samsung, Snowflake, and others. The main reason we're gaining momentum and traction is because the compute and infrastructure landscape has changed drastically. And with that has come some serious challenges. So there's been a tension between infrastructure engineering teams and security folks. Engineers want a seamless way to access the infrastructure resources they need. Security teams want to make sure those resources are protected and compliance requirements are adhered to. When we talk to our customers, they tell us that they were making a lot of unnecessary trade-offs between these teams before they found Teleport.

Security vs. agility

Dan: 00:02:07.597 So security in a cloud-native world is much different than it was just a few years ago. First, work-from-home adds the pressure and essentially killed the corporate network. Second, employees at different levels of seniority need to be able to connect to their infrastructure from anywhere. And finally, infrastructure is increasingly complex. A typical customer environment that we see includes Linux and Windows servers, Kubernetes clusters, databases, and internal applications like CSCD systems and version control systems at GitLab. In this environment, protecting modern applications requires that we master four essential elements of infrastructure access. So the first is connectivity. If access can come from anywhere and compute can happen anywhere, we need to be able to securely connect to any resource on the planet, regardless of network boundaries. The next is authentication. We need identity-based authentication for engineers and machines so we know exactly who or what is accessing each resource. Once we know who or what is accessing, we need authorization. We need fine-grained access controls so that we can explicitly define what a human or machine can do and what they cannot do and what those privileges are and automatically enforce them. Finally, we need robust audit, who or what accessed each resource, when was it accessed, and what was done. Without unifying these four elements of access, your systems will be vulnerable to attack and productivity of your teams could be compromised. So the problem is that existing solutions forced trade-offs between these pillars of access. Perimeter security solutions like VPNs focus on connectivity believe fine-grain audit in the equation. So what about relying on shared credentials using secret vault? That still requires you to figure out remote connectivity and auditing for engineers and machine users. Not to mention shared credentials are security liability.

The Teleport Access Platform

Dan: 00:03:53.956 And finally, there's legacy PAM. While PAM solutions are usually stronger than the former on security, they tend to be bulky and slow down your engineers and don't help for machine-to-machine access. That is why Teleport is different. Our Teleport Access Platform consolidates the four essential infrastructure access capabilities that every security-conscious organization needs, connectivity, authentication, authorization, and audit. Teleport unifies access policies for engineers and machines using the same certificate-based approach. And it's not only more secure. It improves engineering and developer productivity. The Teleport Access Platform is zero trust certificate-based, and it provides advanced just-in-time access workflows and gives complete visibility into access and behavior for human and machine users. We bring those capabilities deep into our infrastructure, down to the protocol level. So for instance, Teleport Server Access gives you visibility into all SSH sessions down to the kernel level. Teleport Kubernetes Access can enforce two-factor authentication for kubectl exec commands. Teleport Database Access can enforce table-level roles and show every query that hits your Postgres, MySQL, or MongoDB database. Teleport Application Access can provide a VPN replacement for internal applications like AWS management console, Jenkins, GitLab, Grafana, and more. And then, finally, our latest edition Teleport Desktop gives you a modern password list access for all your Windows servers and desktops, including complete session recordings.

Teleport use cases

Dan: 00:05:27.975 Let's look at a few common use cases for Teleport. The first is simply zero-trust infrastructure access. By providing an identity or access solution for your entire infrastructure, Teleport improved security dramatically regardless of network boundaries. Some customers need to go beyond that and prove that their infrastructure is secure by passing an independent audit for FedRAMP, SOC 2, PCI, HIPAA, or GDPR. We have playbooks that can get you there. We also have customers coming to us saying, "Hey, we need to go passwordless." Teleport can replace all your secrets with short-lived certificates that are not only more secure. They improve developer experience. And then, finally, customers sometimes need to modernize their privileged access management systems in a way that integrates into their distributed and DevOps-driven environments. We can help there as well.

Teleport is open source

Dan: 00:06:16.712 Again, Teleport is open source, and this speaks to our DNA. If you compare us with legacy solutions, you notice one key similarity in their approach as opposed to ours. They tackle the access problem by creating cumbersome enterprise solutions that cater towards checking the boxes for security or compliance and don't necessarily prioritize the end user. At Teleport, we've created a solution from the ground up with engineering DevOps and SREs in mind. Our founding engineers came from this world and experienced these problems firsthand. That is what makes us truly different and why being open source is so important to us. Teleport is trusted in production by customers who care about moving fast while also maintaining best-in-class security posture. Our engineering team has faced these exact challenges and have built a solution that we know works for other high growth and security-conscious organization. With that, I'm going to turn it over to Jay to take you through a quick demonstration.

How Teleport works

Jay: 00:07:13.242 Howdy, howdy, everybody. Jay Perez here. Like Dan mentioned earlier, I'm a solution engineer here at Teleport. Been at Teleport about 18 months, starting my journey in support team, currently on the solutions team for the last 6 months or so. I'm reporting live from the breakfast taco capital of the world, Austin, Texas. I will preface this by saying that I am Dominican American, which means I speak very fast. So if you need me to slow down, just send a message in the chat, and I promise I'll slow down and keep it to your pace. All right, let's get started. Let's start here with an architecture overview. So this is a brief overview of what Teleport architecture looks like. Everything inside this purple box is what we consider to be a Teleport cluster. So there's two teleport components. One is the Teleport Proxy. The proxy is your entry point into your cluster. It's also how all your resources connect. The next is a Teleport auth server. The auth server is responsible for two things. One is auditing and keeping track of everything that happens in your cluster. But the most important feature of it is the certificate authority. So everything in Teleport gets an identity. All your resources, all your users, everything has an identity. And that's how we achieve zero-trust model. So the certificate authority is responsible for providing that identity to your users and resources.

Jay: 00:08:42.481 Living just outside of your cluster, we have your identity provider should connect any SSO you have that accepts OIDC or SAML. So this may be Okta, Google Workspace, or Azure AD to connect to your resources. Once you set this as your source of truth, teleport is able to extrapolate the groups that users have and render comprehensive role-based access controls based on that. Currently, Teleport supports Linux servers via SSH, Windows servers via our proprietary RDP. We have Kubernetes and various databases to include MySQL, Postgres, MongoDB, Cockroach, many more. And then we also support internal web applications, something like Jenkins or Grafana. The traditional workflow for a, let's say, developer living out here is called developer ‘devon’. So when devon logs in today, devon will log in to Teleport using your identity provider. The Teleport auth server then grants a certificate. These certificates are time-based. This can be configured. Once that time expires, so does the access that devon had. Additionally, these certificates have metadata, which includes all the access you require for the day. So I would say you have access to X, Y, Z Linux servers, X application, X communication cluster, so on, so forth, as you define with your role-based access controls. But we've noticed that sometimes devon will require protection resources or need more access than he traditionally has. So we have a mechanism called access request. Access request allows devon to get the temporary access she needs, and it's temporary access she needs to access any resource. And once that time expires, she returns back to her basic level access.

Demo time

Jay: 00:10:39.740 We use these tools in the top to facilitate that workflow of access requests. So for example, when devon was to request elevated access, you get a Slack notification. I'll demonstrate that later on. Or you can get a Jira ticket that comes in, and you could approve it through that Jira workflow. Or even we have a [inaudible] to integration, which allows devon to automatically gain the access she needs as long as she's on call or has an active ticket. I will then move into a demo in Teleport itself. Let me change my screen share. All right, so here, I'm logged in as devon. As you can see in the top right corner, these are all the Linux servers devon would have access to. And one thing you'll notice is that it's tagged as label environment dev and dev. So devon even has access to all environment dev resources and Linux. Another thing you'll notice that when it comes to SSH, Teleport allows you to restrict what users you can log in as. So devon could only log in as EC2 user. So let me go ahead and SSH into the server. When you SSH into a server, it could be done via the web UI like I did here or using your traditional CLI terminal, whichever terminal you currently use. I'm going to generate some traffic here just so I could have something to show you the audit logs. Go ahead and close that session here. If I go to activity, under audit logs, you'll be able to see when my session started. This is when devon first logged in to the server. If I back up a little bit, you see a certificate issued. So anytime devon logs in, she's issued a new certificate. Or anytime she requests a little bit access, she'll get a certificate. That certificate has metadata associated to the session and all the access they have by default.

Jay: 00:12:42.467 But this is when the session first started. You get metadata on the server who logged in, what user they logged in as, and also when the session ended. And the session ended. You could also play back a video recording of what transpired. The real cool thing about this — I know I said video, but it's actually text-based. So I could actually copy and paste out of here, as you can see here. Copy and paste out of a session recording. Additionally, I could extract this to a file and grab for certain commands and so forth. And it does play back with the video pause, rewind, fast forward, just like a traditional video would. This could also be played back on the CLI if need be. Okay. So let's say devon needs to elevate now to production-level access. So we have Access Requests, which is here. I could request access. Select the role I need access for. I could provide an optional reason. You could make this mandatory. Provide access. I'm going to go ahead and send that request out. On my administrative side, I had the Slack channel called Access Request, and you'll be able to see when the request comes in. It says the request is pending. Once it's approved, you'll get an emoji that says approved. You could also get a denial, as you see here, denied. Since I'm logged into the admin in this browser, I can just click on this link and approve it right on the spot. Approve or deny? I'm just going to approve it for saving time here. On devon's screen, she will be able to see that the access was approved. I could then assume this role. And one thing you notice, probably displayed at the top, is that she has access for 59 minutes. Once this time expires, devon will return back to the basic level access she had prior.

Jay: 00:14:33.007 If I go to my resources now, you see that my server list has grown to include environment proc. Another thing you'll notice is that I could also log into root now. All right. I'm going to go jump into my admin access to do the rest of the demo. I want to demonstrate something we call Enhanced Session Recording. So as I showed you earlier, we had a video playback of a session recording [inaudible]. But it's slightly limited as you could only see the commands or read on text. With enhanced session recording, we are leveraging what's called Berkeley Packet Filtering, or BPF, to get kernel-level information of everything that happens within that cluster. So this is advantageous because we found that our customers said they have engineers that are advanced and use mostly script throughout the day. So I created a short, little neat script that is going to get me my weather eventually. There you go. [laughter] All right, so we got the weather here. All the script is doing — it's setting my directory colors, and then there's a curl command. So I'm going to go ahead and show you what that looks like in the audit logs with BPM. So you see? It's a lot more data. This is when the session started. You're able to see all these entries. Every entry is a command that was run. The first few entries off from a bashrc file. The very first command that read my script is actually directory colors and then this curl command. If I look at the details of this curl command, it will show you that I ran curl as root. And this is the website actually curled. Since we are leveraging Berkeley Packet Filter, we're also able to get any network connections that initiated, as you'd be able to see here, that we allowed a connection to curl from my local IP to this web IP. And just like before, I'm able to play that session back.

Jay: 00:16:34.434 All right. There are many more features associated with our Server Access. I will leave it there so you could ask me questions later if you have something more specific. I will next jump into other protocols. So we also support Application Access. This is what we consider internal applications. The advantage to using Teleport's solution for applications is that, traditionally, some of these apps like Grafana or Prometheus live inside a private pod or running dock container with private IPs that you don't expose. So our app access allows you to read traditionally inaccessible internal apps without leveraging the VPN, and you get a secure connection all the way across. I just started up my Grafana. This Grafana is currently running inside a Kubernetes pod with internal IPs only. Another thing you'll notice here is that I'm actually logged into Grafana as my admin user. So with Teleport, we are able to leverage Java web tokens or HTTP headers to make this experience passwordless. So I could reach my applications all the way seamless through without having to enter a password. And you notice with Teleport in general that we are moving towards everything being passwordless. Another thing you can leverage with our app access is that Teleport is aware and is able to leverage IAM roles in AWS. What that means is that we could use our existing roles in AWS and map a user to that role using our console access. This works both via the CLI and the UI.

Jay: 00:18:18.437 So as you see here, I'm logging into my read-only — as a read-only user into my actual AWS account, where I'm hosting all my resources at the moment. Where this is advantageous is, as I showed you access request earlier, you could use access request to elevate somebody's access to AWS temporarily. So let's say you want to modify or fix your authority within AWS using something like ACM. You could grant them that temporary access for that very sensitive work, and they'll lose that access as soon as their session expires.

Dan: 00:18:56.246 Jay, we have a quick question if you don't mind pausing for a second for Richard. If a user needs to log into Linux VM and require Unix profile to access data on a daily basis, does Teleport support that?

Jay: 00:19:07.893 Yes. So Teleport allows you to map to an existing user, or you could use — we have a PAM integration. Our PAM integration allows you to create PAM scripts inside these Linux and Unix boxes and leverage that accomplishment through Teleport. So yes, both ways work. I will jump into Kubernetes Access. So Kubernetes cluster's here in the UI. It tells you how to connect these clusters. So you do need the CLI for Kubernetes. So I could do tsh status. Will show my current certificate and what access I currently have. So it says I have 9 hours 25 minutes left. If I do tsh kube ls, it'll show me all my Kubernetes clusters. I'm currently logged into EKS clusters. Teleport remembers the last cluster you logged into. So once I log into Teleport, Teleport actually appends my config file with my certificate. What this means is that you don't have an indefinite kubeconfig file line out there that could be compromised.

Jay: 00:20:19.309 So with Teleport, I could also just start working immediately. kubectl get pods. The very first time is a three-to-five-second delay. After that, it’s instantaneous. You'll instantly be able to connect to that cluster. I could change context by doing kube login gke, and I could do kubectl get pods here. And that's how we switch context back and forth. Let me go back to eks. I'll show you the auto-login actually in a second. But what's really nice about Teleport is that we're also able to get session recordings for exec commands. So I'm going to exec into this busybox pod, free, ls [inaudible], and close out of the session. In our audit login, you're able to see all these Kubernetes request that I've made. This should be a get pod. So I did a get pod in the default namespace in my Kubernetes cluster called eks. And then this is when I did that exec command. I'm able to exec into that pod. And the way to view that session recording is through the session recording tab. It shows you eks cluster default namespace busybox pod. Cool thing to show you is that tsh play command allows you to playback session recordings. I just got that session UID, and I could play it back right here in the CLI.

Jay: 00:22:03.015 All right, the next protocol highlight would be our Database Access. Like I mentioned earlier, Teleport supports MongoDB, Postgres, MySQL, Microsoft SQL, and various other ones. The experience is relatively the same for all our databases. tsh db ls will show you all the databases you have access to at the moment. At the moment, I have three Postgres. So I can do tsh db connect to connect to database, provide database names, the user, and the database to Teleport. And I'm in Postgres automatically. You could configure Teleport to speak to any client that you currently have, as long as they accept SSL certs, which most do. You could do tsh db config. And this will show you the configuration information you need to set up these clients. And it's very seamless and fast. Let me show you the audit login for database. It's very similar to what you saw before, when the database session started, when it ended, and any query that is run. Obviously, I did that. [inaudible] command which in Postgres just list all the users? It's a very long query.

Jay: 00:23:21.994 And then our last protocol is Desktop Access. Desktop Access is how we leverage RDP. Essentially, the advantage to using Teleport is that you're reducing your attack area. You could install a Teleport pod close to your domain controller. And through there, you leverage all the connections. You only have to open your RDP port to a single source. Once you connect, you're logging in as administrator, you'll be able to see that it's actually also a password experience, just like our other protocols. Once you log in, you're able to already put a traditional [inaudible]. You could enable or disable clipboard sharing. You could also enable or disable recordings via role-based access controls. And that does give us a session recording, which we could play back. You'll be able to see when I logged in. All right. That concludes the demo portion. I could go more in-depth if we have any questions that are asked more specific.

Q&A

Anadelia: 00:24:32.042 Thank you, Jay. We do have a few more questions in the queue. One of them is: "What is our pricing model?"

Dan: 00:24:43.378 Yeah. I'll take that one. Our pricing is a per-user pricing model per protocol. So you basically determine how many users you need access on each protocol, and then we price it accordingly. And our pricing is based on an annual basis.

Anadelia: 00:25:02.133 Great, thank you. Got another question here in the queue. We already have passwordless authentication enabled with Ping. If we use Teleport, do we need any change in this?

Jay: 00:25:14.037 So you could use Ping as your identity provider. So you could use Ping as your IDP, and you could bring Teleport as your robust access controls. I wish I had a little more information as to how you access the password list, but Teleport will be able to use Ping as the authorization and then Teleport — sorry, Ping as the authentication. And Teleport does authorization, audit and connectivity for you. Those are the four pillars that we tackle.

Anadelia: 00:25:46.224 Excellent. Thank you. One more here on how are your sessions being stored.

Jay: 00:25:52.549 Good question. So depends on your deployment. So we have several deployment models. We have our cloud offering. Our cloud offering, Teleport Host, the Proxy, and the Auth for you, which means we also store your session recordings in AWS. They're good for a year. We also have our on-prem offer, which is similar to the open-source, where you're able to either store them on disk or store them on the compatible clients. So in AWS, you have – in Google, you have cloud storage. So you could store them on that, and you could set your own protection policies based on that information.

Anadelia: 00:26:37.475 Thank you, Jay. One more question here is around, "What are the different deployment options does Teleport offer?"

Jay: 00:26:43.828 Okay, good. Yeah, the cloud offering, and then we have our on-prem. The on-prem deployment is really fast. You can deploy it. We have a helm chart, so it can be deployed on Kubernetes. The helm chart literally gets you started under 10 minutes. We also could deploy on the Linux host, or we have our cloud offering where we host it for you. You're just responsible for connecting the resources.

Anadelia: 00:27:11.111 Excellent, thank you. And with that, we've reached the end of our questions and the end of our presentation. Actually, sorry, we have one more question. If you can elaborate more on Teleport authorization capabilities, such as RBAC, APAC, PBAC delegation of administration scalability.

Jay: 00:27:28.670 So Teleport uses RBAC robust access controls over attribute based. If you have an identity provider like Okta, which does bring attributes, you could turn those attributes into things you can map to a label. So everything in Teleport is mapped using labels. So labels or tags, how other places call it. So you create labels or tags for all your resources. And based on those tags, you could grant access to users. So it's kind of complex, but it's a JSON — sorry. It's a YAML file. It accepts regex. You're able to do and/or parameters. You could go as deep as you want. So you could say a specific resource, you say a specific set of resources. Additionally, anything in Teleport, any function of Teleport could be locked down via robust access control. So you could completely eliminate protocols from engineers' site. You could also eliminate or improve ability to see audit log, session recordings, modify teams or trusted clusters. I didn't talk about trusted clusters. But trusted clusters essentially allows you to create multiple Teleport clusters and have them be able to communicate with one another. And you could reach resources across the aisle when the trust is established correctly with robust access control.

Anadelia: 00:29:05.130 Thank you, Jay. Just want to get maybe one more minute in case there are any other questions. One question that comes up often is also, "What is the best way to get started with teleport?" For those of us that are in the presentation now, what are you recommending?

Jay: 00:29:18.213 Yeah, the easiest way is we have a two-week free cloud trial. So if you go to our site — I don't know if you could get us a link there. But essentially, you could go to our site, set up a two-week trial. All you need literally is an email address, no credit card required. And then, other than that, if you want to go open source, we do have in our GitHub gravitational dash Teleport. We do have a directory called examples. Within examples, we have helm charts. We have helm chart examples and Terraform examples, Terraforms for AWS. So you get started that way.

Anadelia: 00:29:58.469 Excellent, thank you. And it looks like we've reached the end of our questions. I want to thank you, everyone, for joining us in this presentation today. And thank you to our presenters.

Dan: 00:30:10.084 Thank you.

Jay: 00:30:10.779 Thanks for having me. I can't believe you gave me a microphone. [laughter]

Anadelia: 00:30:15.195 Have a good day.

Dan: 00:30:15.854 Thank you, everybody, for your time.