Simplifying Zero Trust Security for AWS with Teleport

Simplifying Zero Trust Security for AWS with Teleport

Managing secure access has become a critical challenge for organizations using AWS at scale. Traditional security approaches, like passwords and virtual private networks (VPNs), are not sufficient to protect growing infrastructures while maintaining productivity. This webinar, "Simplifying Zero Trust Security for AWS with Teleport," explores how Teleport enables a modern, identity-first approach to AWS access.

Learn how Teleport implements passwordless authentication, enforces granular access controls, and provides complete visibility into AWS activity. Discover how features like cryptographic identity, just-in-time access privileges, identity and policy governance, and centralized auditing streamline workflows enhance security, and simplify compliance. Whether you're managing Amazon Elastic Compute Cloud (Amazon EC2), Amazon Relational Database Service (Amazon RDS), or Amazon Elastic Kubernetes Service (Amazon EKS), Teleport equips your teams to scale securely and efficiently. Join us to see how Teleport is redefining AWS infrastructure access with Zero Trust.

Key Highlights:

• Zero Trust Access for AWS: Implement an identity-first, passwordless approach to secure AWS resources, replacing traditional methods like VPNs and static credentials.
• Passwordless Authentication: Enhance security and reduce attack surfaces with short-lived certificates for AWS CLI, Management Console, and API access.
• Granular Access Controls: Enforce role-based access policies tailored to user personas, ensuring least-privilege principles across EC2, EKS, RDS, and more.

Who Should Attend:

• DevOps and Cloud Engineers looking to streamline secure access to AWS resources without compromising productivity.
• Infrastructure Security Professionals focused on implementing Zero Trust principles and improving compliance in cloud environments.
• Infrastructure and Platform Teams managing multi-account AWS deployments and seeking to simplify access control at scale.

Transcript - Simplifying Zero Trust Security for AWS

Eddie: Okay. Let's get started. Again, I'm Eddie Glenn, Director of Product Marketing here at Teleport, and I'm really excited about the two gentlemen that we have on today's talk. We've got Ashok Mahajan, and I'm sorry if I mispronounced your name, from AWS. He is a solutions architect. I'm going to give him a minute just to introduce himself. And then we also have Weston Eakman from Teleport. He's a solutions engineer here at Teleport. So guys, can you just say a few words about yourself?

Ashok: Sure. Thanks, Eddie. Hello, everyone. My name is Ashok Mahajan, and I'm a Senior Partner Solution Architect at Amazon Web Services. I'm part of the Global Startup team focusing on startups, and in my role specifically, I work with security startups in their enablement journey on AWS that focus on co-build and go-to-market motions. I've been in InfoSec for over 18 years now with expertise in identity and access management, application security, data protection, and cloud migration across multiple domains.

Eddie: Thank you.

Weston: Awesome. And great to meet you, everybody. My name is Weston Eakman. I'm the Senior Partner Solutions Engineer here, focusing mainly on enabling partners to either learn more about Teleport and kind of what this space looks like and very much on the technical side. Right?

Eddie: Perfect. Thank you. Okay. Before we get started, just have a few housekeeping items that I wanted to cover. There is a chat box on the right-hand side of your screen. So feel free to ask questions, post comments, engage with us there. We definitely would like for this to be interactive. And as time permits, we will try to respond to those. We may hold all the questions to the end. But yeah. Please definitely participate. And then besides the chat box, there is a Q&A tab for you to actually ask questions. And those are the ones that we will get to at the end. And then there is a tab called Docs tab. And we have some resources there that we think you will find useful. And then within about 24 hours after this webinar is done, we will send you a copy of the recording. So you don't have to spend time taking notes, but if you want to, of course, obviously, that's okay. So with that, let's go ahead and get started. Next slide, please.

Webinar agenda

Eddie: So this is what we'll be covering today. We're going to talk about some of the unique challenges, especially around engineering productivity and security that come with modern infrastructure. We're then going to turn things over to AWS, and they're going to talk about zero trust with AWS. And then we'll talk about how Teleport can help with zero trust on AWS. And then probably the part I'm most excited about is the demo that we have prepared for you guys today, where we'll show you Teleport with AWS. And then finally, we'll get to those questions at the end. So let's move to the next slide, please. So I didn't really spend any time introducing myself when the others did. So I'll just take a minute. My background is I'm in software engineering. But when I was developing software, it was much different than what we experience today. And that has brought in a lot of unique challenges around software development, the types of infrastructure that's used in software development environments now. And it makes it really urgent for us to think about how do we modernize what we do and how do we modernize the access to infrastructure resources that we have. And there are things that have changed significantly over even just the past 5 years. The complexity of our infrastructure is much different than what it used to be.

Unique challenges with modern infrastructure

