Security & Compliance for AWS Infrastructure

Improve Security and Compliance for Your AWS Infrastructure with Teleport - overview

Easily control who can provision and access your critical AWS resources while improving security and compliance. Watch this webinar as Allen Vailliencourt from Teleport discusses how to:

• Secure your growing AWS infrastructure.
• Meet security and compliance regulations through complete visibility.
• Increase developer productivity while saving time and money.

Key topics on Security and Compliance for Your AWS Infrastructure with Teleport

• Teleport is designed to eliminate the inherent conflict between the developer productivity and security.
• Cloud-native security requirements are dramatically different than self-hosted or on-prem or the traditional data center.
• The cost of a data breach and the cost per record are often severe.
• Teleport doesn't force trade offs like existing solutions do.
• Teleport use cases include zero-trust infrastructure access, passing compliance audit, implementing passwordless, and modern privileged access management.

Expanding your knowledge on Improve Security and Compliance for Your AWS Infrastructure with Teleport

• Teleport FedRAMP Compliance
• Teleport SOC 2 Compliance
• Teleport HIPAA Compliance
• Teleport Passwordless
• Teleport Machine ID
• Teleport Server Access
• Teleport Application Access
• Teleport Kubernetes Access
• Teleport Database Access
• Teleport Desktop Access

Learn more about Improve Security and Compliance for Your AWS Infrastructure with Teleport

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

Introduction - Improve Security and Compliance for Your AWS Infrastructure with Teleport

(The transcript of the session)

Allen: 00:00:06.188 All right. Well, let's go ahead and begin. And as folks jump in, we'll definitely add them, so. Add them to the webinar. But appreciate everyone coming out today and attending from Latvia to Georgia, North Carolina, Texas, and all points in between. And today's webinar is in conjunction working with here at Teleport and AWS. Improving your security and compliance for your AWS infrastructure with Teleport. So I trust you're here because you all have lots of AWS infrastructure or things within that world and want to figure out how do we tighten that down and how can we as Teleport, our product, really assist through that. So let's go ahead, jump into some things here. And a few house rules. If you have questions come up, we'll have a little bit of Q&A time afterwards. Got a little bit of a demo here as well in our agenda. But please feel free to drop questions in the chat or ask them and we'll get to them as well.

Allen: 00:01:11.588 But right at the top, my name is Allen Vailliencourt. I'm a partner of solutions engineer, sales engineer, here at Teleport. I've been with Teleport for about a year and a half. And before that, I worked with Avar and spent about 15 plus years in the production world doing the DevOps thing before DevOps was cool. So software developer, Linux admin, Windows admin, impromptu database admin as needed. So you're aware of many hats. And living in that world, in production world, managing infrastructure that was both on-prem, self-hosted bare metal or physical machines, all the way to early cloud, and playing on Amazon and AWS since about 2011 was probably the first time I spun up an EC2 instance. And of course, back then, AWS did not have a whole lot of feature sets out there, but they had EC2 and it was great to just start diving into it and playing with it. There's my LinkedIn profile as well. So feel free to send me a connection request. I love to network and connect with folks on LinkedIn. And if you have any questions on technical or anything else, I'll try to answer them as best I can.

Webinar agenda

Allen: 00:02:32.356 So today's webinar agenda. We're going to talk about three different things here. We're going to talk about securing your growing AWS infrastructure, we're going to talk a little bit about meeting security and compliance regulations through complete visibility, and then we're going to talk a little bit about increasing that developer productivity while saving time and money. All being done with Teleport and how Teleport kind of wraps in and handles all of that with that. So let's jump a little bit into that and get going.

Allen: 00:03:08.413 So for those that are new and might never have heard or used Teleport in the past, we have a line here that we like to say. It's really, what is Teleport, right? It is the easiest, most secure way to access all of your AWS infrastructure. And are we AWS-specific? No. We're cloud agnostic. We're network agnostic. But in today's world the majority of customers are using AWS. And we use it heavily in everything. So that's what we're talking about today. How do we access, how do we secure this infrastructure that we have that we're running?

Eliminating the inherent conflict between the developer productivity and security

Allen: 00:03:46.827 So our strategy, really, is removing the inherent conflict that's between the developer, productivity, as well as security, right? It's that conflict that all of you all probably see. If you look at pre-DevOps worlds, everybody has something. They throw it over the silo. The next team handles it. And that kind of access. Developer needs access to a certain machine. You need productivity. Production stuff. But then security is here. So there's this conflict of access and handling that. And traditionally, it's been really challenging to manage all of this, right? It's a pain. And scaling this at scale gets really challenging. So part of that, we like to use consolidation. How do we do that? Well, we use four kind of talking points, right? Connectivity, authentication, authorization, and then audit. And we do it for software, we do it for hardware, we do it for peopleware, as we call it all through the Teleport Access Platform.

