Securing Your Cloud Infrastructure with Teleport and AWS IAM
Securing Your Cloud Infrastructure with Teleport and AWS IAM - overview
Watch this webinar to learn about the challenges in securely delegating access to your AWS resources. Specific topics covered include:
- How companies are currently managing their AWS infrastructure
- Integrating Teleport Access Platform with AWS IAM
- The top 5 advantages of using Teleport to access AWS resources
Key topics on Securing Your Cloud Infrastructure with Teleport and AWS IAM
- Teleport is the easiest, most secure way to access all of your AWS infrastructure.
- Teleport's strategy is to remove the inherent conflict between developer productivity and security, and it is designed to cure the pain of scaling access.
- Using Teleport Connect, you can securely connect to your global infrastructure regardless of network boundaries.
- AWS IAM Identity Center (successor to AWS Single Sign-On) enables centrally managing access to multiple AWS accounts or applications.
- AWS IAM Identity Center helps you securely create or connect your workforce identities and manage their access centrally across AWS accounts and applications.
- Use IAM Identity Center to securely scale access across accounts and applications, supporting your workforce agility and workload innovation on AWS.
- The 5 advantages of using Teleport to access AWS resources are fine-grained control of each AWS service; consistent experience in using AWS Console and CLI; simplified RBAC; Just-in-time (JIT) elevated privileges; and insights through AWS CloudTrail and Teleport Audit.
Expanding your knowledge on Securing Your Cloud Infrastructure with Teleport and AWS IAM
- Teleport Passwordless
- Teleport Machine ID
- Teleport Server Access
- Teleport Application Access
- Teleport Kubernetes Access Guide
- Teleport Database Access
- Teleport Desktop Access
Learn more about Securing Your Cloud Infrastructure with Teleport and AWS IAM
- Teleport Labs
- Contribute on GitHub
- [Join our Slack community]/(community-slack/)
- Participate in our discussions
Introduction - Securing Your Cloud Infrastructure with Teleport and AWS IAM
(The transcript of the session)
Allen: 00:00:02.338 Well, let's go ahead and kick things off and as more people are coming in. Again, this is being recorded, so we'll have the ability to get this out. So if you came in late somehow, didn't hear me talk this — but we'll get going. But anyways, we're going to go. And welcome to today's webinar. And my name is Allen Vailliencourt. We'll get introductions here in a minute. But this webinar, we're going to be talking about securing your cloud infrastructure with Teleport and AWS IAM. So really excited about talking about Teleport as well as integrations with AWS. And we're going to kick things off here. As a brief introduction, my name is Allen Vailliencourt, I'm a partner solutions engineer here with Teleport. I've been with the company for about a year and a half now and excited to be on today's call, kind of walkthrough. And we also have Benjamin as well. So Benjamin, go ahead if you want to do an intro. And then, we'll kick it off.
Benjamin: 00:01:00.119 Yeah. I'm Benjamin Gardner, I'm a senior partner solutions architect at AWS, and I support startups.
Allen: 00:01:08.231 Awesome, well, thank you. So we've got him here. And a couple of things here, we got a Q&A time here at the end of today's webinar. So any questions you have, please drop them in the chat, and we'll get them answered as best we can here. But I want to make this informative for everyone involved. And hopefully, as you leave today, you'll leave knowing a little bit more of what we're doing and how we're doing it. So to kind of kick things off here, just want to get going a little bit of today's agenda, right? We're going to talk, high-level, of what is Teleport. For those that are new to Teleport or were not on one of our earlier webinars, I'll just go high-level of what is Teleport. And then, Benjamin is going to jump in and talk a little bit about AWS IAM Identity Center, which is really cool. And then, we'll jump back into, right, talking some of the challenges, right, enterprises, how are enterprises managing their AWS infrastructure, challenges of securely delegating access to AWS, integrating Teleport with AWS, and then finishing out with a couple advantages of using Teleport to access your AWS resources. So we'll go through this deck. We also have a little bit of a technical demo showing some of these pieces here in action of how we're doing all of this. So let's go ahead and kick it off.
What is Teleport?
Allen: 00:02:37.568 So what is Teleport? For those that are new and haven't seen Teleport before, we'll just briefly kind of talk a little bit about this. We call Teleport, really, the easiest, most secure way to access all of your AWS infrastructure and companies and orgs. And I imagine, some of your teams, you have AWS infrastructure all over the world, all kinds of infrastructure, maybe even multiple accounts. And so Teleport was designed by engineers, by our founders, here — two out of our three founders are developers — as ways to access infrastructure just in an easier way, because the current ways we're doing it, which we'll talk about later, can get a little bit of challenging. And our strategy behind this is we're trying to remove that conflict between the developer productivity and security. So in this world of DevOps and DevSecOps, as developers want to move fast and be agile and deploy things, security is trying to put the brakes on things, trying to slow things down because you don't want to be hacked. You don't want to be the next Uber or Rockstar Games or something like that with some sort of breach out there. So there's that conflict between the two. And so part of that involves really a pain of scaling access. Access for small teams, two to three people, is fairly easy, pretty run-of-the-mill, not too difficult. But as you scale, then we start seeing challenges that start happening, challenges with connectivity, authentication, authorization, and audit for software, hardware, and even peopleware. And so these are the four pieces that we're solving with Teleport.
Allen: 00:04:28.696 So going back to that compliance issue, compliance challenge, right, so here's a quick slide, just showing the average cost of a data breach, the average cost per record. And you can see that it's increasing over the years, which can be really stressful for those involved within that. So having a tool like Teleport, signing it into your SSO provider or something like AWS IAM, which can help reduce potential attacks or breaches along that line — so that involves bringing Teleport in. So what is Teleport? Well, it is a zero-trust, certificate-based tool that allows even for just-in-time access and complete visibility for engineers and machines. And we have five protocols, as you can see here, that we cover: server access, database access, application access, desktop access, which is Windows-based desktop, and then Kubernetes access. And so when we're talking about cloud native security, and as a kind of an example, showing here on this slide here for AWS. And it doesn't matter where. Teleport is kind of cloud and network agnostic. But when you're looking at accessing infrastructure, whether it's servers, Kubernetes databases, etc., or applications, it is dramatically different when you're going to the cloud versus maybe a traditional on-prem data center where you had a firewall or a VPN. You're in. But when you add the cloud to that, there's a lot more potential ways of getting breached or something like that. And then accessing it, if not done properly, can, again, be a little bit challenging.
Allen: 00:06:14.840 So the current solutions that are popular in the market today, that are legacy tools or just are out there, are what customers are either building their own or using a hodgepodge of different types of tools. You have perimeter security. That kind of network-only, the firewall-type piece, it's focused on that connectivity. It doesn't necessarily have fine-grained role-based access control, does not necessarily have really decent audit. Shared credentials, using a password vault that a lot of folks use, whether it's a personal password tool like Bitwarden or LastPass or KeePass or even a commercial tool like a CyberArk or Vault or something along that line, having those credentials that might be shared, focuses on that authentication piece, sometimes doesn't really solve connectivity. And then there's some audit and limited RBAC and then legacy PAM, right, the tools that have been out there before the advent and the maturity of cloud native, where a lot of orgs, we're seeing, that have been using it for a number of years, but then have struggled for adapting to cloud-native workflows. And then, trying to use those tools into cloud native, a lot of times, might impact productivity. So we handle it as a cloud-native tool by using short-lived certificates.
Allen: 00:07:38.296 So our access platform, which takes all these four essential infrastructure capabilities, connectivity, authorization, authentication, and audit, wraps them behind short-lived certificates in order to manage access for that. So for example, for Connect, Teleport Connect, right, zero-trust networking. As I mentioned, we don't really care about the networking side because Teleport, it's like, "Hey, we're network agnostic. Wherever, excuse me, your products or your infrastructure lives, we are going to be able to talk to it." We have an identity-aware access proxy that says, "Hey, we've got Kubernetes traffic coming through." It's going to be able to know to route that specific protocol. That it works for users and services, whether it's Allen here or Benjamin or Carlos or Chris or whoever trying to access something, or machine ID or service accounts, it will work. Then, we tie it into that authorization piece, fine-grained access controls for every employee and service for your infrastructure. So we're using role-based, attribute-based controls along that line. We're using access request workflows that help flow, giving users access as needed on an adjusted time basis, and then dual authorization and moderation capabilities as well. And then, the authentication piece here, right, we can authorize someone, but then we also need to authenticate, right? How do we know someone is who they say? And this is where Benjamin will talk about with the AWS piece here, is that identity access management part of the puzzle, that SSO integration, where you're using a centralized place there to manage access, manage users. But yet, we do it based on short-lived certificates.
Allen: 00:09:26.105 And then the audit, all of this is pointless if you do not have a good way to audit what is happening within your environment, if you can't audit session recordings or have detailed audit logs of knowing what's going on, or if you do not have the ability to integrate with any sort of SIEM or security tool along that line. So a couple of our use cases that we have here, right, we've got zero-trust, infrastructure access, audit compliance, password lists, and then modern privileged access management. And then one piece here that I love to talk about, one of the things that attracted me to coming to Teleport is we're an open-source project. You can go to that link out there right now. You can look for it on GitHub. We are actually almost at 13,000 GitHub stars, and it's fast growing. You can see what our team is building and what the public is actually submitting as far as pull requests, issues, contributions from the community. When you look at a security tool that's managing access to your infrastructure, being able to open the engine, open the hood and look in the engine and take it apart and see how it's built is really critical because it gives you better insight in knowing that "Hey, there's no proprietary stuff going on here. There's no potential backdoor or something along that line," because you have an open-source tool that's out there and being continuously vetted and checked by the community itself. All right. Well, I'm going to pause here for a minute. I'm going to switch over to Benjamin. So he's going to talk a little bit about the AWS Identity management.
What is AWS IAM Identity Center?
Benjamin: 00:11:06.614 Awesome. Thank you. Let me bring up my screen. I hope you can see my presentation. Just wanted to give a little bit of background about myself. So I'm Benjamin Gardner. I used to be a software development engineer before I was a partner success solutions architect at AWS. I was also a DevOps engineer. So I tasted both of those worlds a bit. And just to give you some background onto myself, why am I talking about myself and not about AWS IAM Identity Center is because, because I had those two roles, I know how important it is as a software development engineer just to be able to do your job, so being able to push your code and run that code and not have to worry about the infrastructure. That was the DevOps part of my career, was making sure that those software development engineers had that capability. How does that play into what I'm going to show you today, is AWS IAM Identity Center helps with that, right, giving you access easily so you can onboard people fast and have your resources be productive as fast as possible. Just a reminder, as well, is that we recently renamed this tool. So it used to be called AWS SSO. It's now called AWS IAM Identity Center. So you might be familiar with it already.
Benjamin: 00:12:32.187 Let me go to the next slide. So what are we trying to do with this tool? We're trying to match identities and access, right? So we want to have — basically, the best case scenario is that we want to have a single place where we can manage our users and their identities and give them access to the right resources. And we want to take advantage to applications that we might already have with all this available, right? So we don't want to have to do it five times, so every time somebody onboards, you'll have to have an admin that needs to add somebody five times to somewhere. That's not productive. So we want to simplify this process of onboarding new resources and giving the access that they need and make sure that they don't have access to the things that they shouldn't have access to. So that's what IAM Identity Center is trying to accomplish. So going back a little bit, how was this happening? Right? So we used to do cross account trust, right? So before times, we would have one AWS account. You would give access to people that needed access to that account and give them permissions. And then, we saw what was happening was we're going to multi-account strategies [where?] more and more accounts. So we were doing SAML-trust, doing cross-trust accounts. So you could use one account to give access to the other accounts. But they did become more and more complex as you scaled up. And that's something we want to avoid, right? As you scale, you don't want to have more complexity. You want to keep that complexity the same and keep it as low as possible. So as mentioned in the second slide, the admins tasks, create a SAML-trust to each account, that's just a lot of work. Every time you get another account, you're going to have to set up that trust. So that's just more complexity than that you would need.
Benjamin: 00:14:34.662 So we created ways to improve that, right? So you'd have your SAML-federated identity provider that you could pick. So in this case, we have maybe your Microsoft or your Google or your Okta that you would trust and that would give assertion to the accounts and give you access to that accounts. Those accounts, that was all done through IAM. And then, through that, you could get access to all the different — through the different accounts. So that was one way how I used to have to do things, but we thought we can simplify that even further. And that's where AWS IAM Identity Center comes in the picture, right? So what does it do for us? Right? It helps easier management, right? It gives you a central control plane of where you can give access and the roles and the responsibilities and the security controls for all your users in one single plane. And you can also set up your different IdPs there, so you can use your existing IDP to create your users, and manage that, from there. It also gives you access to SSO from the command line interface. So for instance, if you're using the CLI to do development work, you have your different IDEs, like VS Code, it'll integrate with that. So you can use those tools easily, deploy your resources where you need to deploy them without having to do much set up, right? You set it up once, and you're ready to go. As a developer, you don't have to worry about that. And admin task is easy because you only have one place to set everything up again.
Benjamin: 00:16:32.795 Again, one log-on experience, so if you're using SSO, you have one URL that you go to. So if you want to have a console access, you go to that URL. And if you have different accounts, different roles in those different accounts, you'll have the ability to get into those accounts through that one URL. And then, we also have support for first party integrations. So if you are using SageMaker notebooks, for example, and you've set that up, same webpage, you'll have another tab where it says, "I want to get access to my Jupyter notebooks," on SageMaker; you can get access through Sage Maker, through that control plane. And then, it's all managed, again, for the admins from that one application. So there's always the one place where you have to go to. There's no need to go in around in the console like how it was what I showed in the previous slide, right? You don't have to set up everything in different places and in different services, different roles. You just have that one AWS Identity Center where you can set everything up. So that's basically what the problem that it solves. So again, manage AWS account roles, right, manage access and sign-on, so you can integrate it to do our applications. Cloud-based business applications, we support, right? So think of an Amazon QuickSight. You can also use that to get access to the Amazon QuickSight dashboards. And I think, most importantly for our developers, right, you get access to command line interfaces, and that includes any SDs that support that. So I'm a big fan of Visual Studio Code, and I have that set up so I can easily move around my different profiles and my different accounts when I'm trying different things out.
Benjamin: 00:18:26.472 So right, the big thing is always, where's your identity stored? So there's different types of identity storage that we can pick. So for instance, a popular one, right, is Active Directory. But there are tons out there that you can use with the IAM Identity Center. And it supports SAML 2.0. So anything that supports that, you can use to plug in into there. Maybe some more interesting on the technical part is how this all works, right? So very popular now, right, with the coming of more and more accounts is the AWS Organizations. That's what you're using to distribute your different OUs. And giving access to those different accounts, like I mentioned, right, can be difficult. So we can use AWS IAM to do that, define the permissions of different tools, and as I said, you can then see on the control plane which accounts you have access to and what permissions you have on those accounts. How does that work? So you have your AWS Directory Services. You can, for instance, connect to your on-premises Active Directory if you have one, use AWS Directory Service to connect to AWS IAM Identity Center. And then, that, then, has your different roles, responsibilities in there. And then, again, that gives you access to the different AWS organizations and the OUs that you have in there. And again, you have the fine-grained control over the multiple different AWS accounts that you have. So that's one typical use case we see with our customers that still have on-premises resources, and they have an on-premises Active Directory.
Benjamin: 00:20:32.646 So now, an overview of our login flow, right, so you have your on-premises Active Directory where you store your different users, your groups, etc. They use that, right, use the SAML identity. I mean, you have your IAM Identity Center user portal that does the AuthN part of it to Active Directory. And then, you use the SAML identity token that you get to then get access to the different resources that you have. Little bit more complex scenario, right, for something that you might want to set up as the reference architecture, so again, you have your on-premises Active Directory, and you use AWS Directory Service to do a direct connection to your AWS IAM Identity Center. That ensures that you can get your AuthN and your AuthZ to the IAM Identity Center user portal, again, through that user portal then again, to get access, right, make sure that you're authorized and have the right identity to get access to the different accounts that you have access to. Another one, I'm just going to skip through this one because I think it's a little redundant.
Benjamin: 00:22:11.720 So configure your SAML-enabled business application, so again, right, you can use any SAML-enabled application, you can also tie into AWS IAM at any center and give access through the AWS IAM control center access to that application. So I mentioned, for instance, QuickSight is one of our tools that you can use that with. But there's tons out there that you can — [there are?] tons of third-party applications that if they support SAML, you can give access to through AWS Identity Center, as well. I think, just another reference architecture, really quickly, to go through is — let me go through this one. So I'm coming up on my time. So I'm just hurrying through these slides. So yeah, I just want to point out one last time, right, that the different identity sources that you can use, I think Azure, is a popular one, Active Directory. But I think, for more and more startups, Okta is one too. But there's also the ability to use AWS native, so it also has its own, so if you don't have your own identity tool at the moment, you can just use the standard AWS one that comes with AWS Identity Center. Yeah, that's all I had. So Allen, I'll give it back to you.
How do enterprises manage AWS infrastructure today?
Allen: 00:23:51.964 Awesome. Thank you, Benjamin. And definitely, if you have any questions about that — and what's really cool about the AWS IAM SSO is that it integrates well with Teleport. We've got customers that are actually leveraging this as their identity, their IDP, back into Teleport, which is a great thing, for sure. All right, so let me get my share back up. All righty. So let's go back into this and jump back into the demo here quickly, but skip that part since we just did it. So let's talk a little bit about, right, how are enterprises managing your AWS infrastructure today. And from a lot of folks, this is where you're seeing, probably, a myriad of ways of how this is being done, right? Through the AWS console, you can just go through the wizard, click, add an EC2 instance, add a database, and you're up and running, right, through the CLI. AWS has a really nice SDK that you can use CLI tools to manage infrastructure. Probably one of the more popular ways, right, third-party tooling, Ansible, Terraform. And I forgot to mention, AWS has cloud formation — ability to have different toolings to automate some of that infrastructure that customers are leveraging today, right? So as an example, a screenshot of the AWS CLI as well as the console and everything. And this is how a lot is being managed. And I talk to customers a lot that are using one of these three ways or all three ways to manage infrastructure. Even my own demo environments, right, if I'm in the console, I can click around, add stuff if I've got some Ansible scripts that I run in some Terraform or even a bash script that's calling the AWS CLI, so kind of leverage a myriad of those tools to manage even my own demo infrastructure.
The challenges in securely delegating access to AWS
Allen: 00:25:51.433 But it brings us to a few challenges that come along by doing it these ways, right? By accessing and using this, you get a lot of manual work, right, hands on keyboard, no infrastructure as code. And for those in busy orgs, fast-scaling environments, this manual work can add up to a lot of technical debt. It can get challenging in just moving along. Automating any change can be challenging, right, whether it's due to lack of skill set, lack of knowledge, lack of time, right? The way we've been doing this has been working, and we know it. So to automate all this can take some time to get going. Lack of understanding how AWS secures resources, they provide a huge awesome platform, but they leave a lot of that security up to that end user to be able to know how to tighten it down. And so if someone doesn't necessarily understand, they could open up a security group and have port 3389 for RDP, or 22, open for the whole world to access critical infrastructure or even database ports. A big one is misconfiguration of IAM roles and policies as you can see that identity access management can get really complex, and AWS provides tons of resources and tooling around that. But if you misconfigure something, grant a role or policy that could give a service account or a user more control or less control.
Integrating the Teleport Access Platform with AWS IAM
Allen: 00:27:26.558 And then, another one is knowing how cloud-based security and access is different from X. And I put X there, so that could be your way you're doing it currently in your own data center, whether it's on-prem if you're in a traditional environment with a corporation that has their own data center or using a small regional cloud hosting provider or a lot of bare metal type of stuff. How it's done differently there can be a challenge as well. And then, audit compliance challenges, right, so every cloud, every way you do things, we have different challenges for audit compliance. Maybe there's no standardized processes that help users get familiar or help users along that line. So a segue right, let's integrate Teleport with AWS IAM and talk a little bit of how we tie into that and start getting closer to the nitty-gritty [on?] some of the practical exercise of using this. So you could continue the manual process, or you could leverage a tool that tightens that access without complicating the process. In a lot of words, they were basically saying, "Hey, continue what you're doing," or, "We have a better way of using Teleport to tighten this, once it's set up and configured properly, will really save, I think, a lot of time and effort for teams." Teleport has a really robust role-based access control engine. We tie into AWS seamlessly. We're a first-class citizen with AWS. We're part of their partner network. We host Teleport Cloud, our SaaS offering, within AWS. And a lot of the features that our team builds is built for AWS workloads in mind, just because of the popularity and knowing how many of our customers are leveraging AWS. You can offload some of those manual processes from AWS into Teleport itself. So audit compliance, or if you're managing static credentials or public private keys, getting rid of them and using Teleport and short-lived certificates can really help a lot.
5 Advantages of using Teleport to access AWS resources
Allen: 00:29:29.536 To that next point, right, leveraging those short-lived certificates to manage access into AWS, so let's jump here and kind of dig into the — say, we call it five advantages. There are more, but we actually had a recent blog article that talked about some of the advantages of using Teleport with AWS. So I'm just going to dive into that and talk a little bit more. So first one is fine-grained control of each AWS service. Second is consistent experience in using the AWS console as well as the CLI, not having users learn new different things; simplified role-based access control, just-in-time elevated privileges, and then insights through AWS CloudTrail and Teleport audit logs. So we're going to dive a little bit more into this. So let's check them out.
Fine-grained control of each AWS service
Allen: 00:30:25.794 So, fine-grained control of each AWS service — what does that look like? So with Teleport's RBAC engine, you can limit what AWS services your users can access. And then, on top of that, that audit trail is captured in both Teleport's audit log as well as the AWS CloudTrail service that they have. So as an example, right, we want to allow developers to have read-write access to an S3 bucket for updates. Whereas contractors might only have read access to the same bucket. So that's an example of using some of that. And here's a policy; this is just actually a snapshot of the AWS: so if you log into your IAM right now on AWS, there are 1,000 or so policies. And some of these might have some, yeah, AWS managed policies out there that AWS provides and says, "Hey, here's one EC2 full access. Here's billing or security audit, data scientist." That is a lot of policies and roles. And then, how do we know what users can have access to those pieces there? So as an example, let's segue here and just show that. So that fine-grained control — so in my cluster that I have here, as I'm already logged in, I might have a role called AWS CloudTrail or console access. And so I tie these in by limiting what that user can and cannot see. So in this case, a user that might have this Teleport role assigned to them will be limited and say, "Hey, they can either have full access or maybe CloudTrail along that line." Whereas I got a user over here — it's a contractor — who doesn't have access to anything right now. So they cannot generate — they cannot request access by default. But we're tying it into the AWS. So we spent that time to build out our roles and our policies in fine-grained, saying, "Hey, we want a —" in my case here, when I look at my AWS roles, I have that specific one that's for CloudTrail read-only and then one for EC2 full access. And we'll show how this works here in a little bit. So that's an example of how that might work.
Consistent experience in using AWS Console and CLI
Allen: 00:32:48.873 And then, going to the next one here is consistent experience in using the AWS console and CLI. So when you introduce new tools that have the potential to disrupt existing workflows and developer processes, that, in turn, can lead to less productivity as now your engineers have to ramp up on all these new tools, right? So we integrate nicely with the CLI management console because we want to provide less disruption for those engineers. We want them to be able to do the work that they need to do without having to worry about being disrupted or anything along that line, so they can still use what they're familiar with. And then, from a security perspective, right, teams know that the activity that's managed by Teleport is a win because they know, "Hey, Teleport is managing a lot of this access here."
Allen: 00:33:43.750 So as an example, here's one. I have — and I'll show it here in real-time in a minute — a screenshot, for those that don't still have the demo, just showing accessing of EC2 instances using Teleport as well as not using Teleport and how that looks. So right here in my browser, I'm already signed in as a user; I'm already signed into AWS. So I can run an AWS command as a developer engineer, describe instances. In this case, I have an instance; that gives me a little bit information back on that. And so I get this nice, "Hey, I'm familiar with this." Well, just to show that even if you're not doing it without Teleport, and you're used to doing it from just using the CLI itself, I can hit return and also get it as well, so trying to not change and disrupt that user workflow, which is really critical because the advantage of using something like Teleport is, now, because I'm running that one command through Teleport, two things, I get an audit console that says, "Hey, this user is running an application." I get some JSON-formatted auditing that knowing this user. And then, when I look in CloudTrail, I'll be able to see what was happening, as well, along that line. So that's the advantages of that consistent experience across the board.
Simplified role-based access control (RBAC)
Allen: 00:35:13.699 Simplified role-based access control — everyone who's played with RBAC knows RBAC can get really complex, right, really, really fast. So our engine in Teleport is — we really want that granular-control resources and permissions. So certain users can have this access; certain users do not. And we tie that in by utilizing the AWS ARNs within a role to allow restrict access. And I showed, with my CloudTrail and EC2, what those ARNs look like. And so you can define these roles for your AWS service through IAM within AWS and say, "Hey, we have engineers that are only responsible for production," so we have specific roles. And then, you can map those with Teleport role-based access control and keep it very specific, so who can see and what and do whatever. So here's the one I have defined, oops, where on the left, you can see my AWS role that has the ARN defined. On the right, you can see the role that I built within AWS. In my case, I just added a generic EC2 full access, and that's it. And you'll see this in action here, in a minute, how this is going to work. So as an example, if I wanted to run a CloudTrail or see information that I might not have access to, we're going to do this with a contractor who's going to access or request additional access. So they're going to say, "Hey, I need CloudTrail access." So we're going to proceed and fire this off through Teleport itself. So within Teleport, I get an access request that comes through. This is one of our features here. I can see that. So now, I'm going to grant access, approved today only.
Just-in-time (JIT) elevated privileges
Allen: 00:37:11.700 And so I'm going to let this user, who normally doesn't have access to AWS, now, will be able to see resources they previously did not have. So I'm going to assume this role. And so now, I can see this: I have this new role, and I can actually go here. Hopefully, that didn't — and that broke. Go figure. So something changed there. So let me do this. I'm going to request this role instead. Maybe that's what happened here. See, this is what happens. Sometimes, you go back into things, and something works one minute, and then, it breaks the next. So I'm going to approve my AWS role. I think, I just forgot to copy it over. So I'm going to go back here, go back to my listings. So I'm going to switch back out of the CloudTrail one, which doesn't work. I'm now going to assume my AWS role, which, I believe, does work. This allows me to see my resources. And there it is. So now I can see AWS CloudTrail. So right now, if I try to go to the AWS console, it's going to not sign me in. I don't have a user attached to this. But with Teleport managing this with our roles, I'm going to be able to access EC2 instances.
Allen: 00:38:32.615 So what Teleport does — it works with AWS, creates a federated user. We can see now I've got the contractors here. I now can see resources that I previously was not able to see. So maybe, I'm in here, and I want to look at CloudTrail usage. Well, because this one is EC2 only, I'm going to get errors or things along that line because I don't have API access into this. My role has been defined specifically for EC2 access. Now, this role will only last for an hour because my contractor only has — or, well, this one is going to expire because I've been signed in. So in half an hour, it's going to expire. So I'll lose access into this. So when you talk about that — it’s simplifying it so I don't have to give user-specific access to AWS. I can tie in and leverage Teleport to manage some of the pieces of the puzzle here.
Insights through AWS CloudTrail and Teleport Audit
Allen: 00:39:30.672 Just-in-time elevated privileges, which I think I just showed that, right, so we had a user who did not have access, but they needed it, so we granted them. So in this case, our access request, you can use tools like Slack or Jira or PagerDuty. In fact, our documents were just updated recently. We now have a Microsoft Teams plugin. So you can use tools like that to view requests and auto-approve or give access on an as-needed basis. And just to kind of highlight, this contractor, right, within had access specifically to those, as I showed here a minute ago. And so that kind of just-in-time privilege is great because it's zero trust. User doesn't, by default, have access, but they can elevate; they can request it if they need it for anything that might happen. And then, insights through tools like CloudTrail as well as Teleport Audit — so Teleport and AWS, we use CloudTrail to log activity of users and what's happening. You can export our logs, which are JSON-format logs into, really, any SIEM of your choice, Splunk, Datadog, Devo, Elastic. And that provides you the ability to get better reporting, better alerting, better telemetry of what's happening. From an audit and compliance purpose, we provide those.
Allen: 00:40:53.227 So now, Teams can say, "Hey, what was Allen doing on this server? He requested access. He was given access. He was on AWS building new systems." And we have this whole trail and alerting to be able to capture all that. And then, if you're hosting Teleport within AWS using tools like DynamoDB, that will capture these logs as well as your own cluster information on the backend. And then, SSH and Kubectl exec sessions are replayable, and they're stored on S3 storage. So that full tied in from audit compliance and having the ability to keep this information within AWS is great. Here's an example of CloudTrail, right? So I've got, over here, the console where the user logged in, the Teleport log. And then when I log into my CloudTrail, I can see that event record of knowing what that user was doing, what username they're in as, what timestamp on it, source IP address. So it provides a complete picture for Teams to manage access across the board. So I want to pause for a minute. I know that was a lot. And looking at the time, we're going to jump right here into a few Q&A questions on this line. And I appreciate everyone's patience.
Allen: 00:42:10.984 So looking here, first one, someone asked, "Do we publish our source code in GitHub as well?" So let me show you that. We do. So you can actually go right here to GitHub, and you can see everything that our team builds. There was a release that came out three hours ago. So you can see what our team is building out. You can actually go and view issues that are out there. So hey, if you have an issue that you're working with, you can go out here. We have a discussion section here where communities can put in discussions or ask questions and get general help along that line. So we're very active. In fact, we're almost at 13,000 stars, which is pretty awesome. So hope that one answered your question there.
Allen: 00:43:00.909 Another question that I have here is, "Does Teleport trace user-role access behaviors for defining zero-trust access controls? Or does it rely on you already having a solid grasp on user IAM prior to utilizing in a mature manner?" Having knowledge of IAM is really key. If someone doesn't understand IAM out of the box, Teleport, well, has a few generic basic roles, an editor role or an access role. So when you install Teleport, you're going to get a generic role. But we have full docs that kind of detail how to configure roles and set them up. But definitely, having some understanding and grasp of it — you don't have to be a professional. I mean, I've been using IAM for a while now. And I'm still learning something because there's a lot of nuances and a lot of how that all works. So I hope that answered that question there for you.
Allen: 00:43:59.260 Another question here is, "Is it safe to say Teleport aims to resolve issues like console, CLI, based role switching by allowing a single dashboard to jump across accounts?" You can, I think, on that line. So if you're using Teleport on that — and let me try and look at that question here. Role switching, single dashboard to jump across, that is one way. So if you have a certain role in your CLI here that you have everything configured, you might have different Teleport roles that give you different IAM access that you could switch back and forth. And even if you don't have the ability, let's say, you as a user, maybe you have more of a — you're the AWS guru, right? So you can actually have it defined so that you could pick which role you want to authenticate or log into AWS as. So that is also a method of helping control maybe multiple roles or resolving issues by switching back and forth across that line.
Allen: 00:45:04.063 And then, Janine has a question here, "Does the audit and logging capability go as far as capturing specific parameters and folders that may be altered or down to detail?" Are you talking AWS? I'm assuming AWS access. Possibly. So our audit log captures when it's doing kube exec or SSH-based activities. So for example, I'm a user. I'm SSHing into a server right now. And if you have what we call BPF logging enabled, and I run commands, Teleport is going to capture these very specific sessions. In the audit log, you can see that I ran an
ls; I changed into a directory or whatever along that line. So between that, that's an option that can be enabled. But we also have what we call session recording. So if that user exits out of this session, I can go back into Teleport, and then, I can actually pull back a session recording and review what was played or what that user did. So between those two, I think that provides that capability for users to see all of that information. Let me see here. Great questions, by the way. So I appreciate everyone’s patience as we kind of go through some of these.
Allen: 00:46:33.328 We got a couple more. "What level of access does Teleport require to our infrastructure? Does it require full admin privileges?" No, it does not. So we have a myriad of ways of installing Teleport. There's a Teleport service that runs on your cluster or your nodes or your databases or your EKS clusters. It does not require root or admin level privileges. We have some information in trying it out or deploying a cluster that talks through permissions. Being a security-minded company, we don't want everything running as root or admin. Teleport uses reverse tunneling. So my resources that I have out here — I'm not opening up any additional ports in my firewall or my security groups on AWS. My servers have private IPS, and they're outside, reverse tunneling back into my Teleport cluster for that.
Allen: 00:47:30.899 "What's the maximum number of AWS accounts you could support using a single Teleport dashboard?" That's a great question, and I don't have an answer for that. I would, in theory, think quite a bit. We've got users that have thousands of users in Teleport, hundreds of roles, and so I'm thinking it should be able to handle quite a bit, but I've not seen any data on that. Is there a specific — whoever typed it in, if you could maybe follow up on the general chat, maybe if you have a specific number, we can maybe dig into that a little bit on that.
Allen: 00:48:11.118 And Richard, "Does the use of Teleport short-lived search for AWS access mean there's no console passwords or access keys provisioned for AWS users, no more need for a password or access keyring?" That is correct. So I am logging in to — so here's my other user, right? I'm currently not signed into Teleport. But now, with my Teleport used Okta as an admin, I'm going to sign into Teleport here. So I'm going to do this one on CloudTrail. It's going to authenticate, log me in with short-lived certificates and AWS IAM federated access, no keys or anything to log into this. I don't have a password. I can't type in my IDP or Okta password to get into this. It's all managed by Teleport itself. So that's how we're leveraging that. And we've got a little — again, going back to our documentation where we talk on application access — we talk a little bit there — as well as an architecture guide that talks a little bit more on some of that. So definitely, our whole mantra, we want to get away from key rotations; we want to get away from passwords. And you notice, the first time — oh, I didn't sign out. I was already signed in. But I logged in once. I logged into Okta, which authenticated me. And then based on my Teleport role, I have access to whatever has been granted and given to me on that.
Allen: 00:49:37.812 The question is, from Zach, asking, "How well can it actually scale 150 AWS accounts currently split by application and tier at an enterprise level? They're going to eventually scale to around 500 total AWS accounts." Zach, I'm going to take that question back because that's a great question. I do not have an answer for you on that one. So I'm going to follow up on this one. I think, since you registered, we do have that information on it. So I will try to get a follow-up and maybe get you an email out, or something along that line, answering that question, because I don't know. I would think it should scale fine because it's kind of federated access. And what Teleport does is, when you sign in as your IDP, it creates a temporary Teleport user. And that Teleport user is here for the length of that session. So I have an eight-hour session, so I'm signed in. And then, when I authenticate out, or I SAML log out, or it times out, that user is gone. So here's my Teleport contractor that came in through GitHub.
Allen: 00:50:42.432 And then, another question here, "Where will Teleport be hosted, on your VPC or outside?" It could be hosted anywhere, to be honest. You can host it on Raspberry Pi. You can host it —we have a SaaS model, so there's a few deployment options there. We have Teleport. You can host it and let our team handle it. But you can host it in your own AWS account. So we're very flexible and provide that because we have customers that cannot use SaaS, or they prefer to manage the cluster themselves; they prefer to host it within their own environment. So we provide full support for either, what we call, on-prem or self-hosted, as well as our cloud hosting opportunities there. And you could even mix and match across the board.
Allen: 00:51:29.557 Yes. Rohit asked a question about working with PagerDuty. That is correct. I do not have an integration. We have a YouTube channel where Jonathon Canada, one of our solutions engineering managers, did a demo last year. It shows integrations with PagerDuty. But we do have some — let me look at my documentation here because we actually have a plugin that kind of talks a little bit about access requests with PagerDuty. It kind of walks through. And here's a little snippet of it, and it walks through how you can even get that up and running and set up. And let's see here. We got a couple more minutes, so this is great.
Allen: 00:52:09.955 So, "I'm not using CLI sessions the way IDP plus AWS ID Center integrations usually do?" Yeah. So as far as I know, we're not using CLI session tokens. And I'm not the developer that built this. So the reason I'm still able to run my AWS, I still have my credentials file locally, so I could actually do that. But let's say, I log out of my local cluster, and I do not have a local credentials file. And if I try to run that AWS command, it's going to err out because I'm not using credentials because I'm proxying it through Teleport using shortlist certificates. And so that helps manage that across the way there.
Allen: 00:52:58.088 Another question here, "Can I use Teleport open source?" Yes, I mean, we are fully open source. You can pull it on GitHub. Now, there are some limitations. And if you want to know what those might be, we have an FAQ on — well, that is not the right FAQ. Here it is — a couple of FAQs. We actually talk about open source is different from Enterprise. And the main thing is, really, support, here. So enterprises, in today's world, right, need to be able to have somewhere to reach out if something breaks or something complicated. There are some single sign-ons, role-based access control. Moderated sessions is an enterprise, excuse me, option here as well as things like FedRAMP control or certain audit and compliance; we have some Enterprise-only there. But you can look at this FAQ to get a little bit more information on that.
Allen: 00:54:00.297 Let me see. Man, those are great questions. I hope I answered all. Zach, I will follow up with you on any of those, as well, from that one because that was a great question, stumped me on that one. And I'm looking at our time. One last thing here to show before we finish out — and I appreciate everyone's patience today in sticking with us, through Benjamin and I, for today — is, where do you begin? And we'll make sure everyone gets a copy of these slides as we've got some links here, AWS use cases, how to contribute. We have an open-source community on Slack as well. So you can easily hop in on Slack and ask questions. I'm on there as well as number of our engineers and developers. And if you're lucky, even our CTO answers questions out there, which is pretty awesome, as well, very involved development community. And that is what I have for today. And I'm looking here, and I don't see any other questions. I think we answered them all. And I appreciate everyone's time. Again, thank you. Benjamin, thank you for hopping on and talking a little about AWS IAM and everything. And hope everyone has a great day.
Benjamin: 00:55:12.026 Thanks, Allen.
Join The Community