Eddie: When I was developing software, we had one or two servers that were on-prem, locked up in a room, very limited access. That's not how it is today. Infrastructure is spread around the world. It's in the cloud. It's in multi-cloud environments, hybrid clouds. Software development is spread around the world — remote developers. It's extremely complex and just the types of tools that are used. And because of the complexity, this starts to drive high operational and management overhead. And I know as developers, that's one thing that we do not like — is that overhead. So that's one thing that I think really starts to drive why we have to modernize how we access infrastructure resources. Then the other issue that I know we all have seen in the news is that identity has been a primary attack vector for organizations. So 75% of cyber-attacks are targeting people. They target people so they can get to valuable infrastructure resources. And it looks for human error that people make with releasing their credentials, or maybe they aren't storing their credentials properly to begin with. Then we definitely have seen a lot of movement in the artificial intelligence area. It's making attacks, especially phishing-based attacks, much more difficult to distinguish between what's real and what's a phishing attack. And then a result of these things, what we've also seen is that executives in charge, so our manager's manager's manager, they're now being held responsible for any kind of breaches or compromises that happen. So when I think about why is this something that I'm excited about talking about today, I think these are four reasons why we're all here and this is an important topic for us to talk about.

Eddie: So before we dive into the details, I kind of want to think of an analogy because I was explaining to a friend of mine what it was that Teleport does. And I know there are some of you that are really technical and some of you that might just — you'd be more business-focused or security-focused and don't completely understand what's the big deal with modern infrastructure and why modern infrastructure becomes difficult. So I like to think about an analogy where we've got a Twilight Zone hotel. If you can just click through all these buildouts, that would be great. So think about a Twilight Zone hotel. So it's not like a regular hotel. New guests arrive, old guests leave, and obviously, every guest needs a key to their room. But unlike a traditional hotel, Twilight Zone hotel, we've got rooms that are constantly changing. So what used to be on the third floor at the end of the hall is now on the second floor next to the elevator. New rooms are being added and removed in real time. Rooms exist for a time and then they disappear. So the complexity of the hotel, knowing where anything is at any given time becomes extremely hard for not only the guests, but also the staff that's operating the hotel. And when you think about the staff, you've got bell clerks, bellhops, desk clerks, maintenance, room service, all of that. They all need access to different parts of the hotel. They need access to rooms. But with all this constantly changing, it's very hard for them to manage.

Eddie: And that's if you're thinking in terms of just a single hotel. But when we've got a Twilight Zone hotel, it's actually multiple hotels. So this complexity, as you can see, starts to exponentially grow because of the things that have to be managed. And it doesn't take long for the front desk to get overwhelmed. And people are waiting. They're arguing. They're complaining about not having access to the room that they had rented. Staff can't get their jobs done because they can't get to the room that needs to be serviced or room service delivered. Guests are given access to entire floors, maybe to an entire building, because someone just forgot. The night clerk was so overwhelmed. They just said, "Hey, here's access to the entire floor. I don't remember which room you're in. Just go to the entire floor." And then we've also got the element of dishonesty, that misconduct, that there are thieves that are wanting to steal from the hotel and from the guests. So they're just throwing on the hotel uniforms, and they're roaming around the buildings freely.

Eddie: So I hope everyone can see the obvious analogy between modern infrastructure and this Twilight Zone hotel, but maybe it's time for us to think about a new approach. And that's what the bulk of this talk today is going to be about. What if we just got rid of the keys altogether? What if we used something about that person that made them unique, irrefutable ID on arrival? So not just the person, but it's every asset within the room. It's every room itself, every luggage cart. They all received identities that was tied to them in a unique way. And then what if this elevator scanned that identity and just took them to where they needed to go? So they didn't even need to know what floor they were on. They just scanned their ID, their face, or their fingerprint, and the elevator knew where to take them. And then what if employees' access to these various rooms was granted based on a need basis only. So the employee didn't have just access to every room in the hotel. They would only have access to the room that they needed to access at that particular moment.

Eddie: And then the other aspect of this is, obviously, we need to be concerned about the security of our guests. What if we can monitor every move that anyone made on which room were they accessing, which guest luggage did they touch, what guest bill do they modify or edit? So again, high-level analogy. I just wanted to set the stage before I turn this over to AWS. But before I did that, I just wanted to talk about if we step back and think about modern infrastructure today and modern software development environments, it's necessary and imperative that we balance innovation and scale with the growing attack surface. And I think this would be a much different conversation if we only had to think about one of these three. But when you combine the competitive pressures that your organization faces to have new features and new capabilities to get the market share that they want, to be able to scale that in a global fashion, and then also to be aware that the attack surface is growing in a way that makes this problem extremely hard for us to take into account. So let's move on to the next slide, please.

Modern access control