Security and compliance challenges

Allen: 00:04:57.319 So a few security compliance challenges that we see here, right? You look at this and say, "Hey, we have data breaches. This data came out in this report in 2021. You look at the cost of a data breach and the cost per record — it's pretty severe. It gets up there and it's only increasing. We look at today's challenging world securing stuff. What is exposed? How do we handle? How do we manage that? So this is what keeps, hopefully — if you're a security personnel on this call or an architect or doing anything in AWS and the cloud, this is what keeps you up at night, right? Trying to figure out how do we secure access into our data and our systems.

Teleport Access Platform

Allen: 00:05:42.659 Well, we do it through a few ways here with Teleport. We call it our Access Platform. And that's kind of high-level terminology. That's really what it is. It's zero trust based. It's certificate based. We use just-in-time access to give limited-time gated access to resources only on an as-needed basis. And then we have that complete visibility for engineers and machines. And the Teleport Access Platform comprises of five protocols, as you kind of see on the slide, right? Server Access, which is SSH, basically access into SSH IoT type of devices. Database Access, where we've got 15 to 20 supported database protocols and more being added. Application Access, which is tools like internal dashboards or self-hosted web pages. Windows Desktop Access, which is one of our newer protocols that allows organizations — oops. Wrong click there — to access Windows-based resources along that line. And then of course — this is what happens when you mis-click a few things. Kubernetes Access as well, right? So many things are Kubernetes-driven today. Leveraging Kubernetes to access things and being able to secure those as well.

Cloud-native security requirements

Allen: 00:07:07.775 So moving on. So cloud-native security requirements are dramatically different than self-hosted or on-prem or your data center that's just down the hallway through the glass doors, right? Years ago, I worked at a company and we showed off our data center. You could walk down the hallway. There's this big glass pane here. You could see all these server racks and all these blinking lights. And then there's this little hallway, then another big giant glass into a courtyard. And then from an aesthetic visibility standpoint, you're like, "Wow, that looks really cool." But looking at it from a security standpoint, it was really bad because you could be walking by the building and looking through these double pane glass windows and say, "Wow. Look, there's their whole production data center." And that's kind of how things were. Of course, you had to get in the building or something along that line to then access it. Fast forward today where organizations are on the cloud. Whether it's AWS, Google, Equinix, doesn't matter. The architecture design of accessing those requirements are dramatically different. Just a quick example, this slide here, right? You've got DevOps, SREs, business intelligence, IT ops, front end, etc., all trying to access applications, Kubernetes databases, Linux servers, and Windows servers. And you can't just say, "Here you go, and have fun." Or you could, but then you're opening yourself up to that slide I showed previously, showing data breaches or things that potentially might happen along that line. So that's what we are dealing with.

Existing solutions force tradeoffs

Allen: 00:08:47.806 So there are existing solutions and it's what companies are using today across their environments, right? They're using perimeter security. So when you look at perimeter security-based solutions, they focus on that connectivity piece here. Typically, there's not a lot of fine-grained role-based access control. A lot of times, the audit leaves things to be desired. There are shared credentials where probably a lot of you all might be using today. I know that's what I did in production, needless to say, right? We had a shared password vault, and users would use the same ID, the same administrator user, or the EC2 user, Ubuntu user, or whatever it is. And so we would share that. But you didn't have that accountability. You had very limited RBAC or to no RBAC. And then audit was like, whoever is using it today, we just trust one another. And then you got legacy kind of PAM privileged access systems, tools that are out there, that have been out there for a long time, that were not necessarily designed for cloud-native workloads or the fast pace. And so using a legacy PAM tool potentially impacts productivity. Challenges of getting it to work with the cloud-native stuff also poses challenges as well.

Short-lived certificates

Allen: 00:10:14.493 So Teleport, so how are we doing slightly these things differently? You're going to see this slide, probably variations of it as I talk through this, and then we'll jump into the technical pieces. Kind of show it in action, right? So we do it based on short-lived certificates. And that is a big cornerstone of Teleport, right? Accessing it through connectivity, authentication, authorization, audit. Short-lived certificates. Why certificates? Well, they're known value. They've been around for many, many years. All of the work you're doing today, in fact. If you look at we're connected here on Zoom, it's encrypted using Mutual TLS. When you go to Amazon and you buy something or you log into the Amazon console using certificate-based authentication to access that are short-lived or web-based potentially longer- lived. But yet we use it with Teleport, making them short-lived certificates. So that way, access to a resource is only granted for a certain amount of time.

