Sharpen Your Security Skills with Open Source! Introduction to Modern Infrastructure Access - Overview
Secure access to complex computing environments is hard to get right. Introducing the open source identity-aware access proxy: Teleport. It is used by engineers at smart companies Nasdaq and Google, to easily access all to their computing resources — SSH servers, Kubernetes clusters, or databases. For security professionals, Teleport uses short-lived certificates, audit logs, and session recordings to make it easier to achieve high security standards and compliance. In this webinar, we will go over what Teleport is, what some of its key features are, and talk through some use cases. You’ll be a https://goteleport.com (semi-)pro in no time!
Key topics on Sharpen Your Security Skills with Open Source! Introduction to Modern Infrastructure Access
- Teleport, an open source project, is an access platform that allows engineers and security professionals to unify access across all environments and behind NAT.
- The security vs. agility tension manifests itself in 3 key areas: access workflows, credential management, and compliance and auditing.
- Teleport makes it easy to implement security and compliance through identity certificates, role-based access, session sharing, and access request management.
- Teleport empowers organizations like Nasdaq, IBM, and Snowflake to implement security, enforce compliance, and reduce operational overhead.
- Companies use Teleport to easily access all of their computing resources — SSH servers, Kubernetes clusters, or databases.
Expanding your knowledge on Sharpen Your Security Skills with Open Source! Introduction to Modern Infrastructure Access
Learn more about Sharpen Your Security Skills with Open Source! Introduction to Modern Infrastructure Access
Introduction - Sharpen Your Security Skills with Open Source! Introduction to Modern Infrastructure Access
(The transcript of the session)
Secure access to complex computing environments is hard to get right. Introducing the open source identity-aware access proxy: Teleport. It is used by engineers at smart companies Nasdaq and Google, to easily access all to their computing resources — SSH servers, Kubernetes clusters, or databases. For security professionals, Teleport uses short-lived certificates, audit logs, and session recordings to make it easier to achieve high security standards and compliance. In this webinar, we will go over what Teleport is, what some of its key features are, and talk through some use cases. You’ll be a https://goteleport.com (semi-)pro in no time!
Allen: 00:00:00.409 Well, good morning or afternoon or evening wherever you're at. I appreciate you all taking time out of your busy schedule to attend today's webinar. And we're going to be talking about — if you're wondering what it is, we're going to talk about Teleport: A Brief Overview of Teleport for Beginners. So I'm your host. Allen Vailliencourt is my name. I'm a sales engineer here — I cannot talk. I'm a sales engineer here with Teleport and been part of the team for a couple of months now, I think since February, and live here in South Carolina. So before I jump in technical, I always like to brag on my family because I do what I do because I love them. I've got two boys that are full of energy, and we have a puppy that is our new addition to our household over the last few months. So it's been enjoyable having her. It's like having a kid all over again, trying to figure out potty training and all that. And then the top right, just something fun, a little bit geeky, I like to play and collect speed cubes, Rubik's Cube. I'm not the fastest person in the world, but it's something I do enjoy. It's a great fidget cube, stress relief. So if you're ever on a really long virtual seminar, hopefully not this one, and you find yourself needing something, picking up one of those, I think, will be a lot of fun. But also, a few housekeeping rules as before we kind of dive into this. We have chat and Q&A, so please raise your hand or type in a question or feel free to ask any questions. I want this to be informative for you. If you're new to Teleport, you've never seen it before, or you've heard a little bit about it, we are going to cover a few slides, the basics of it and then dive into a little bit of a technical demo. But just want to throw that out there along that line.
What is Teleport?
Allen: 00:01:49.570 So, anyways, let's begin. What is Teleport? When we hear that, people say, "Hey, what is Teleport? What does it do?" Well, in our parlance, our language, as we call it, it's an access platform. And you're like, "Okay, so what's an access platform?" In essence, what it says here, right, we're allowing engineers and security professionals, DevOps, you name it, to unify your access across all kinds of environments and behind NAT translation, whether it's server access or SSH servers, Kubernetes access or Kubernetes clusters, application access, and database access. Those are our four key pieces there with some new additional stuff coming down the pipeline, which is super exciting as well. And what we're doing with it is we're trying to simplify how our engineers, how users are accessing these resources. In the traditional world of doing things or seeing things, you have this tension in three areas. You've got access workflows, giving people the permissions and rights and roles to access things that they need to do; managing those credentials, whether it's SSH keys, usernames and passwords certificates; and then you have this compliance and auditing piece, which is huge, right, for your PCI, SOC 2, FedRAMP, a variety of compliance and auditing type of things there. And you look at the scales, our illustration here and how that works is you've got a security team in a company that is like, "Hey, we need to have all these in place." But what happens if you have too much of that — that agility piece of a company disappears, right? You have more layers to go through, firewalls are locked down, VPCs are tight, permissions. And it can become cumbersome. So companies that are trying to be more agile, be more DevOpsy, and automate things, it can get slower. You go the opposite side and you get too agile, right, you're just whoo, it's the Wild West, and now you get security issues that kind of go out the door. So trying to balance those is, I think, always a challenge with security teams, with DevOps teams, and everyone across the board.
Identity certificates and RBAC
Allen: 00:04:12.357 So our goal with Teleport is to kind of simplify some of that and hopefully alleviate some of that pain. So how do we do that? We do that with one way of using identity certificates. So in a traditional environment — so we'll go back to SSH servers as an example, if your users are traditionally used to using public-private keys to access these resources, there's some other issues along that line as far as what happens when the user moves on and what happens if that key gets compromised, etc. So we do that with things — we eliminate some of that by using SSH certificates along with x509 certificates. And so you're talking to an IDP, your SSO provider that supports SAML IDC and you're getting these short-lived certificates that then now have things here illustrated like permissions and who you can talk to, what environments, and then you have an expiration time. So it's not out there forever. And that's all based on roles, right? We use heavily role-based access control, which in today's world is really king of managing access to anything, whereas in the old days and maybe even in your environment today where you just throw a permission, everybody has admin. Well, now with the maturity of RBAC, you can leverage that and really get granular, right? As an example, user A, James is an admin, or maybe John Smith is an intern or a developer. So by using role-based access controls, you really get a chance to limit and manage that. And so Teleport uses that heavily for access.
Session recording and audit logs
Allen: 00:05:59.428 And then another piece of the puzzle which we'll show here and it might be a little hard to see on this little animated image here is the ability to view and see what's happening in your environments in real time, like live session recording, audit trail, audit logs, and all that stuff. So we kind of tackle that as well. And then session sharing — this is a virtual webinar, right? So people are attending probably all over the world. And so maybe you work for in your company where employees are all over the world. Like our company, we're a distributed company. We've got employees all over the United States, all over Europe, Asia, even Australia, and everything. And so that can be challenging if you need to share access into a system. So using a tool like Teleport, you can actually share those sessions and enable other users to log in and gain access in order to see what's happening.
Access requests
Allen: 00:06:57.812 And then we have another piece here where from a compliance audit standpoint, especially from a security team, right, or change control, being able to have access requests, being able to grant users limited access or one-time access kind of on demand. So an example here we're showing whether it's Slack, which you can get notifications or maybe something like JIRA, where you can go through an access workflow. So you can use some of that with our API to tie into that. And then underneath it all, Teleport is an open-source project. It has been open source from the beginning, and we'll have a link here in the slides here at the end where you can actually go out right now and see the issues that our team is working on, look at our pull requests, look at our roadmap, and actually get involved within our community as well. So these are your lines — so who uses Teleport? And as an example, just right here, I've got a couple of logos Nasdaq, IBM, Snowflake, for example. If you go on our website, we do have a list of more enterprises that are using it. But Teleport, both its open source as well as our enterprise version of it, is being used by companies all over the world to manage access to systems wherever they're at. And we'd love to know if you're using it today, maybe in open source, let us know as well. Because being that it's a GitHub project and it's open source, we don't necessarily know who may or may not be using it.
How Teleport works
Allen: 00:08:33.505 So from a high level, let's kind of dig into what Teleport looks like before we jump right into it. So we have an authentication server that you see right here, and then you have a proxy that sits in front of it. So that our server has a certificate authority behind it that is signing the short-lived certificates for users. So let's say I'm a developer and I need to gain access to — whether it's an SSH server or Kubernetes or database. I'm going to log in to Teleport using whatever tool I'm used to using whether with the web or a command line. Now, Teleport is going to talk to your SSO provider, and that's where you store your source of truth. So let's say my SSO provider is Okta or Google or GitHub. So it goes there and it sees John Doe — or it sees Allen. It says Allen logs in and says, "Hey, Allen should be an admin" so then it passes that information back to Teleport and says, "Hey, according to this user logging in, he's an admin and he should have admin rights." So then Teleport issues, oops, a short-lived certificate for this user that now gives them permissions of what resources they can access. And then, of course, that certificate has time to live on it, has other metadata as we showed earlier of what that user can do, etc. And then as an end user, I'm now able to access and do the work I need to do on my systems. And in the background, Teleport is auditing this information. So from a compliance standpoint, I'm now able to audit this information, push it out to a SIEM if I'm using something like Splunk or a Datadog or LogRythm. And then now I can build telemetry and I have auditing compliance that I can tie into this as well. Then as I mentioned earlier, we have that access request portion of it where you can use Teleport to — we call it ChatOps, right, leveraging other tools to build these workflows, these one-time access requests that might come across the board.
Demo time
Allen: 00:10:42.757 So being down that part of the piece, we're going to jump right here into the demo aspect of it here. And so I'm going to show a few things on the demo. I'm going to show the UI, I'm going to show the command line as well. So let's jump into that as I switch context here. All right. So let me go here. So in this piece here, so what I've got is two pieces here. I've got my Teleport login tool. That's right here. I'm able to log in and access something on Teleport right here. So I'm able to get into it. I've got a couple of SSL providers that are listed here, and these providers are basically my source of truth, who I am that I say I am. So we're going to log in here using Okta. I also have a terminal here. So I'm going to show how Teleport works from a terminal access command line. So let me zoom this in here a little bit. There, so we can switch contacts a little bit easier. So I'm going to authenticate to Okta. I've already signed into Okta on the backend. And so what Teleport does is it draws me into the UI where, immediately, I can see based on what roles I have, pieces of what environments I have access to.
Allen: 00:12:07.915 So, for example, because I'm an administrator, it drops me in and I can see everything. So in my environment, I've got one, two, three — I got six different servers. These servers can be anywhere in the world. They could be edge devices, they could be a Raspberry Pi, they could be bare metal, they could be VMs. In my instance, I'm running a couple of servers on Google Cloud, I'm also running a couple of servers on AWS. And so because I'm an administrator, I have access to see all of this information. Same thing on a command line. You can see that I have logged in as a different user and Teleport has issued me a certificate that's valid — well, when I did this, seven hours and 54 minutes left. In fact, if I go refresh this, you can see it's dropped a little bit. So even from here, I can now see all of the servers I have available as a user.
How RBAC in Teleport works
Allen: 00:13:02.340 So how does Teleport manage that? And this is the part where it comes into that RBAC, role-based access control. So let me show you that. So because Okta says, "Hey, you should be an admin. I come across with Teleport. I'm issued an admin role." So I go in here within Teleport, and I can see all the different roles that are available as an admin user that I can assign to different people. This is my admin role. For those of you that are looking at this saying, "You know what, this looks a little bit like YAML," you are correct. It is YAML. So if you're familiar with are using YAML from just infrastructure as code, Kubernetes, this is how we have built a lot of the configuration files, raw files is all on YAML so it makes it easier to digest, easier to use and adapt with different tools. So me as a user that has administrative rights, I'm able to see pretty much everything within my cluster. And now granted, do we want to give everybody admin rights? Probably not. I know in my old sys-admin days it was just sometimes easier when you have a small team and you trust someone, you just give them admin rights to a system. But in today's world where you got dynamic environments coming up and down, you got production systems, and development systems, this is where you want to really define those roles and limit what users can and cannot see. So as an example, having a contractor, they don't have access to anything. So as a contractor, they cannot see any resources, but they do have the ability to request additional access into it using our Access Workflow engine.
Allen: 00:14:47.226 Out of the box, Teleport has four roles. So if this looks a little overwhelming, this is a demo environment. So I'm always playing and setting up different roles along that line. But if you go out there today and pull down our open source or start our cloud trial, you're going to see four roles out of the box. We have an admin role - excuse me - an auditor role, I believe an editor role as well, and then a developer role. So there's a couple of high level roles that are out of the box that you can use as templates. On top of that, we also have a Terraform provider that recently came out. So we encourage users to leverage Terraform and infrastructure as code best practices, build your roles, then store them on a Git repository, GitHub Bitbucket, GitLab, wherever. And then you can leverage our Terraform provider in order to update and manage roles. So going back to this, so I'm an admin, and we can even go on my user screen, and we can see that I'm logged in here, and it says, "Hey, this person has an admin. They also have AWS console access." And even lets me know how I'm authenticating within Teleport. My one user is authenticating using GitHub and my other user is authenticating using SAML. You do have the concept of local users within a Teleport cluster, and it's great for testing and proof of concepts. But probably from a production standpoint, you probably do not want to have a whole bunch of local users just because that's all stored within Teleport database and a little bit more to manage on that line.
Tying in an authentication connector
Allen: 00:16:22.995 Tying in an authentication connector is really easy as well. So as you saw at the beginning there, I had a whole bunch of them, and this lists all the details of these different authentication connectors. So as an example, if I go to my Okta connector, this shows me everything I need to set up. Again, it's in YAML. I can map my groups to my users and what I need to do in order to leverage an OIDC or SAML compliant. We do get a lot of question about Azure Active Directory. Even though I do not have that setup, we do have full support for that. So as long as something is SAML or OIDC compliant, you can easily plug it in here within it.
Server Access
Allen: 00:17:04.586 So let's segue a moment and jump into the server portion of it. So how those roles define what you can see — what you can and cannot see. So as a user and let's say from a command line — because most users are probably not going to do work from a browser but for demo purposes, we'll show that. So I'm a user. I'm logged in to my Teleport system. I've been issued an eight-hour certificate. Basically, it says you're valid, and I can log in as any of these users if my back-end Linux system support those. So I'm going to go ahead and log in to this. So I'm one user. I'm going to log in to Ubuntu, AWS, server one. I don't have to know the IP address. I can use it by the node name, which I'm connecting here. You can also connect into a system using key value pairs, which is another neat way of accessing. If someone is like, "Oh, I know it runs this application. I don't remember its IP or its hostname, but I can log in that way as well." So for this instance, I'm logging in. Oops. It helps if I actually type in the right command. There you go. So I'm going to log in. A tsh is our binary. It's a Teleport binary. It's basically a replacement for SSH that adds a few other really cool features to it. So I'm going to log in to the server. So it's going back proxying through Teleport and saying, "Hey, do I have rights and privileges because my certificate says I do? And based on my role, I have access to it as well." It lets me in. I am now on my server. So I can run really high quality production applications like dad joke or whatever else that might be out there.
Allen: 00:18:50.498 So I'm on this server running commands, doing what I need to do as an administrator on the server. Here's some of the magic that's happening on the backend from a Teleport perspective. And this is underlying what I'm going to show here from our audit log. And things like this is kind of the core of what Teleport does for, really, all of our protocols. First of all, I have an active session. And what this does, Teleport's letting me know if I log in to the web UI it's like, "Hey, look, a user is actively connected to a resource right now." It even gives me the IP address where they're connecting to, what the user is, and then even the node that they're connecting to. I also have an audit log. So Teleport has the ability to log this information. This is the critical piece where we talk to companies and users that say, "Hey, we need an audit or a compliance — we need something along that line." So now I've got an audit log that is auditing what is happening within my cluster. So when I run a command like figlet or dadjoke, it is pulling this information across from a binary. Now, this really detailed logging is an option that you can turn on in Teleport. It's basically BPF or Berkeley packet filtering. It enables Teleport to do kernel-level auditing of commands. So as an example, when I type in dad joke and it just looks like a generic you type it in, you get a joke back, and you don't think anything of it. But underneath of it, Teleport realizes that that was a cURL out to a certain website. So with BPF turned on, it does a little bit of a granular kernel-level of understanding what that command was. So we can see it was a cURL, and here's the destination IP that I was cURLing to in order to pull the latest dad joke of the moment.
Allen: 00:20:53.899 And so things like BPF enhanced, recording is great when you got environments or areas where you need to have really detailed logging within your systems. By default, it's not turned on out of the box, but it is an option that you can turn on within your servers. So let's go back to our active session puzzle here. So let's say I'm on a server and I'm doing work and I'm here in South Carolina where I live and I'm stuck. And maybe my boss is somewhere across the US, maybe he's traveling or she's traveling, and I'm not able to get — and I'm stuck. As an engineer, I'm stuck. I can't just walk over to their desk and say, "Hey, can you look at my screen and share." We might be able to fire off a Zoom like this or a Google Meet or Teams and share screen and "Hey, click this. Type that. Do whatever." It makes it a little challenging. So what we can do with Teleport — you actually can join a session. So what I'm doing now is I'm actually joining this session. So as a user, I'm already logged in here and I say, "Hey, I need help." Maybe an admin, another developer can come along and they could say, "Oh, wow, cool. Here's the issue. Let's hop in." So now we can collaborate and work together on the system. So commands typed in one screen are going to show up in the other. So if I'm troubleshooting something, looking at what's happening within the system, we can go back and kind of collaborate, talk through, and figure things out. On the Teleport side, it sees that a secondary user has connected. So we can see that "Hey, our sessions are adjoined —" someone else is on that session. So let's say we're done, we finish our work, we're going to clear it out, and now we're going to exit. All work is done. Everyone's logged out of the system. I go back to my session screen within Teleport. That session is no longer active. It's gone because it's not an active session anymore. And this is where the other piece here of Teleport happens is it uploads a session recording of what? Of the session. So I can go back. And maybe we had an event that happen on an evening or during a deployment and you need a postmortem or just from a security aspect. You want to audit what's happening. I can go and playback the session and see what's going on in my cluster. So for this aspect, I can say, "All right, so this user's on the system. He's running dadjoke a few times and typing in different commands and whatever." I can pause this. I can fast-forward if I wanted to. I can rewind. So Teleport gives you the ability to do that. I could even take this session recording and play it back from my browser — I mean from my command line. So if I have the rights and permissions — because my local user is also an admin. So I can hit play. And now I'm doing a playback within my command line environment as well.
Allen: 00:24:04.643 So it's a great tool from that kind of auto compliance. And you can even go back within Teleport, look at my last seven days so you can see all the sessions I've been doing over the last couple of weeks. Maybe somebody says, "Hey, do you guys remember that July 4 incident where somebody put fireworks on the system?" So let's go back and look at what happened on July 4, within that range, and let's go playback these sessions and kind of see what was happening within our cluster. So you have the ability to do that with our session playback along that line. And it's a great way to get an introspective of something happening, see activity on it, especially if you have new engineers or your onboarding. We have some customers that use session recordings as a way to — postmortems when they're troubleshooting or even onboarding new engineers. So it's a lot of options you have along that. All of your servers and you're probably wondering, "Well, I could just access these servers however willy-nilly, wherever they're at." Well, and this is one of the neat things about it is that these servers that I'm accessing, none of them have public IP addresses or public access to that. So my AWS servers, they only have an internal IP address. My GCP servers have internal IP address. So the only way to get to these is through Teleport or via AWS console, web console, or command line AWS, or even the GCP SDK, the G Cloud Compute command line options. So I'm accessing systems across the world that are doing work on it, able to do it because the reverse tunnel back to the cluster. So for environments where you've stood up bastion host or you're using a VPN, you can eliminate those by leveraging Teleport. In essence, it becomes that bastion host but with some added things there. I don't have any keys on these servers. I don't have any users on them except for a couple that — the Ubuntu user that I've created because of our Ubuntu boxes. But they're all reverse tunnel now, so I'm able to do work on them as an end user. So no matter where your systems live around the world, you're able to do that with Teleport and manage it along that line.
Application Access
Allen: 00:26:28.718 So I'm going to segue here. We're going to talk quickly on the application piece here, the next piece of our access platform and how that works. So our access platform is basically like a web application proxy for it where you can put private dashboards like a Grafana dashboard or in my instance, maybe a private GitHub type of repository out there, and I can put it behind Teleport. So that way, instead of using a VPN or whitelisting people's IP addresses, we can just give them permission to say, "Hey, you as a user have rights and permissions to access this application. You have to do it through Teleport." So I'm doing that. So Gogs is an open source self-hosted GitHub is running on one of my servers. It's only running in one of my servers that has a private IP address. So that's key. The server does not have a public available 80 or 443, only through Teleport. So I'm able to access this from within Teleport if I have the rights and permissions. So maybe I want to log in to this box here and do my work as a user. Let me see here Gogs admin, and I can sign in. And now I can run my dashboard, I could do my pull request, I create issues, or whatever I need to do as a developer or engineer. Teleport is going to audit certain information on an application. So it sees that an application session has started, but it's not actually logging my interaction with that application. It's something Teleport does not do. So it can gate access to this application and allow me to get to a public or a private application, but it's not giving me — it's not auditing what's happening within it. So it's just something out of the box that we do not do.
Allen: 00:28:25.794 Well, if you say, "Well, what if a user bookmarks this? Because I get a fully qualified domain name, and so maybe a user is going to bookmark that and say, 'I'll just go to it directly.'" So they save it, they type it into their browser, and here's what happens, Teleport says, "Hey, you're trying to access an application that's gated. You don't have access to it. So you need to authenticate. You need to log in." So I'm like, "Oh, great. So maybe I'll log in as my user." So I'm going to log in here as that contractor user. Let's get my password for that one because I use randomly generated passwords for everything. So I have it stored that way. Oh, it wants me to authenticate it to a different thing here. So let me get my other security code for that one really quickly here. That way, we can sign in here and say, "What is this user trying to do?" So bear with me a moment there. Seven. And I do recommend that in your environment, you do set up MFA or two-factor authentication. It can be a little bit painful at times trying to manage something like that, but in the long run, from a security, with today's data breaches and things like that, definitely set something like that up. So what happened here is, right, I logged in. I authenticated to GitHub as a contractor user, but then it bounces me back to this application and it says, "You know what, it's not found." The reason being is because as a contractor, I do not have rights to this application. So let's go back in my contractor role here that I'm authenticated in as. And I'm not allowed to access any applications, but I can request access to these applications. So let's say I go back here, and I go to my screen, and I don't have any applications, but maybe I need access to something. Well, I can actually access — or request access to this application.
Allen: 00:30:34.210 So for this instance, maybe as this user, I say, "Hey, I need access to this Gogs app. Please let me in to do my work." So I'm going to fire that off. And I'm going to segue this application access into what we call our chat ops kind of model or thinking on that line. So this is where it comes in where if you have something set up within Teleport from a chat ops perspective, now you can kind of see what's happening. So I fired off that request because a contractor needed access to Gogs, and they don't have it. So my Slack bot there says, "Hey, we have a new request coming in. A user needs access to this application, can someone approve it or deny it?" I could click this link. It'll open up my browser on another window here, my other browser. So for instance, for this case, I'm just going to go here to access request, and I can see it. So let's view it. I could approve it or deny it. I can leave a message. And there's a whole threshold of different things you can do with access requests, multiple users to approve or deny, etc. "Don't commit to production," or whatever I want to say as a note to that user.
Allen: 00:31:53.305 So what happens now is my access request gets approved. I have a little thread going on here. So I've got this kind of audit trail of what's happening. Now, as a user, I can refresh the screen, and I can see that "Hey, it's been approved." So now let's assume this role. So I have assumed an app's role. And so by doing so, if I go back to my application screen, I am now able to see this application that I need to now log in to do my work. So I can fire it off, I can launch it. It's going to drop me into that page and grant me access. I can sign in with my user and kind of go from there. And so on and Teleport side, again, from an audit section, we've got an access request created. We can see a request was created by the contractor, what the reason is, what the role is, and then it was reviewed, and then they had started that session.
Kubernetes Access
Allen: 00:32:51.031 So I kind of tackled two birds there. Quickly, one, application access, how Teleport manage and gate some of that. Then using our access workflow to allow users to gain access into different applications or tools as they need to. So let's segue here to the third piece. And I know this seems as — you're probably looking like, "Wow, that's a lot of info." Again, if you have any questions or you wanted to see something just raise your hand or type in the chat and happy to answer any of that as it comes up. But in the meantime, let's segue to the Kubernetes piece of the puzzle here. So I have access to one Kubernetes cluster. That's all I have set up. And I can actually look at it here as well from within my Teleport command line tool. So now I want to gain access to it. So I want to make sure I'm authenticated in. So I'm going to go ahead and log in. And what this does if my context has not been set already, it's going to set my kubeconfig file so that I have access to this Kubernetes cluster. So according to this, I've been granted access and my kubeconfig file has been set. So now I can actually get information about my Kubernetes cluster. Because I'm system masters, it's going to get me all my namespaces, I can get my pods. Because it's my default one as an engine [EKS?] pod, so it's showing that one. So on the backend, similar to our application and our server side from an audit perspective, here's what's happening, Teleport sees that I'm making requests into Kubernetes. And because Teleport is protocol aware and knows, "Hey, this is a Kubernetes API call," so we're going to log it, we're going to keep track of it, we're going to really dig down and know what that user is doing. So if I use a tool like Lens — which a lot of customers use because yes, we can do a lot of Kubernetes stuff from the command line, but using a UI tool is a little bit easier. You get a little bit better dashboard to view and what's happening out there. I can log in to that and because I'm connected in my certificate is valid, Lens is going to populate everything that I need to know about the cluster. My auto log is going to get really busy really fast because I'm the Teleport user Valien that's making all these kube API calls via Teleport. So I'm in here looking at my config maps if I have any, my secrets, my game sets, etc., Teleport is going to audit all of this information. So it gives you really good visibility into Kubernetes activity across the world, different clusters that you may or may not have.
Allen: 00:35:46.707 One thing that's really cool on the Teleport side here is the ability to do session recording of Kubernetes execs into pods. So example, I have an NginX pod here, right? And normally maybe we're not SSHing into any production pods, but for this instance, we had something going on and a user needs to gain access to figure out what's happening on the pod itself. So they exec into it, they're doing work, and then they log off. And no harm done or maybe that pod crashed and then replication control will spawn out a new one. A couple of things, we're going to see our continued Kubernetes access and even our session requests knowing that "Hey, we've started a session within that." But then at the end there, Teleport's going to actually upload a session recording of that interaction into that pod. So I got my cluster, I got my namespace, and then the pod itself. And actually, you can go back in now and playback. So you say, "Hey, why didn't our production pod crash? And what happened there?" Well, we got a session recording. We can see that John Doe was on this box, and they were running some commands, and here's what happened. So, again, we do session recordings on SSH as well as Kubernetes, which provides insight and ability for companies and organizations to see what's happening within their environments on that piece. And if I log out of my Kubernetes, when I do log out, my ability and access to these systems is now revoked. And I'll show that here at the end.
Database Access
Allen: 00:37:24.853 Our last piece of the activity of our four main parts here is our ability to leverage database connectivity. And similar to my SSH nodes here, I have a whole bunch of databases some on AWS, some on GCP. None of these databases have public IP addresses, public ingress into them. They're on private network, and they're not able to — no one can get to them. If I try to run queries on these databases, nothing's going to happen. It's going to error out because I just don't have access to it. But according to Teleport, I should have access to it. So let me look here and look at what rights I have to a database. I see I have four of them. I'm able to see, but I'm not actually authenticated into any of them. So I'll go ahead and log in to my AWS or MySQL database. So what this does, it sets a different certificate that is just for the database connectivity. So I still have my SSH certificate, but I'm now getting a short live x509 certificate from a database sign that gives me the rights and permissions to access those databases. And I can actually look at them — well, it's deep here in your hidden folder called tsh where your keys are stored.
Allen: 00:38:48.512 So now that I'm in here, I put my cluster name for that database and it has connected me because it sees that I now have a valid certificate. So now I can run my queries on this database, and get the information that I need, and do my work as a DBA or a data scientist or however I need to do. So let's pivot back here to the audit log. You're probably seeing a pattern here, right? Everything that we do in the front end from an access, Teleport is logging and auditing it on the backend. And because it's protocol aware, I now see things like database queries. We can see that "Hey, this user has connected to this database." And here's the database URI. It's a private database, 3306, even though I'm only accessing it via 443 in my client. I'm logged in as this database user because I've been assigned that role. So I have permissions to that. And now, I can run queries on that database itself. I'm running a select all from employees. So if somebody says, "Hey, this table crashed or something went bad and whatever." "I didn't do anything." Through Teleport, you can say, "Well, we see here you did a drop table," or "you deleted that user," or "that whole row," or "column" or whatever it is. Teleport has that audit where it's transparent to an end user. They're just able to access their systems. They're able to do the work that they need to do from a day-to-day perspective. But on a security compliance standpoint, you have this nice trail that you're able to see what is happening within your cluster. And that's the whole premise of it, right? When we look at that slide at the beginning, Security and agility. We want our devs to be able to access things quickly without a whole lot of roadblocks. But yet we want to have that security piece there to manage and to audit and track what's happening within our system. And so those are the four key pieces here of Teleport. The four that we have, right, from our access platform. So let me go back to our — we'll go back to our slide here in a minute. So going back here at the beginning — right here. We got server access, Kubernetes application and database as well.
Q&A
Allen: 00:41:10.149 So I've got a question here from user David, "Is tsh uploading the session recordings from the client? Or is the recording actually done on the server side?" So it's actually done on the server side. So my client here — so the server that I'm SSH into is recording that, and then it's uploaded on the backend. With SSH, that recording is basically done — when that session terminates, it gets uploaded immediately. From a Kubernetes standpoint, it's streamed. The session recording is streamed in basically real time. You could change that on the SSH side to change it to real time. That is a Teleport configuration that could possibly be done. So, yeah, so as a user, if I'm trying to manipulate something here locally with my tsh client, it's not going to work. Great question, though.
Allen: 00:42:01.473 So segue back here, as I mentioned, we're an open source project, and this is our GitHub repo. You can see we've got 10,300 stars now, and it's a very active project. You can actually see what's coming down the pipeline. And I just want to give you a heads up. We have a version 8 coming down. So we're on 7.3, but we actually have a version 8 that's coming down in a couple of weeks. And it's going to be pretty amazing because it's going to have Windows support because I noticed in my slide here, I showed we had Windows support, but it's not there yet. So it's coming. It's in alpha right now — or beta. So we got Windows remote support. So enterprises that need Windows support, you're going to have the ability to do that, plus other cool features, being able to access more databases and some other things coming down the road. So going back here as we kind of tail out here, how do you get started with it today, right? We've got open source. You can hop in on GitHub. You can contribute in there. We got a Slack community where I'm on there, a lot of our sales engineers, even our developers and other support folks, a community help for people running the open source version or just have questions around it. We do have a free trial. So we have two options. You can host Teleport in your own environment today. Actually, we also have a SaaS version of it from an enterprise side. So companies that don't want to deal with that infrastructure piece of it, so you can actually go and sign up there. And then our discussions we have along that line as well.
Allen: 00:43:44.930 And I've got another question here, "Does Teleport support Keycloak as an OIDC-SSO in the community edition along with GitHub?" It only supports GitHub. That is correct. So some of the key differences between community, open source, and enterprise is the community open source only has GitHub as its primary SSO provider. So you can use a local username and password, or you can use GitHub as your SSO. So if you need something like Keycloak or GitLab or Okta, Auth0, that does require our enterprise version for that. I also want to give a shout out to us as a company. I've been here since February, and we have probably doubled in size since then. We are a series-B-funded company. And we've got, at least as of couple of days ago, 30-some openings across engineering, sales, product marketing. And we're a fully distributed company. So we've got somebody that works in Nepal, which is super awesome; somebody in Alaska; a couple of folks in Australia; a whole bunch in Europe; and of course, Latin America and South America and the US and Canada. So having a distributed company is what we're all about. And so if you want to be involved with a company building really cool open source products, love to see you guys — see anyone apply.
Allen: 00:45:09.140 How to get a hold of me is there's my contact information. I am on LinkedIn. I am also in our Teleport Slack community as Allen Vailliencourt. I'm on Twitter. If I do tweet, it's usually something around Teleport or food or my dog or board games. But feel free to shoot me a connection there as well if you just want to connect professionally, ask any questions or via email, happy to help along that line as well. And I know we have a few minutes left. So I want to say thank you for hopping on today's webinar. And if you have any more questions, well, we'll leave it open here for another minute or two and answer any questions. Or if there's something — because we have a few minutes here, could we go for, I think, another 10 minutes? If there's something you want to see a little bit more detail on the demo side, I can also show that off as well. And of course, our website, goTeleport.com is where it all starts. So I know that was a huge whirlwind of content. It's a whirlwind of what Teleport is, right? End of the day, we're trying to solve these issues for our engineers and trying to make life easier for them by simplifying that access and agility security through point.
Allen: 00:46:35.830 I've got another question here, "There used to be a HAR format recordings for our web apps, is that still a thing?" That's a great question because I do not know. So I'm going to write that down because I am not aware. I know for our web application piece, it's there and it works really well. We have AWS console access now and a few other things, but we're not recording what's happening on the backend. There is some roadmap thing for building out the web application piece there and getting it, but our engineering team is growing, and they're trying to prioritize different features, and right now, a lot of the focus is on the cloud, Kubernetes, and database side of the fence. But I can look into that just to find out if there is a HAR format on that. I am not aware of that off the top.
Allen: 00:47:37.314 Oh, and let me show you one thing, what happens when a user logs out, right, as I'm authenticated in? So I'm going to go ahead and log out. So I've lost access to my Kubernetes. So I'm going to get an error on Kubernetes because my kubeconfig is now gone. So if I use my tool like Lens that is here, it sees that it's also gone as well. So I'm not able to access my cluster because that kubeconfig. So that's one piece from a Kubernetes standpoint where if you have different clusters and you don't want the user to keep those kubeconfigs on their system, using a tool like Teleport that manages that for you, then you don't have to worry about those kubeconfigs getting compromised or taken out there or whatever because Teleport is managing that access to those systems as well. So I just want to show that piece of the puzzle.
Allen: 00:48:35.093 "Other than Terraform, is there API access?" There is. Our API is a GRPC-based API. So in our documentation here — let me fire it off real quick. So right here in our documentation, we have an API section that gives a little bit of introduction of what you can do with it, how to get started, and some of the architecture behind it like creating a user or whatever along that line. And there's some examples as well in our GitHub for that. So from the API, that's what it is, not a full on kind of web API. We do have another project — so we got Teleport as our primary project, but we have a Teleport plugin — maybe it's plugins. There is. So we have another project called Teleport plugins. And this is where like our Slack plugin or our Terraform provider is here — this is where a lot of information is built along with some API information of how to create your own plugin because we've had users asking, "Hey, we use this tool or that tool, can you build a webhook?" So instead of making a feature within Teleport that now has to be managed, our engineering team has kind of basically said, "Hey, you can build a plugin that interacts with Teleport for that," so like JIRA or Slack or Mattermost. One of our more recent plugins is an event handler plugin. So if you're using Splunk or LogRythm, Devo, any kind of big SIEM out there, you can actually run an event handler plugin that lets you forward or export your audit logs out from Teleport like a Teleport cloud or different nodes, and forward them into a SIEM of your choice. So that was something relatively new. You can see examples of how it's all built. Everything, for the most part, is built in Go from Teleport. Good question, though.
Conclusion
Allen: 00:50:43.123 All righty. Well, I'd give you guys a couple of minutes left here. So, again, I appreciate your questions. Again, look for a follow-up. If you have any questions, let us know. We're here to help you all on your journey as you're digging into what Teleport is and all that. But I appreciate your time today, and I hope you have a wonderful rest of your day.
Join The Teleport Community