Eddie: And before I turn this over, I think the last thing I want to talk here is when we do talk about modern access control, and I've kind of hinted on that in the analogy, but modern access control — when we talk about it, we're talking about four different things. First one is cryptographic identity. So basically, this is an identity that is going to be tied to either a person or a machine, or maybe it's to a software load, and we know that that identity cannot be modified. It cannot be stolen because it's tied to some perhaps biometric characteristic of a person, if we're talking about people. So that's the foundation. We've got to have cryptographic identities. Then as we'll talk here in just a minute, zero-trust networking becomes extremely important. We want to be able to have session-level encryption and authentication between people and non-people, so people and machines, and machines and workloads, and workloads and workloads. Then we need to be able to offer secret list authentication and ephemeral privileges. So privileges that are granted only when they're needed. They can be taken away very easily, base everything off of least privilege, on-demand access. And then finally, the ability to perform security intelligence. So basically, have a single source of truth. It doesn't matter if the resources live in AWS or they live in a server in your building or some other kind of asset. There's a single source of truth for managing that infrastructure access across all of your organization. So now I'm going to turn this over to AWS and let's talk about zero trust.

Zero trust with AWS

Ashok: Thanks, Eddie. That was a great overview of some of the challenges that we face in modern infrastructure, right? Now, before I talk about zero trust, I want to highlight one of the most critical challenge in modern system architecture. It is finding a sweet spot between security and availability. In an era where cybersecurity challenges are becoming increasingly sophisticated, user expectations for 24-by-7 availability continue to rise. So this balance between security and availability has never been more crucial. And every organization takes a different approach to solve this. Some organizations put more emphasis on architecture patterns and solutions and avoid zero trust as a buzzword. Some are unclear on how to move forward, and some are looking for an established and proven mechanism. Whether you are managing cloud infrastructure, handling sensitive data, or even scaling enterprise applications, the fundamental question is, how do we optimally balance security and availability for the system that our consumers are accessing?

Ashok: So with that in mind, let's start by defining zero trust. Zero trust is a security model centered on the idea that access to data should not be solely based on network location. It requires user and system to prove their identity and trustworthiness and force fine-grained identity-based authorization rules before allowing them access to application, data, and other systems. I want to draw your attention to these specific intentional words upfront, security model. We really need to believe that zero trust is a way of thinking about security. It's the how and not the what. When we look at traditional approach to security, it is more parameter-based. But with zero trust, we are no longer going to rely on the network parameter. Instead, we are going to bring a wealth of additional resources of context, whether it's identity, device, and more, in order to make a more granular and frequent decision about who can access what. And I'm sure we all can agree that definitions sometimes are necessary, but often I find that working through metaphors really helps bring the abstract to life.

Ashok: To really understand zero trust, imagine an art museum. Art museums are filled with incredibly valuable assets, but they are not built to keep people out. They are built to get the right people in so that they can interact and enjoy the art. The building's exterior is still incredibly useful, right? It keeps the wind, rain, snow, and things of that sort away, and allows the staff to set the proper environmental factors like temperature and humidity. But the crux of security comes from the museum operating as a system of norms with explicitly directed behavior, monitoring and observation, and detective controls. While there are many spaces in the museum that someone can access, as long as you go closer to the priceless piece of art, controls become more stringent. Things like ropes and signs that tell you what's permissible or not. Controls in action like laser boundary detection, touch sensors, cloud alarms, strobe lights. Some of these are controls are placed based on the value of the art. Of course, security personnel is there, but you cannot have so many security personnel within each room. That would not only destroy the natural ambience, but also kind of defeats the purpose of the museum itself. So instead of just putting the controls, you have the security guards monitoring from a control room, watching things in action, and react quickly as and when needed.

Ashok: Now, with that context in mind, let's talk about some of the guiding principles that you can actually follow to build a zero-trust architecture. Let's start by challenging a common misconception — this idea that we need to make a binary choice between parameter-based and identity-based security. On one side, we have the identity-centric approach. It's modern, sophisticated, and promises extremely granular control. The idea is compelling — authenticate and authorize each and every request, creating a zero-trust environment where nothing is implicitly trusted. On the other hand, there is a network-centric model. It's familiar, battle-tested, and frankly, easier to reason about. Network boundaries and parameters provide a vital purpose. They filter out unnecessary noise and reduce the attack surface before requests can even reach an application layer. This approach has a significant value. Remember the definition of zero trust we just looked at? Now let's look at, in the next slide, how we need to rethink about these security mechanisms, not as an either/or, but with an AND condition. So rather than choosing between these security mechanisms, the real skill lies in understanding how to layer these approaches effectively. Think of it as a defense-in-depth mechanism rather than defense-and-replacement. The parameter is in depth. It's evolved to become one of the multiple layers in your security strategy. The key is knowing when and how to apply each approach to achieve the right balance of security and operational efficiency. Next slide.