Connectivity, authorization, authentication, audit

Allen: 00:11:18.635 So we connect to resources using zero-trust networking as we talk about. We don't care where your resources live. They could be in any AWS region throughout the world. Any availability zone. Doesn't matter. Teleport is agnostic on that. We have an identity-aware access proxy that looks at the protocols coming through and how does it manage it. And then it works for users and services. So John Doe, me, Allen, as a user, or our marketing team, our front-end team, back-end team based on that to access. Or services like [inaudible] or Machine ID, things along that line, to connect to it.

Allen: 00:11:59.017 The next thing is then we use authorization, right? Fine-grained controls for every employee and every service accessing your infrastructure. So what we don't want is the ability to just give someone, "Here's your access and keys to the kingdom, and voilà, you're good to go." You want to be able to define that with tight RBAC controls. And then you can layer on access request workflow. So let's say a new engineer comes on board. Needs access to EC2 to build out new servers. Well, maybe they don't have it, but then they could request and get elevated access into that. And then things like dual authorization and moderation. We have production workloads running on AWS right now, and we don't want just anybody logging at any time. So maybe we have dual authorization. So they authenticate to their SSO provider. They get authenticated Teleport. But then when they want to jump onto that production server, they would then have to re-authenticate or touch a YubiKey or something along that line. And then even add the ability to have moderation. Hey, this is a production system. We don't just allow anybody into it. So we always have two eyes on a keyboard or two eyes on a monitor. When you're in a traditional office, it's easy. You just walk over to someone's desk, you sit down, and you work. But in today's remote world, where everyone is across the globe, it's a little bit harder to do that. So you have tools like Moderation where a user can't even log into the server until the moderator comes on board and then is able to authenticate and authorize and let that user in. So once you're in and everything, we authenticate based with tools like Okta and SSO, single sign-on integration, which is a critical piece of, really, any organization today. Whether it's Active Directory, Google Workspaces, Okta, [inaudible], JumpCloud. Those become your source of truth where users and groups live. Identity-based access for those engineers, those service accounts, again, all based on short-lived certificates.

Allen: 00:14:12.766 And then the kind of last piece here is, yes, we allow all this, but then what happens? Well, we start auditing all of this information. So we have session recordings, which we'll show here. Detailed change logs. What's happening in our environment? We integrate with tools like Splunk or Elastic or Datadog or Devo. Any major SIEM type of tool out there that we integrate with so that organizations can build telemetry and reporting and dashboards and know what's happening in there. And of course, this works for engineers and service accounts. It provides that layer of accountability for them. I was on a customer call a number of months ago and one of the DevOps engineers there they didn't have a tool like Teleport. They were looking at it. So what he was doing himself just to kind of cover from an accountability aspect, he was actually using OBS. Open Broadcaster. So anytime he SSH'd into a server, he would record it with OBS and save a video file of it or along that line. That way if something happened, or if he got accused, or if they were like, "Hey, server went down," he had that accountability there, audit trail that he kind of home grew just to provide that. But with Teleport, it's all native integrated within that.

Teleport use cases

Allen: 00:15:31.215 So let's jump into a couple of use cases right here off the top for this. Zero-trust infrastructure access where we don't give anybody access at any given time. It's zero-trust. Yeah. We don't know who you are, so we're just going to give you access when you need it or when you request it. Because right off the top, we're going to deny everybody. Compliance auditing, which is huge in today's world with SOC 2 compliance, PCI or ISO, FedRAMP. Different compliance standpoints where companies need to approve, we have this audit trail, and Teleport meets a lot of those. And our products are SOC 2 compliant. SOC 2 Type 2 compliant. And you can pull all of that information off our site and even some use cases of how our customers are leveraging that for some audit compliance auditing. Passwordless. Where, if you've seen in the news, even the government is talking about going passwordless, right? There's a consortium of big players — Apple, Microsoft and others — about how do we implement passwordless. I mean — we do it with our phones. Face ID, right? Or if you're on a Mac, Touch ID. iPad I have right here with some other stuff here as well. Windows Hello. So implementing passwordless solutions. Teleport allows you to do that as well. And then modern Privileged Access Management, right? We're not [inaudible] of a legacy PAM and trying to shove a square peg into a round hole into the cloud. We're a modern PAM tool that allows to work with a lot of these different use cases.