Ashok: The second principle is what I believe is the most crucial principle when applying zero trust, and that is focusing on specific use cases. Eddie, when he was talking — he also highlighted some of the aspects in this arena. One of the biggest challenges we face is that zero trust can mean vastly different things depending upon who you are talking to. And this is actually one of the main reasons we see so many confusion and ambiguity in the industry as well. There is an interesting fact. Organizations might share the same underlying principle, like acknowledging the network boundaries that are relevant as much as they used to be. But the key here is they often differ, excuse me, drastically in what they're actually trying to achieve. Situation is not the same for every organization. Some organizations are primarily focused on enabling end-user mobility. Others are laser-focused on eliminating unnecessary little movement. And some are dealing with complex third-party access scenarios. This is why I strongly advocate for working backwards from a specific use case or problem you're trying to solve. Instead of starting with zero trust as a concept, start with a specific problem you're trying to resolve. Ask yourself — what are my primary security pain points? What are specific risks I'm trying to address? What does success look like for my organization? When we frame it in this way, the conversation becomes more productive. We move from an abstract concept to a concrete solution that actually solves a real problem. In my experience, this use case-driven approach is what really separates a zero-trust implementation from those that get stuck in a conceptual phase to an actually practical, focused, and outcome-driven approach.

Ashok: The third principle I want to focus on is how to apply these concepts in accordance with the value of system and the data being protected. Remember the art museum example I was giving earlier highlighting the value and controls that we need to put in place based on the value of the art. Zero-trust implementation should be pragmatic and value-driven, not one-size-fit-all approach. While it enhances the existing security controls through improved visibility and software-defined capabilities, especially in cloud environment, it should not be viewed as a complete replacement of traditional security measures. Instead, think of it as an additional layer that complements existing control in line with the defense and defense approach. The key here is to apply zero-trust principles selectively based on the value and sensitivity of your system and data. Traditional network controls and a perimeter will remain relevant for many businesses, and the goal is to measure improvement with existing security controls as and when required based on the business needs. This balanced approach ensures we get the maximum security benefit while maintaining operational efficiency.

Ashok: Next slide. Now, when we look at the traditional fine-grained authorizations and the way it is implemented, you see most often than not, it is implemented as a custom code within an application. This approach creates significant problems. First, it puts an extra burden on developers, requiring them to fully understand complex permission structure. Second, it makes the system inflexible. Any permission changes require a code modification and rebuild the application. And finally, this approach complicates audit process and increase the likelihood of audit finding because your authorization logic is scattered throughout that code rather than being centrally managed. This highlights the need for a more modern externalized authorization approach that separates these controls from application code.

Ashok: Now, when we look at a simple AWS example that provides a compelling real-world example of zero-trust principle in action, even though it's often overlooked, is the example of how you access AWS APIs. AWS API infrastructure handles millions of customer requests daily across various networks, yet its security does not rely on network controls. Instead, it demonstrates a true zero trust through TLS and SIGv4 protocol, where every single API request, even at massive scale, undergoes through authentication and authorization. This approach, pioneered by AWS, has become so fundamental to cloud security that it's even considered a standard practice, perhaps explaining why it's rarely even highlighted in a zero-trust conversation. It's a proven model showing how zero trust can work at a global scale without depending upon network security. Cloud security at AWS is our highest priority. And I do want to touch upon our Shared Responsibility Model where AWS is responsible for security of the cloud, the physical infrastructure, the facilities, the actual compute and building block that runs these AWS services. You as a customer are responsible for security in the cloud. This means you secure your workload and application that you deploy onto cloud and have the flexibility to put more emphasis on the security of sensitive data and adjust as and when needed based on your specific business need. AWS actually provides you with various services and features that you can use based on your specific business scenarios, specific business requirements, and based on your customer needs.

Ashok: Let me quickly introduce some of these AWS services here. First is AWS Verified Access, which provides secure access to corporate applications and resources without a VPN. It enhances your security posture by allowing you to define fine-grade access policies based on a user's identity and device security state and enforcing policies on every access request. It simplifies security operations by allowing administrators to create groups and manage access policies for application and resources with similar requirements from a single interface. Second is Amazon Verified Permissions, which is a fully managed authorization service that uses the CDA policy language. So instead of building your own application-specific authorization system, you can add granular permissions based on your application. With Verified Permissions, developers can build applications faster by externalizing authorization, centralizing policy management, and you can also align your authorization with zero-trust principles. Your application or your local policy enforcement, like an API gateway, can call Verified Permissions to determine if a user can access a resource or not. It's as simple as that.

Ashok: And the last one I want to highlight here is Amazon VPC Lattice, which is an application networking service that gives you a consistent way to connect, secure, and monitor service-to-service and service-to-resource communication without any prior networking experience. With VPC Lattice, you define the guardrails and policies that govern the network, and your developers can connect their services without any knowledge of the underlying network. Along with these native AWS services, we also have a strong network of AWS partners with deep expertise and, excuse me, specialization solution to meet your specific needs. By leveraging AWS services with these partners' solutions like Teleport, you can scale your AWS infrastructure while reducing the potential of unintentionally opening up your AWS resources to unauthorized access. Now let's hear more about Teleport from our Teleport partner and see how Teleport can help you with zero-trust implementation.

How to manage zero trust at scale with Teleport