Allen: 00:17:22.172 And one of my favorite things here at Teleport is we're an open source product. And over 12,000 stars, the last I checked on GitHub. And there's a link there and you get a copy of slides. Go to GitHub and search for it. You can see our roadmap. You can see what's happening. You can see our builds going out there. And we have a lot of open source users. We have a lot of open source contributors. I think this is a very valuable thing, especially from a security standpoint, right? When you look at today's security model, security world, if you're buying a product from someone or an organization and they're like, "Hey, this is a secure tool. This is going to see all your audit and everything," you want to know, is there a backdoor into that? Is there something that I need to be aware of? Well, with Teleport, you can actually go out there and comb through our source control and actually look at it. It's one of the strengths and advantages of being open source, having that community peer review being able to help manage some of that information. So I know that was a whole lot. And that's it for the marketing side.

Demo time

Allen: 00:18:26.837 Now, we're going to jump into the fun stuff now. I'll walk through the demo and kind of highlight these pieces with AWS. And definitely if you have any questions, feel free to type them in chat and we'll jump into them as we talk and kind of answer them as well. So let me switch here. So what I have here on my screen, I've got a couple browsers here. I've got my main one which is going to show when we log in, what does a user see, and how does this affect me and work with my AWS type of resources. And then I have over here as well the incognito user. So I've got a demo user, a contractor I should say, that's going to come out here and request some work there. Then I have a command line. So we can show even from a terminal command line how a user might access different resources. And you can already see from a command line, I signed in earlier today and my certificate originally was valid for 8 hours, but now it's dropping. So if I actually look here and do a tsh status, you can see now my certificate is valid for just around 5 hours now. So that time to live is dropping, so access is decreasing. So I can still access resources, but for just for another 5 hours. And then after that, I'm going to have to re-request authentication.

Allen: 00:19:59.046 So let's go ahead and jump in here and kind of show this. So the first piece there, is we log in using our source of truth. We log in leveraging that IDP. And here it is where I'm authenticating using a YubiKey with my fingerprint to verify that, "Hey, what I have, what I am, who I say I am." And then I'm dropped right into a Teleport web UI. And this UI, since we do everything based on role-based access control, my user coming from an Okta has been defined as an administrative type of user. So in this case, I'm able to see a lot of different resources.

Allen: 00:20:42.166 So let's log in as John Doe contractor over here. So I'm going to log in with GitHub. So I can actually log in and authenticate with a variety of SSO providers. Well, I come in as a user and I'm like, "Well, I don't see anything." Well, because this user, by default, does not have any access at all. So yes, we have allowed them to access, but because of zero-trust, we're not going to say, "Hey, you're a contractor. We're just going to give you the keys to the kingdom and let you do whatever you want within our environment." So in that case, that user has no access to this.

Allen: 00:21:18.288 So once I'm in, what can I do as a user? Well, from a day-to-day standpoint, day-to-day work of a user, I can just access my resources. So in this case, I have an AWS server out here. So I'm going to go ahead and log into an AWS server here. So I'm going to log into the server. I'll do it from my command line — because that's our probably typical workflow, seeing engineers using CLI — and then I'm in. So I can clear it out. I can run my famous dad joke of the day, which it's all random, I can say different apps. I can type. I can look at my memory. Whatever I do as a Linux admin or whatever, I just go in there and do it. From an end user's perspective, it's all transparent, right? I logged in. I didn't use any sort of key or password vault or anything. I just SSH'd right into it.

Allen: 00:22:22.965 Here's what's happening on the back side of it. And this is where it gets really exciting from an audit perspective. Well, we can see commands and traffic being audited. So now as users are accessing your AWS resources, they're SSH'ing into it. They're doing work. They're fixing stuff. We get this robust detailed audit log. In this case, I have enhanced auditing enabled. So I can see what's happening within this environment. So I know a user’s typing this. And this is all traced back to unique users. So my user on my command line is a user called Valiant because it's tied into my GitHub username. But I'm actually logged into my Linux server as an Ubuntu user. So you can see this right off the top that now you're matching users' unique IDs into what's going on within their world. So if everyone's just using the same login and you don't have that audit trail, then you're going to be like, "Who did what? We don't know." But with Teleport, everything is tracked back to that unique ID and what that user is.

Allen: 00:23:35.090 The second thing that is happening here — you get the ability from an administrator, depending on your roles or privileges — you can see these active sessions going on. So in this case, I'm a security admin coming down. Like, "Huh, we got a user that's on one of our AWS servers right now. Let's join their session." Whether it's a moderator join or something like that. "Let's go ahead and join and see what this user is doing." So I can hop in and I can see now in real-time what is happening within this environment. So this user is over here running commands and doing all kinds of stuff on this box here and poking around in everything. Control C. And maybe from a browser aspect, they can also type in that command and everything. Whatever they do, we can see because we have this ability to join the session. Whether it's a moderator join or me as just an end user may be helping someone out to troubleshoot. Something along that line. And then at the end of the day, we finish our work, or our certificate expires, or something like that, then our session disappears. All throughout all of this, we have this full audit trail going on. So we know what users are happening, what users are doing.

Allen: 00:24:56.305 And then another piece that happens here. We now get this ability to see a recording of what happened. So you can go back and say, "You know what, coming off of a long weekend we had a read-only Friday, but then somebody made a deployment. A server went down." Well, guess what? We can now go back in here and take a look. We can replay the session. We can see what our users were doing at any given time within those environments. Wherever those AWS environments are throughout the world. And that shows just a little bit some of the power functionality of what we're doing with Teleport. And we take this and we layer it through our applications, Kubernetes clusters, as well as even databases.

Allen: 00:25:42.143 So, as a perfect example, let's jump in here to a database user. So I have a database. This is a Postgres database that's an Aurora Postgres database. That's already connected to my Teleport cluster. And I'm a DBA or I'm a business intelligence. I'm going to run some SQL commands on this. In this case, I got a little generic Northwind database. I pull in data, I pull information, and I'm doing my work on this. From a Teleport side, my audit log, you'll notice it's now slightly different. It switches from showing SSH-based audit trail. We now see database querying going on. And so I can click in here. I can say that "Hmm. This user, allen-okta, is running database queries." Here is the database. In fact, this is a private database on RDS. There's no public ingress into this database. I've got this database locked out. So yes, everybody can see this URL, but no one can access it because it's gated by Teleport. And here's the query that I ran. I ran a select all. So now you know when a user makes a mistake on a database or makes an update, we've got this full audit trail that is easily readable. It's in JSON format by default. You can forward this, as I mentioned earlier, into the SIEM of your choice. Splunk, Datadog, Devo, etc. Now you have the ability to know what's happening.

Allen: 00:27:12.688 Give you a real-world experience of database mishaps. I'm sure all of you have these stories. Back when I was in production and I did not have a tool like Teleport, we had a shared database user — administrator or whatever it is — because we're a couple of developers. We didn't have a good tool. And so production database and QA database was kind of all trusted. And an engineer comes to me, one of the developers, is like, "Hey, Allen, do we have a backup of this SQL Server database?" And that was like, "Why?" He goes, "Well, I thought I was on dev. I thought I was on dev QA." He goes, "I made a change and I just changed 60,000 rows in a production table." And so all fire breaks loose. We go in there. Had a 15-minute backup. So I was able to restore it. So no data was lost. But if we had a tool like teleport integrated, that probably never would've happened because that developer would not have had, or shouldn't have had elevated role to a production database. And then let's say this developer didn't say anything. Just went along with their work and just moved on and we discovered it. And we try to go back and audit. All we see is DBA admin running these changes, but you don't have that audit trail. Well, now with a tool like Teleport you can now know that "Hey, all of my database queries are tied into specific users." So that provides a really tight audit compliance trail that organizations need and leverage into that. And so RDS databases that live on AWS, whether it's Redshift or Postgres, MySQL, you name it, we get the ability to protect and lock things down within those environments.

Allen: 00:29:01.710 So let's segue quickly here to another kind of use case. I have this contractor that I signed in from a little bit ago. And so this user is in, and they're like, "Hey, I need to spin up a new server." Well, by default, I don't have access into this resource at all because my role is very limited. And so with using a tool like Teleport, you can manage and gate access into these specific AWS resources. So this users going to request and say, "You know what, I need AWS access because I'm an AWS engineer. They're bringing me in here to do all of this. So I'm going to proceed and ask for this." I said, "I need access to AWS resources for today's webinar." So this user might fire us off this request. In our access workflow, you can do it within Teleport itself like this. You can also tie it with tools like PagerDuty or Jira. So if you have a ticketing system that you want to flow these resources, these requests through, we have a full API. Makes it really powerful of being able to get just-in-time access.