Eddie: Thank you very much. That was awesome. I really appreciated that information. So you said something that I just wanted to key off of, and that is at scale. And that's really what Teleport is focused on — helping our customers implement zero trust and secure their infrastructure access at scale. And with modern infrastructure, that is extremely important. And there are two things that kind of drive how we have architected and designed our product, and that is we want to be sure that we can help our customers achieve velocity of their engineering teams. So keep any kind of slowness that might happen from an infrastructure request from occurring within your engineering teams. So help you accelerate time to market. And then also equally as important, and some people might even say more important, ensure the resiliency of your critical infrastructure systems. So protect those from human error or malicious compromise.

Eddie: So some of the things that we are able to offer to AWS customers is being able to help centralize access that's been designed specifically for AWS infrastructure. And one of the aspects of that is for those customers that have multiple AWS accounts. How can you consolidate infrastructure access across those multiple accounts? And that's something that Teleport can help with. Obviously, help with passwordless identity-first access so that we have a more secure means for your users to access critical resources. And then obviously, we support a wide range of AWS services, including ECT, EKS, RDS, etc.

Eddie: So in terms of password lists, we like saying goodbye to passwords and static keys, so SSH keys, API keys, etc. Basically, the way we deal with identities is using short-lived certificates for secure authentication. This helps our customers eliminate the risk of stolen credentials. And then we make this seamless with AWS command line interface as well as the management console. We also are able to provide very fine-grained control across AWS resources using attribute-based control, ABAC. This helps you ensure and implement least privilege and zero-trust principles. We are able to offer customized policies for EC2 and then Just-in-time privileges for temporary elevated access. And we'll see some of these in action when we get to the demo part of today's webinar.

Eddie: And then we all work in industries and markets that have regulatory concerns. So Teleport is able to provide insights that are often needed for regulatory compliance. We do things like logging AWS's CloudTrail for seamless auditing. We record SSH sessions and store those results in S3 and then provide real-time visibility into whose access, what resource, when, and provide that visibility to our customers. And then when we look at the platform that we're able to offer that provides this modern infrastructure security access, we divide it into three areas. One, where we're able to provide an access to all types of infrastructure resources, one that helps with governance around being able to answer questions about who has access to what resources or policies being enforced or not being enforced. And then the third area is around identity and governance, being able to monitor and lock identities and provide and issue Device Trust for those devices that are accessing your infrastructure resources. Next slide, please. Okay. Now this is the part that I've been really trying to get to because I want to be able to save enough time for us to do a very thorough demo. So I'd like to turn this over to Wes now, and he's going to demo how Teleport works with AWS.

Short demo of Teleport and AWS

Weston: Perfect. Thank you so much, Eddie. Thank you so much, Ashok, for going through all of that information. Before jumping straight into the demo, I always like to have kind of a visual of how Teleport works. And then you can kind of relate it back when we're going through the demo, kind of understand what this flow looks like without going into it just blind, right? Anyway, I really like the hotel analogy. And I'm going to stick with kind of the idea of rooms and analogy. So how I really like to look at Teleport, where Teleport is acting as a proxy, and I like to consider Teleport proxy a room. And the only way to get into that room is through a single door. And then to get through that door, you have to have some sort of identity-based access. And what's great about Teleport, and as you'll learn this as we kind of walk through that, is that we're really meant to be complementing and enhancing your already existing workflow to help with kind of the day-to-day work that you guys are doing.

Weston: And so with that being said, that identity-based access to go through, we would integrate with something like an Okta or a Ping Identity, whatever your SSL might be. And so once you have the identity-based access, that's where the ephemeral short-lived certs come in. And so because we act as that certificate authority, we hand a short-lived cert off to the human or non-human identity, right? And so just as in the case of the kind of hotel, if you drop your key card, by the time they find it and try to use it, that certificate's not usable anymore, right? And so by default, we do something like eight hours, but that can be managed and reconfigured to whatever needs of your companies are. Again, we have some out-of-the-box things that we find best practice, but everything is manageable and configurable.

Weston: And so when the human or non-human entity enters into the room — door closes behind them — we have two different portals set up. And those two portals represent two different workflows. One portal is fully colored, and then the other portal is going to be grayed out. And so what the first portal is representative of is what we have given pre-configured for that user immediate access to. So when we think about eliminating attack surfaces every which way in kind of this least privileged, zero-trust environment, when we give access to, say, someone who's an intern, and there's 5,000 different resources within your environment. But because of how we configured the engineer, they only see five different brightly lit-up portals, right? And so they don't even know about the other existing 4,995 resources. They only know about those five, and they can only access into those five whenever they want. And this is usually something like that for interns like staging, environment, QA, something of that nature.

Weston: Now, for the second portal, the grayed-out one, this represents a request workflow. So think, now we went to an intern. We're going to go to a principal engineer. Say there's a break-glass moment. There's 20-minute SLA into fixing this bug. And say you're e-commerce and your checkout is offline. And this needs to be fixed right now because every second you wait and waste, that's real money that's lost. And so you want immediate access. So as soon as the engineer learns about it going down, it touches that grayed-out portal, and a pop-out comes out saying, "Hey, I need access to this for," let's say, "two hours," give a description. And then I'll go off to over here as Just-in-time Access to whatever notification system that you are currently using within your environment, right? And it goes straight to the approver. And as soon as they approve, that'll allow them to go in. Now, we also have methods of adding in keywords that'll give you automatic access and doesn't need to get to an approver. So maybe something like a checkout being completely disabled warrants support automatically jumping in to fix that issue. So something in that essence. So again, we're here just to make sure that we're complementing, enhancing, and getting you to available within your entire infrastructure.

Weston: So now that we understand those two types of workflows, how are we actually getting to the resources itself? And so the way that we're joining the resources — and this could be multi-cloud, and we definitely see AWS there. This could be on-prem. And what we do is create a reverse tunnel. And so from that reverse tunnel, because we're joined, this is how we eliminate secrets, right? So once you're in that room, you're already pre-configured to have access. You're pre-configured to — say Kubernetes. You can only go into this node, into this namespace, into this pod, using only these types of verbs while you're in there, all defined, right? And then being able to jump in and out when you can and when you need to because it's automatically configured. And so the types of services that we can jump into with infrastructure is going to be something like SSH, databases, Windows servers, Application Access, as well as Kubernetes. So a wide breadth from a single point of entry predefined. And so something that also always comes up saying, "That's awesome. You guys have just that direct connection." But people are going to be people. And people at times want to find an easier way to access even though it's already an easy way to access. And so maybe an engineer, not malicious by any means, creates something kind of a backdoor with SSH key. We do have a feature that ensures that if something like that happens, we'll go ahead and alert the correct people and so we can take that down. So we ensure that correct flow of work.

Weston: Awesome. And the last thing I want to mention here, because especially when Eddie was talking about compliance and what our auditing looks like, what we've seen in the past, especially if you have multiple AWS accounts and then multiple data centers, multiple clouds, all those audit logs live in their own areas. So if you have a data center with databases over here, AWS, maybe you have Windows over here; maybe you have a data center too where they have some Kubernetes. All of that, if you're trying to find and piece together like a thousand-piece puzzle, what the whole picture looks like from some sort of incident, you have to go here, here, here, here, here, here, here, here — all over the place. That becomes unmanageable. And so with Teleport's access platform, we have all the auditing in one section. So when you're jumping from resource to resource to resource, we can see, "Hey, Weston did all these things in this sequential timeline," and we know exactly where he's been. And then the second piece of that kind of auditing is that we also provide session recordings, and we'll jump into that in just a moment. But it gives you easy access to see exactly what the inputs are and what the outputs are within that resource itself.

Weston: Cool. So let's jump into the actual dashboard because I'm sure we've been waiting to get into that. Appreciate everybody’s patience and everybody’s attention. So jumping over here — this is my dashboard demo. Again, this is the front door. We're integrated with Okta. So here, I'm just going to go ahead and click on Okta. And this will go through kind of the whole portion of handing me over the short-lived certificate. And so here, kind of as I had mentioned, the different portals representing the different workflows, we have the fully colored ones that gives us automatic access into specific resources. And then we have grayed-out areas, which you can see is indicative of the request workflow with it saying Request Access here.

Weston: So what does it look like when we actually jump into something? So I'll jump into three different portions and then show you what the request workflow looks like. So the first portion — obviously, we want to see AWS. So we do have the ability to see the AWS console itself with Teleport helping into that access. And so when we view the launch portion, it's going to show you multiple — if configured this way — ways to interact on the console. And you can see that there's multiple different IAM roles. So I'm going to go into example read-only access to show you that — right? — we are in fact in read access only because then I can go in here and see, okay, there's instances running. There's 28 of them. Let's jump into this one. Let's see if we can do an action of connecting. Once we're in here, we can go ahead and connect in. And because we have a specific read-only access — right? — we've been denied any kind of connection into the SSH session here because that's not allowed. We haven't given access in this way because, again, what we're doing and what we're trying to accomplish, and what we've implemented is that zero trust practice, right? Especially going by the general principles that Ashok had shown us earlier.

Weston: And so exiting out of here, let's go over here, back to resources. We can jump into an SSH server as well. And what's great about this is we do have tags and labels that you can associate with each of these resources. We can get some quick and easy metadata, right? The status, amount of memory, storage, what the uptime looks like. We know this is AWS and where it lives — right — as well as kind of location there too, with all those taggings. And again, when we jump into Connect, we're given specific users, and those users are configured to have only specific privileges, right? And so when we jump into something like `weston.eakman`, myself, we can see the CLI show itself. And something I forgot to mention at the beginning — there's three different ways to interact and jump into access. One that we're going to stick with — because it's just a little easier when we're sharing just one window, is through a web UI. You can download an application, that's a Teleport application, onto your local workstation, or you can go through your native CLI. So again, we don't want anybody to feel like they're forced to use a completely new tool. We want to make sure that you're still going through the exact same workflow. All we want to do is enhance and complement.