Allen: 00:30:14.913 So now this user’s going to fire it off. In my case, I have it very simplified. I'm just using it within. Although, I do have Slack integration. So in this case, I'm going to fire up my Slack. And so my SRE team is managing this, and they say, "Hey, we've got a request that came through from Teleport contractor looking for AWS roles. So let's click it or let's go back to our audit trail, and go back in here and look at what this user is requesting." So let's review it. I can see it here. I can view it. All right. Contractor a few seconds ago. Let's go ahead and approve it. Approved for today only. And based on the role-based access control that's been submitted and defined previously, this could be a limited role. In this case, I think this roles two hours by default. I created this role for two hours. I look back in my Slack workflow, so I can now see that, "Hey, I've got this thread going on." So again, we have that audit trail knowing what's happening. Who approved it? Allen Okta approved it. He's an administrator. You can even have thresholds of approvers and deniers and very robust ways of doing all that. So the user can now go back. He's like, "Oh, sweet. They just approved it. So let's assume this role." So when they assume this role, Teleport issues a new certificate to this user. And I can verify that by going into my audit log and seeing that, "Hey, a certificate's been issued for a Teleport contractor," and then looking at the details of that certificate. So now this user is in, and they're like, "Sweet. I've got access to AWS." So what does that do? Well, I now see servers that are labeled with AWS. I also see applications. So we have integrations with tools like the AWS Management Console, whether from the CLI or from a browser base. So this users like, "Sweet. I now have access to EC2. I still don't have access to Kubernetes because we didn't have any, or even databases. So only apps and servers. So in this case, let's go ahead and launch this and get me access into AWS."

Allen: 00:32:27.635 So what Teleport now does, it goes there, and ties in with some federated access with AWS console. Which is actually a really, really neat thing that we see a lot of our heavy AWS users leveraging. So you can see there this contractor has a temporary user that's been created with an AWS. And because the role that's been defined is based on RBAC of what they can do, and I have a role and IM policy and role that says, "Hey, whoever has this AWS EC2 full access — they can now create EC2 instances." So in this case I can be like, "Hey, I'm an engineer. They told me I needed to create one. So I'll go ahead and create a new server because I've been asked to do this. We'll just use Amazon Linux here. t2 micro is fine. Let me see here. Make sure I get my right key pair on this if I'm in the right zone. There it is. We'll use my one here. Yes, we still have it. A key pair. One AWS. You don't have to have it. But we're not depending on this. Part of using Teleport is reducing this footprint of having these keys everywhere. You still need from an administrative standpoint the ability to have a backdoor scenario. So in a production environment, you don't want 50 keys out there. You don't want everybody using it, but you want to limit who can have access. So all of our users are going to be using Teleport, but if somehow the service dies or we have an issue, we need to get into the SSH server directly outside of Teleport for some reason, we still need to have that but we're limiting who is having access to that.

Allen: 00:34:19.524 So in this case, we're going to — don't do this — allow SSH from anywhere. But this is a demo box. It will be destroyed here as soon as today's webinar is over. And my user is created. And now, as a user, I'm able to log in. Teleport still has this audit trail. So we knew when this user signed in and connected to AWS. You notice I don't have EC2 connectivity showing, "Hey, I don't see what this user is doing within AWS." This is where we tie into Cloud Trail. So all this work that's being done right here from this instance is actually being managed within Cloud Trail. So I could actually log in over here with this user, go to my Cloud Trail account. In this case, it's going to be a read-only access piece here to Cloud Trail. And then I should be able to see this activity, see this connectivity, see what was happening within my Cloud Trail going on in this when I look at event history. And I'm not a Cloud Trail professional. So I can see a Teleport contractor logged in here. So you can have that ability to see what users are doing by time. Both the best things of Teleport, the best things of AWS, and tying those two together.

Allen: 00:35:41.386 So let's say I'm in here as a CloudTrail read-only user and I'm like, "You know what, I want to go to EC2 and see what that user was doing." Well, I can try, but what's going to happen is I now get API errors. So this user does not have the ability to perform these operations because my IM and roles have been defined to be very limited to only Cloud Trail. Whereas this user only has the ability to see and manage an EC2 type of instance. So that's how again, we're tying that in, being able to manage that. And so I can do this from a command line as well. So if I'm a heavy command line user, in this case, let's see here. Oh, if I look at my apps here and see which apps — I'm actually signed into Cloud Trail right now. So I can actually use Teleport to look up — let's see here. Let's see if this works without breaking. And I can actually look up some events that might be happening within AWS. So I can use the AWS CLI here via Teleport to look at information. In this case, I think that might not — yeah, that one broke. Or like an s3ls or something. Oops. s3ls. So I can run these queries within it. Teleport is auditing and managing this information. And if you notice, when I log out, you're thinking, "Well, maybe they already have their AWS configure files already set up previously." Well, I don't, because if I just try to run AWS s3ls, I'm going to get an error because I don't have my credentials. It was all managed by Teleport itself using short-lived certificates. And so, because of that, I'm able to tighten my loop down. Not having users using AWS configure and storing those AWS static credentials, we can manage and gate that through AWS itself.