Weston: So just like in any kind of SSH session, we can do some `cd`, `ls`, see what's going on — right? — do a quick `htop`. And then once I'm done with that, I can go ahead and exit. And we'll go through the audit logs in just a moment. Another piece of infrastructure I wanted to go ahead and show was our Windows environment. And again, we can see this is in AWS. And so once we click in, again, we have the different types of users. I don't need admin access right now, so I'm going to go ahead and jump into my own user. And when we connect passwordlessly over into the Windows RDP session, we can see everything kind of spinning up, right? I was in here earlier today, just opened up this here. You can move it around as you want to, right? Click this down here. And then once I'm done, I can go ahead and exit out. Awesome.

Weston: And then the last thing I wanted to show is getting access, requesting access into an environment. So if we want something like Amazon RDS PostgreSQL — this is obviously Amazon — go ahead and do Request Access, and we see a pop-up come over. You have the option of selecting the specific reviewer. This would be already configured when you first deploy Teleport, so there's not usually a need for that. You can say when you need it. It's immediately. Or if we're doing some sort of change management and you know the day that it's going to be needed, we can go ahead and request for the specific date and then the duration of access as well, right? And this can be obviously configured. For this is just on the hour mark from one to eight. And then the last thing is describing a request. So this would be, "Hey, this is for change management in the future. We've already approved everything. We just need to make sure we get in." Or if you need a break-glass moment, you can describe it that way. Or if there's a specific word that triggers immediate access, that can be used as well and configured.

Weston: Perfect. So let's cancel out of that. The next portion I wanted to show was our auditing. And this is our text-based audit log. And as you can see, what we just went through has all been a push to here, right? We see kind of the Windows desktop session, where the certificate was issued as we went through. And we can see with full detail what this information is. And I feel like I'm just kind of a broken record at this point. Again, to fit in your workflow, we can also ship all of this to your SIEM as well. So I know a lot of security folks, they are using what they're using — they have been using — and there's not a reason for them to jump out of the tool that they have and learn something new when there's so much else going on. But being able to provide enriched data and very granular specific data for access about when and where — it can all come from one place rather than, again, from data center one, data center two, AWS account one, AWS account two, etc., etc., etc. And so it's all consolidated into one area. Again, modernizing what access looks like, modernizing what security looks like, modernizing what compliance looks like, simplifying it.

Weston: And the next portion I wanted to show was our session recording. You can see a couple of things have happened today, which is great. I'll just jump into the Windows. And so as you can see exactly what we saw before, as soon as you enter, we're getting welcomed in. We can go ahead and see the Windows Explorer that we have. You can see me moving it around a little bit, closing it out, and then popping open that Windows key down at the bottom. So exactly what I did in there, we see exactly what happened. And then we exited gracefully. Awesome. And lastly, what I want to show is I think visibility is incredibly important, right? We say that we know what's going on and we know how things are configured. But if we can't map it out, I think that would be an issue because you want to see who has access to what. And then from the right side, resources, who has access to those resources itself, right? And without that kind of visibility, you can't have real trust. So some sort of graph or mapping is needed.

Weston: And so that leads me straight into our policy graph. And so we'll go ahead and take a look at Bob, who is an AWS IAM user. And what we'll see is from left to right, what Bob has access into and how he has access into it, and how it's defined as well. So again, we click on this. We see the full view access. We can jump in, and here we can see, okay, Bob. Now we see some lines coming off them, three of them, right? Okay. So Bob has AWS IAM user group here, IAM group user over here, right? Combinations of AWS coming in, what those resource masks are, and then all the different resources he has access to. So when I zoom out, you can see all of his access. So if he has access into here, what does he have access into in other resources as well? So in terms of compliance, when you want to really be able to prove you've secured with least privileges, aligned yourself with zero trust, you want to make sure that you have that visibility as well. And then even so, when we look from right to left, and this is going to show a massive amount of people on the left-hand side, but we can also reconfigure this to have SQL commands to really hone in on something specific. But you can see everybody from right to left as well, right? And then getting as granular as possible and kind of showing a really pretty artwork on the left-hand side.

Weston: Awesome. And one last thing I wanted to show — I love this feature, especially when we're considering what holds all the data, what are the most important things. And so what we could do with this kind of policy graph is we can actually track it as a crown — sorry, track it as a crown jewel. And so that if access changes in any way, they'll go ahead and notify the right people, because we configured it properly, to go ahead and let them know, "Hey, this has changed. We need to do something about it." Or "That was actually acceptable from our change management." Perfect. Well, that kind of sums up what I wanted to hopefully talk about. I know there's a lot more that we have available. And if you want to see more, please reach out to us over here at Teleport. We'll be able to look at this through the lens of what your use cases are. Kind of Ashok talked about before — we want to see what our issue is and then move from there, right? And I think coming in, seeing a broad view is very nice, but we want to be able to tell you kind of your specifics. So Eddie, I think I can hop it back over to you for some final thoughts.

Eddie: Awesome. I really appreciate that. So I just wanted to point out a few things, tie it all together. Modern infrastructure does require modern infrastructure access. And you got to think about two things. And one is convenience for the engineering teams. They need access when they need access. If they need to ask for new access, it needs to be done in a way that's convenient and doesn't take 2-3 days to get that granted. We focused on that aspect of the solution around infrastructure access. Another aspect of the solution is that infrastructure is extremely complex. We're dealing with different platforms, AWS being one of them, local resources being another. We're dealing with people. We're dealing with machines. We're dealing with workloads. From a compliance standpoint, this brings us to the third point — that we need to be able to provide the documentation and the records across all of those infrastructure resources. Even though all of them might be — they all might have their own way of providing recordings with Teleport, we can do that in a single way. We can implement least privileged, zero-trust access very easily. We support multi-cloud environments that are scalable. And as I said, we are designed for engineering workflows. And I think this is going to get us close to the point where we can start answering some questions that have come in. What's the next slide here, Wes?

Weston: Yeah. Absolutely.

Q&A session

Eddie: Oh, I just wanted to point this out. It's a resource that you can get by clicking on the Docs tab, but it's all about, how can you implement zero trust, especially or specifically for AWS infrastructure? So with that, I'm going to start with just a few questions that have come in, and I think I can answer these because they're not that technical. "Where are those session recordings stored?" So this is going back to what you covered in your demo. So if you're using our self-managed version of Teleport, we store those in S3. But you could put them into an S3 object that you manage. If you're using a self-hosted version, it's stored locally there. Or if you want to put them into an S3 object. So that's the answer for that question. Thank you for asking it. The next question is, "Do you hook into AWS IAM to provide permissions to resources?" And yes. We do. We do that. And the next question I'm going to pass over to Ashok. "How does zero trust affect multi-account AWS strategy?

Ashok: Sure. Thanks, Eddie. And thanks, Wes. That was a great insight into what Teleport can do. So let me answer this question with an example in relationship to different AWS services that we offer and how these services can help you with that multi-account strategy. Think of it like the different rooms in a highly secure building, very similar to the example that we talked about earlier. Even though you own the whole building, which basically in this context will be your AWS organization, you need specific keys which act as an authentication mechanism to enter each room, which basically resembles an account, and the security cameras provide the monitoring to keep track of what's happening. The main office — we call it a security account — keeps track of everything that's happening in all these rooms. The idea is nobody gets a master key. Instead, you get temporary access only to the rooms you need and when you need them. All connections between the rooms go through a secure corridor, something like a transit gateway.

Ashok: And there is a central reception desk, which is very similar to AWS single sign-on mechanism that we have, that verifies everyone's identity before you can even enter the building. What's neat here is that if something suspicious happens in one room, your security, excuse me, team knows about that immediately because everything is logged and monitored. Plus, the building policy, very similar to service control policies that we have, automatically restricts people in what they can do in each room when you manage it to AWS organization. The bottom line here is that managing multiple AWS accounts more securely without passing controls at each and every level, rather than consolidating it using these AWS mechanisms, gives you that control that you're looking for, keeping it much more manageable than overcomplicating it when you have pockets of controls in different locations.

Eddie: Perfect. Thank you for that. The next two questions, Wes, I think you're probably going to be most appropriate because I've not actually walked through a customer deployment, but they're both related to deployments. One question is, "Can you deploy on-prem?" And the other one is, "How long does it typically take a deployment?"

Weston: Yeah. Yeah. Great question. So in terms of kind of our deployment models, again, I'm going to step back and say Teleport is really meant to exist in your current environment to complement it as well as enhance it, its workflow. And so just in that same kind of sentiment, the way to deploy is in three different ways: through SaaS, on-prem, or hybrid. So yes. The answer is absolutely yes. I think I usually hear that a lot because there's a rigid compliance that you need to go ahead and stick by. And so because we understand that we absolutely do have — we call it self-hosted. So you can either do it on-prem, or if you have AWS account, you can self-host it there as well. And sorry, Eddie. Could you repeat the second question one more time?

Eddie: How long does it usually take?

Weston: Yeah. Yeah, yeah. And so this is always a funny question to answer because people always kind of want exact, and it's not an exact science, unfortunately, because everyone's different. Everyone has different channels of how they have to get approval for changes, right? But typically, what we see is anywhere from a month to three months. Sometimes it can be a little longer when it's a very, very big organization, but it's not overly exhaustive by any means.

Eddie: Okay. Great. Thank you. And I see we're just about out of time. I want to thank everyone for attending today. I hope you found this informative. There should have been a survey that popped up, and we hope that you take a few minutes to answer those questions. I think it's just three questions. And Ashok, I just wanted to thank you so much for your time, for being our guest today. It was really informative information that you shared with us. And Wes, thank you for the demo.

Ashok: Thanks for having me.

Eddie: So with that, the webinar is concluded for today, and thank you for attending.

Weston: Bye, everybody.

Ashok: Thank you. Bye.