Allen: 00:37:47.136 Do have a question from Thomas. Yes, this recording, I believe, will be available. So once today's sessions done, we'll make sure it's available. As well as the slides as well because I have some links on it for everybody. So hopefully, that just kind of wraps in a nutshell of what we're doing with Teleport. How we're managing access to AWS resources, right? We're doing it with authentication in that connectivity, authorization, and audit. We're letting users have access to these resources in AWS, but we're gating it. We're limiting it, right? We don't want everybody just to have access at any given time itself. One of the big questions people ask, "Hey, what about Kubernetes and access to that?" Same idea. Unfortunately, I do not have a EKS cluster up right now, but I do have — oh, actually, I do need to log back in here. So in this case, I'm going to reauthenticate and log back in and get a new certificate. We'll just show you that process here. Then, I'll show you Kubernetes access as well. So I renewed my certificate. Earlier was five hours. It's now back up to eight hours. So I can look at my Kubernetes clusters that I have access to. I'm going to go ahead and log in. And this one lives on one of my GCP servers at the moment. So now that I'm in and I can now run my Kubernetes commands that I might need to get access into those Kubernetes systems. That kubeconfig is managed by Teleport. Again, when you take this back to full circle, we have audit information. Again, we now have a different request here. A different audit trail that's based on Kubernetes. So we can see Kubernetes API calls that are being made into our system as well.

Allen: 00:39:43.474 And let me show one last thing. I know I talked a lot about the RBAC and the roles. So let me show you what those look quickly and then we'll jump into some Q&A here. We define our roles using YAML. Not JSON, excuse me. Using YAML. So whether or not you love or hate YAML, this is what we're using. And we define what users can [inaudible]. So you can see that this role here, the EC2 or Cloud Trail, how I have it defined, what a user can do, certain databases what a user can log in as, SSH, Kubernetes, what they can see, cannot do. And then that time to live. So that eight-hour certificate is derived here. So if I look at my contractor specific role here, so if I look at this contractor, by default, I don't allow them to see anything, but I do allow them to request access, which is why this contractor was able to request AWS. And this user only has a two-hour role. So we're gating and limiting that user what they can and cannot do based upon that itself.

Allen: 00:40:52.100 And so, again, I know there was a whole lot of information on Teleport itself. A lot to digest. But when you're looking at — let's go on back here to today. When we talk about, here at the beginning, right, improving — here it is. So secure your growing AWS infrastructure, how we're doing that. Using a tool like Teleport. As you add these EC2 nodes, they can auto-join into Teleport and you can manage them. Security and compliance regulations, right? As organizations are tasked to saying, "Hey, we need to know what is going on." Combination of the Teleport audit trail — audit log — that you can export to NEC, along with tools like CloudTrail with our Federated access allows organizations to do this. And then of course increasing developer productivity, right? We're all saving time and money. If I'm a new engineer like this contractor, I didn't have to get a VPN to sign up. I did not have to request access to a vault, a password vault, or a spreadsheet. Hopefully not that we're not storing secrets there. I just basically log in from a command line or from a browser base and I just start saying, "Hey, I need access," or I just start doing the work that I'm used to doing. If I need access, I can escalate that through a ticketing system. Jira or Confluence. I mean, excuse me, PagerDuty or something along that line. That then will say, "Hey, let's give this user elevated access when they need it." All done through Teleport in of itself.

Recommended resources

Allen: 00:42:23.984 So my last slide here, then we'll jump into some Q&A here. It's like, "Hey, where do I begin?" And so I've dropped a bunch of links here. So this is going to be a little bit on the link-heavy side here. That how to run it on AWS today. So I've got a couple of SSH links here of joining nodes in AWS. Some guides to databases like DynamoDB, Redis, Postgres, RDS. The AWS console that I showed off a little bit. Talks through how we do that. And then as well as deploying within and leveraging tools like EKS within Teleport itself. And then we have actually a use cases page here on our site that kind of deals a little bit more high level of what it is with regards to that aspect for AWS. And I definitely want to throw this out as well. We have a Slack community. So you can go to goteleport.com/slack. Join in that community if you're an open source user. You can talk to — actually, some of our engineers are on there. Some of our developers are out answering questions. I'm out there as well as some of our other solutions engineers. But always happy to help educate and grow knowledge of Teleport for other folks as well. Whoop. Let me leave that up here a little bit.

Q&A

Allen: 00:43:43.739 So looking at a few questions here, I've got one from our guest from Latvia. I'm not going to say her name because I will slaughter it. What CA providers are supported by Teleport? Vault, Let's Encrypt, or ACME? Great question. So Teleport is its own CA. So we have two CAs within Teleport. We have a host CA and we have a user CA. Actually, we have a new one coming out. A database CA. So we built our own CA that signs user certificates which are based for users. So if you need to get access to a server, you would — the user CA would handle that. If your nodes need to connect, it uses the host CA to connect to those at a well. But we also use Let's Encrypt and ACME for the front-end piece there. So, for example, let me go back here and I will show you my application. So let's say I have an internal base Git tool. I've got one called Gogs, which is basically an open source of Git. Teleport's going to look at me. You notice I have a fully qualified domain name. And this certificate is actually a — let's see here. This is a Let's Encrypt certificate that is signed and managed by Teleport itself. So we have that integration tied in. Now you could tie in your own root certs if you have them. Teleport also has the support for hardware HSMs or AWS HSM. So if you have an HSM that you want to tie into Teleport as well, you can leverage that. Hopefully, that answers your question along that line.

Allen: 00:45:28.287 Another question that I see people ask a bit, right? Who's our typical customer and what triggers them to buy Teleport? That's a I won't say loaded question. It's a great question. We see a lot of customers in the fintech type of space or even healthcare. Starting to see a lot in retail and growth models there. A lot of cloud-native customers as well. And the biggest thing I think that really compels organizations to buy Teleport is the ability to have everything all under one umbrella, right? They can write because our tool is open source. You can write this. You can fork it. But with advisers, we have a support model. We have a customer success team that is, bar none, probably one of the top customer support teams I've ever worked with. Really robust onboarding experience that helps customers to make sure that questions that they ask or deployments are all handled with our onboarding scenario. And then SSO integration. So tying into Okta or Active Directory. Things along that line which require a little bit more work. That's part of our enterprise package as well.

Allen: 00:46:53.990 And another question is, how do I get more access information to this? Through AWS, right? So we're actually on the AWS Marketplace. So if you are working with someone here at Teleport already, like an account person, you say, "Hey, we have EDP spend within AWS, or we'd like to get it through a private offer in the marketplace." Please reach out. That's beyond me as my pay grade on that aspect. But definitely reach out and we can get you in conversations with those account folks that can help answer those questions. And a lot of organizations that have EDP spend or budget within that realm work Teleport into that. It's a great way to tie AWS and Teleport really well together along that line. And another question here I see is — what was it? — who can control provision and access AWS resources? That really comes down to you as an organization defining that, right? So in my example here, I had my contractor that was defining that. Well, that comes up to you as an org. And part of our onboarding team that works with our customers is deploying the correct roles, which can be really elaborate. This is my demo environment. I've got 40 roles. And we've got customers that have hundreds or thousands of different roles. Is architecting and defining using really best practices that both AWS puts out as far as accessing through IAM policies. Teleport as well. Teleport roles and defining that. So you're making sure you're getting access to users. In our docs, our documentation page — which I don't think I actually listed on that one slide — really details heavily into our roles, our reference, and architecture. Can really assist with that, for sure.

Allen: 00:49:00.286 Let me see here. Don't think we have any others, and I'm rambling a little bit. So I'm looking at time, and we're about 52 minutes after the hour here. And want to leave it open here if anyone else has any other questions here. Let me get back into this last slide here that folks can see. So if you wanted to write some of these links down or check them out, this is where you can go. And again, today's webinar not designed to be a full-on deep dive into Teleport. Really more of a fire hose. Give you an idea of how we're leveraging AWS with Teleport for customers that live and work within AWS. And we're happy to go a little bit more detail into some specific protocols working with our team here. If you want to say, "Hey, I've got this unique use case," please let us know because we'd love to help out for sure. But I don't see any other questions. And we'll give you all a few minutes back on your time today. Again, my name is Allen Vailliencourt with Teleport. And thank you on behalf of all of us here at Teleport. Thanks for attending today's webinar. And thank you for your interest in Teleport and AWS. Have a great day.