Managing Multi-Account AWS Console and CLI Access with Teleport 

Are you using multiple AWS accounts to separate your environments like many of the engineering teams we work with? If you are, you may be looking for a better way to access those accounts.

Join us for a session, in which Nivathan Somasundharam, Implementation Engineer at Teleport, and Ashok Mahajan, Senior Partner SA at AWS, discuss some common challenges that arise when using multiple AWS accounts to separate cloud environments and how to use Teleport to solve these issues. Some of the most common issues people face include:

Onboarding, off-boarding, and restricting engineer access to AWS accounts

Restricting access to sensitive AWS accounts, solved with Teleport Access Requests

Running Terraform, boto3 scripts, and CLI commands without AWS credentials

Transcript - Managing Multi-Account AWS Console and CLI Access with Teleport

Ashok: Hi, Nivathan. Let's share the slide deck.

Nivathan: Greetings, everyone. Thank you for joining today's webinar. Let's wait for a couple of minutes for others to join. Let's see where everyone is from. Feel free to drop your city name on the chat. There is Ali from Austin, Lexi from Chicago, Robert from Calgary. Hi, Robert.

Nivathan: Chintan from San Jose. Hi, Chintan. Let's wait for one more minute and get started.

Nivathan: Maybe 30 more seconds, we'll get started. Hi, everyone, again.

Nivathan: Okay. Let's get started. Once again, thank you for joining today's webinar: Managing Multiple AWS Account Console and CLI Access with Teleport. I'm Nivathan Somasundharam. I'm an implementation engineer at Teleport. Before Teleport, I was a DevSecOps practitioner at VMware and Cradlepoint building, managing, and securing cloud environments. I've been here at Teleport for a year and a half. I live in San Jose, California. I'm partnering with Ashok from AWS today on this webinar. I'll let Ashok to introduce himself.

Ashok: Hi, everyone. My name is Ashok Mahajan, and I'm a senior partner solution architect with Amazon Web Services. I'm part of the Global Startup team focusing on ISVs, especially our partners in security segment. I've been part of the information security community throughout my career. It's a little over 17 years now. I've implemented a lot of solutions around data security, identity, and access management across multiple domains.

Nivathan: Very nice. Here is the agenda for today's webinar. Let's start with the challenges with delegating access to multiple AWS accounts, and then Ashok will go over AWS shared responsibility model in respect to AWS IAM. Then I will introduce Teleport to you all and show how Teleport will solve some of the challenges that we are discussing today. Finally, I can show an interesting demo on how AWS access can be done with Teleport. And followed by that, we can go over some Q&A. Let's talk about the challenges. We all know it's a great strategy to isolate AWS environment and segregate the AWS account for building, governance and resource isolation purpose.

Nivathan: But there are some complexities involved when it comes to delegating and managing access to multiple AWS accounts. Let's get into them. The first one is it's hard to centralize the authorization of different AWS accounts for all your users at different levels. As an engineer, you have to switch between accounts to access different infrastructure components, which requires an engineer to assume roles and change the configuration on the terminal, especially for the CLI access. We all have to maintain various compliance requirements based on the industry standards and in the industry where we operate in. Auditing is a core part of compliance. When we have multiple AWS accounts, there are some challenges with auditing all the accounts at a centralized place or in a centralized system. And the last one is we strive hard to achieve least privileges.

Nivathan: So we cannot let developers to have default access to your critical or your production accounts or your critical infrastructure all the time. When we restrict the engineers to a certain production access or a critical infrastructure, they are handicapped and their productivity goes down. To address this, we can use something like just-in-time access, also known as temporary access to the critical resource, and which is quite challenging to provide access like just-in-time for your AWS accounts. That is the last challenge. Now I'll pass on to Ashok to discuss the AWS shared responsibility model with respect to AWS account. Here for you, Ashok.

Fine-grained access on AWS reduces cybersecurity risk

Ashok: Thanks, Nivathan. Next slide. Yeah. So I think we all can agree that the core of IAM basically revolves around three critical elements, right: the who, access, and what. Right? Who can be made of your users, employees, and your customers. What basically represents the resources you're trying to protect. And what connects the two is basically the access management. With AWS Identity and Access Management, you can specify who can access services and resources in AWS, centrally manage the fine-grained permissions, and analyze access to refine permissions across AWS. So in AWS context, who can be an identity and access management user, a group, or an IAM role. And IAM user, it's not just restricted to a human, but it can also be associated to an application or a service.

Ashok: For example, when you are setting up access for Amazon Elastic Compute, commonly known as EC2, it's trying to access an object in S3 that is basically an IAM user in that context. What can be an AWS account, an AWS resource, such as Amazon EC2, or even a fine-grained access object when you associate it with Amazon Simple Storage or S3, or even a DynamoDB table item. The access is basically managed by policies and permissions. Policies contains the permission that define and ensure whether the request should be allowed or denied. AWS IAM is offered at no additional charge and integrates with many AWS services so that these services can leverage the same IAM-based permission model to manage and control access. Next slide. Since we are talking about AWS account, I just want to do a quick recap of what an AWS account is.

Ashok: It is basically a container for all your AWS resources that you create and manage. It provides you that administrative capability for access and billing. AWS account is basically your security boundary for all your AWS resources. The resources that you create in an account are available to users who have credentials for that account. Among the key resources that you create in your AWS account are basically your identities, such as users and roles. Identities basically have credentials that you use to sign in or basically authenticate to AWS, and they have the permissions and policies that are associated, which defines their authorization. Now let's take a look at the AWS shared service model. Nivathan, next slide. So cloud security at AWS is our highest priority, and leveraging this shared responsibility model can help you relieve the operational burden as AWS operates, manages, controls the component of host operating system and virtualization layer down to the physical security of facilities in which these services operate.

Ashok: You as a customer assume the responsibility and management of guest operating system, including updates, patching, any associated software, as well as configuration of AWS-provided security groups. As shown in this chart, this differentiation is commonly referred to as security of the cloud versus security in the cloud. So in this equation, AWS is responsible for security of the cloud, that includes the physical infrastructure, facilities, the compute, the building block that runs the AWS services. You as a customer are responsible for security in the cloud. That means you secure the workload and application that you deploy in the cloud and have the flexibility to put more emphasis on the security of sensitive data as per your business requirement.

Ashok: You basically own and are responsible for managing your data, classifying your assets, and most importantly, using the IAM tools to make sure there are appropriate permissions defined based on your business needs. Next slide. Some customers have sensitive workloads and prefer to have more control what and where the data and your applications are running. The shared responsibility model basically gives you that flexibility, and it changes based on the services being used. For managed services, AWS takes on more responsibility to elevate some of the heavy lifting that you may need with the trade-off of less general control. As an example, when we look at Amazon Elastic Compute, or commonly known as EC2, AWS is responsible for protecting the infrastructure that runs AWS services in the cloud. Your responsibility lies with controlling network access to your instance, managing credentials, managing guest operating system, and even managing the IAM roles that give access to those instances.

Ashok: Another example is Amazon Simple Storage or S3, where you don't have to manage the operating system, but you will be responsible for managing your data, classifying the objects, setting up the level of encryption, and on top of it, managing access through IAM roles. Note the IAM requirement in these services. Right? IAM was common in both these scenarios. So AWS basically provides you mechanism to configure the identity and access management side of the requirements so that you can adapt based on your needs, your compliance, and security objectives. As an example, when it comes to different users in AWS, there is an account owner, which we also know as root user, there is an identity center user, there is a federated user, and there is IAM user. And you have options to provide long-term or temporary credentials and basically adapt and configure these based on your specific needs and requirements.

Ashok: Now in the next slide, let's take a look at what AWS provides in terms of the core identity management, access control, and governance features. And I think we all can agree that these basically form the core security pillars for any organization of any size and any type. If you look at these slides, the AWS provide these identity controls for Zero Trust, which you can use to authenticate identities, to evaluate identity context, and force fine-grained identity-based authorization before allowing any identity to access applications, your data, and your systems. In the next few slides, we will learn more about some of these services and how these services help you manage access to your critical applications and data. Next slide.


Ashok: Let's begin by talking about AWS IAM Identity Center that helps you securely create, excuse me, or connect your workforce identities and manage their access centrally across AWS accounts and application. In fact, IAM Identity Center is the recommended approach for workforce authentication and authorization on AWS for organization of any size and type. You can create or manage identities in AWS, or you can even connect to your existing identity sources, including Microsoft Active Directory, Okta, Ping, and others. With multi-account permissions, you can plan for and centrally implement permissions across multiple AWS accounts at any time without needing to configure each of these accounts manually. Next slide. Now, as Nivathan was pointing out, in today's ecosystem, we have many applications, multiple teams, and each of these teams have different operational, regulatory, and budgetary requirements. And many companies, because of these reasons, follow a multi-account model.


Ashok: These models simplify billing, where resources used within AWS account can be allocated to a business unit responsible for that account and also provide isolation and tight security boundaries enforced by built-in isolation between accounts and consolidation of workflows with similar risk profiles. AWS Organization is basically an account managed service that enables you to consolidate multiple accounts into an organization that you create and centrally manage. AWS Organization includes account management and consolidated billing features that enable you to meet your budgetary, security, and compliance requirements, and also allows you to manage and control policies and define guardrails for your organization. It basically provides you native tool to build your environment so that you can scale quickly by creating accounts and allocating resources, customize your environment based on your specific needs around governance, and also helps you organize cost and identify cost-saving measures.


Ashok: And if you would like to jumpstart your AWS environment using a simple UI and built-in best practices, we even recommend using AWS Control Tower that we'll be talking about in the next slide. I think we all can agree that managing a large-scale enterprise with a large number of applications, distributed team, cloud setup, and governance can be complex and time-consuming. This can sometimes even slow down innovation that you're looking for to achieve your customer requirements. That's where AWS Control Tower comes in. AWS Control Tower offers you a straightforward way to set up and govern multi-account environment following the prescriptive best practices. AWS Control Tower basically orchestrates the capabilities of several other AWS services, including AWS Organization, AWS Service Catalog, and AWS IAM Identity Center to basically build a landing zone in less than an hour.

Ashok: Resources are set up and managed on your behalf. AWS Control Tower basically enables end user on your distributed teams to provision new accounts quickly by means of configurable account templates in the form of account factory. Meanwhile, you can use your central admin capabilities and can monitor all your accounts to make sure they are aligned with your established organization-wide best practices and controls. In short, AWS Control Tower offers the easiest way to set up and govern a secure, compliant, multi-account AWS environment based on the best practices established by working with thousands of enterprises. Next slide. AWS IAM basically provides you a number of security features to consider and develop and implement based on your specific needs.


Ashok: Along with these tools and controls, there are also some best practices, which are basically guidelines that you can follow. These do not represent basically a complete security solution, but these are best practices that we have learned with our years of experience. As an example, you can protect your root credentials, like you protect your credit card or any sensitive secret, and use them only for the tasks that are needed. Use IAM roles to manage access, use temporary credentials as and when possible, use multifactor authentication for extra security. You can even use AWS Organizations service control policy, commonly known as SCP, to limit the permissions of root users and even establish permission guardrails for your account, grant only permissions that are required to achieve your task, and even use IAM Access Analyzer to validate your IAM policies to ensure you follow the principle of least privilege.


Ashok: When it comes to managing access, along with these native AWS services, we also have a strong network of AWS partners with deep expertise and specialized solution to meet your specific needs. By leveraging AWS services along with these partner solutions like Teleport to manage your connectivity, authentication, authorization, and even your audit needs, you can scale your AWS infrastructure while reducing the potential of unintentionally opening up AWS resources to unauthorized access. Now, I think let's hear from Nivathan how Teleport solves the complexity involved in managing access to multiple accounts and makes life easier. Over to you, Nivathan.


Nivathan: Thanks, Ashok, for going over the Shared Responsibility Model and explaining about some of the great services from AWS and also the best practices related to IAM from AWS. Now let's see why we need Teleport and what are the problems that Teleport solved. Let's go over some introductions before getting into the details. Here is how engineers access infrastructure today. We all know that secure infrastructure access is hard. As an engineer, we want to access various pieces of virtual infrastructure, like servers, Kubernetes clusters, Windows machines, databases, CI/CD systems, AWS consoles, and other applications. And the list just goes on. How do we access all this infrastructure today?


Nivathan: Either through a bastion, like a VPN kind of solution, or we are still using secrets like passwords, SSH keys, and so on. So everywhere, there is a dependency for either a secret or VPN kind of perimeter-based security to secure the infrastructure. But there are problems involved in this VPNs-based security and the secret-based security. If a single piece of infrastructure here is compromised, the bad actor can make little movements inside your infrastructure and they can dump your sensitive information and make the blast radius huge. To address this issue, let's see how Teleport solves them. You all can see how better it is now when you can access your infrastructure through Teleport.

Nivathan: Teleport unifies access to all your infrastructure components. I'm going to introduce you to one of those rare times when a security solution makes it easy and faster for your engineers to get their job done while also increasing the security posture at the same time. Many organizations we speak with have implemented several security solutions, but developers didn't adopt. Do you know why? Because they are a pain to use and developers are smart enough to get around them. If you want someone to adopt a security solution, it has to be dead simple. And that's why Teleport has done with — that's what Teleport has done with Identity-Native Infrastructure Access. Let's get right into it. The solution to address all the challenges is Identity-Native Infrastructure Access. Identity-native consists of two things.


Nivathan: The first one is secretless and the second one is Zero Trust. Let's talk about secretless first. There are passwords which are always getting stolen or phished. Passwords and secrets are always meant to be shared between teammates, which is a bad practice. And passwords and secrets don't have an identity attached to them. So let's try to avoid the legacy PAM systems or keywords to manage passwords. So clearly the better approach is secretless. The second component of Identity Native is Zero Trust that aligns with Google's BeyondCorp initiative for securing their own infrastructure. Zero Trust completely throws out an idea of access between human and machine — is completely based on identity. Zero Trust doesn't trust anyone based on the network.

Nivathan: Always, user identity is checked and the access is granted based on that. Now let's see how Teleport does Identity-Native Infrastructure Access. Here is a high-level architecture diagram of Teleport. The Identity-Native Proxy sits between a user and the infrastructure resources, like servers, Kubernetes clusters, databases, applications, and cloud consoles like AWS Cloud Console. And Teleport itself is the certificate authority. Whenever an engineer logs into Teleport by proving his or her identity, they are provided with a short-lived X.509 certificate. So whenever a user logs in, they are provided with this short-lived certificate so that they can be logged in for that short time based on the TTL that we set.


Teleport integrations with AWS infrastructure resources

Nivathan: Teleport also has the fine-grained RBAC capabilities that controls who can access what inside the Teleport. So based on the identity, the RBAC takes care of deciding who can access what. Teleport can be integrated with SSO providers like Okta, Azure Entra, and our GitHub, and various other SSO providers. You can also use WebAuthn-based biometric hardware authentications like YubiKeys, Touch ID on your Mac, and Hello on your Windows to authenticate to Teleport. Everything is audited, and those audit logs can be also exported to your preferred scene. Users also can request for access through Teleport. For example, whenever an engineer requires elevated privileges, they can request for that, and admins can approve that request.


Nivathan: Teleport integrates with a wide range of AWS infrastructure resources, and we are also platform agnostic. Teleport can integrate well with all your day-to-day workflow systems as well. I wanted to remind everyone again, Teleport is an open source. If you compare us with the legacy solutions, the key difference is Teleport is user-friendly for developers, and developers will love Teleport because we have created a solution from ground up with developers, DevOps engineers, and SRAs in mind. Our founding team came from this world and experienced these problems firsthand. That is what truly makes us different. Once again, you can check out our open source on the GitHub. Now let's go over some advantages of using Teleport, and specific to AWS Console and CLI access.


Advantages of using Teleport for AWS access

Nivathan: The first one is that Teleport integrates well with SSO providers. So you can still hold your identity source to be your IDP providers, like Okta, Azure Entra, and GitHub, etc. And Teleport will help to manage the lifecycle of employee, especially workflows like onboarding and offboarding of employees can be automated. We can add and remove users by just making IDP changes. And then the second one is just-in-time access for AWS account. Consider there is a highly critical piece of infrastructure that sits in one of your AWS accounts. As Ashok mentioned, it is better to segregate your accounts for security and governance and billing reasons.


Nivathan: So consider there is a very sensitive account. We don't want to default access to those accounts to engineers. Engineers can request for access to that particular account and gain access for a short time using Teleport. No infrastructure-as-a-code changes are required here. There is no waiting for any PRs to be approved. It can be also integrated with your daily workflows, like Jira, Slack, Mattermost, Teams, PagerDuty, Discord, etc. In fact, Teleport can do automated reviews based on PagerDuty on-call schedule and grant access based on the schedule. Compliance and auditing for your AWS account activity using Teleport is one of the main advantages that I want to mention.


Nivathan: And Teleport's detailed auditing logs help to maintain compliance and also keep the activity of users in different AWS account at a single and centralized place. You can see all the account activity at a centralized place. You can also export these audit logs from Teleport to your preferred SIEM. Okay. We have gone through the advantages of using Teleport. We can see them in action on how to access AWS account from both Teleport UI and CLI. I have another tab here. So I can log in to Teleport. I'm going to use my SSO. So I'm going to use GitHub now to log in to the Teleport cluster, the Teleport environment. Okay. I'm logged in. This is my GitHub. I use my GitHub user to log in.

Nivathan: And you can see these are the resources that I have access to. I have AWS consoles. I have Kubernetes. I have some databases, RDS databases, and Windows machines, everything on one single place. And the second tab here is more like a management. As an admin, I can manage things over here. Let me quickly log in to one of my AWS accounts here. You can see there is a dev account, staging, and then prod. Let me just do a login to dev account. I don't need to enter any passwords here. Everything is secretless. I just logged into the AWS account straight into the EC2 console, and I can go and see the machine that is running on it. Very similarly, I can do on CLI as well.

Nivathan: Let me check if I am logged in. Okay. I'm not logged in now, so I'll go and log in now. So I have successfully logged in. I have used my SSO provider to log in again here from my CLI. You can see I have acquired the certificate, the short-lived credential that I mentioned, and it's valid for 1 hour. This can be set for the maximum of 12 hours based on your employee or the developer working duration. You can set it 8 hours, which is pretty common that we see. And now, I have logged in. I'll do `tsh status` again.

Nivathan: Yes. I'm active now, and I'll do `tsh app ls`. So this is the only single binary that a developer should use. They just need to install tsh on their local machine. And that should be good enough for all access, not just applications like servers, Kubernetes, everything. Here, I have the three AWS Console and some Grafana and other applications as well. So let me log in to this `prod` AWS account and try to run some AWS commands. Okay. I'm logged in now. I can do `tsh aws s3 ls`. I’m able to see these buckets.

Nivathan: And I can do all the AWS CLI operations. And also, I can start a proxy that will help me to run any Terraform or any other automation scripts with AWS, especially running Boto3 scripts. And so it works very natively with CLI and UI as well. It's just like you don't have to use any secrets and everything is unified. All your access will be unified. Now I have one more user, Alice. Let's consider Alice to be a junior developer who doesn't have any access initially when they log in. And there is an access request feature from Teleport which Alice can use to request to any of these resources or to the role, which is AWS products as role. So let me request for this AWS products as role.


Nivathan: And the request is pending now, and the request is created by Alice. And me as an admin, on the other hand, I can go and see if there are any requests that came in. And you can also notify this request to a Slack or to any Discord or any other day-to-day workflows. And also, you can automate these approvals through PagerDuty schedules. If Alice was on PagerDuty schedule, we can automate that approval process through that. So here is the request from Alice. I'm going to approve. Everything is customizable, like how long we can provide them access.


Nivathan: And everything can be customized based on who can review it and who can request this. Everything is customizable through Teleport's extensive RBAC capabilities. And, yes, I have approved it. Let me refresh from the Alice. So you can see the role has been approved, and Alice can assume this role. So once Alice assumes this role, you can see “assumed and expires in 23 minutes” and check the resources. Alice can see the two resources. And here, I can go to the same prod account and see the S3 bucket that I showed on CLI.


Nivathan: Yep. You can give this access as granular as possible. I mean — it can be from any role, you can map it, and a user can choose any role based on the RBAC setup that we have configured before. So this is the demo on just-in-time access. And along with that, I wanted to show about the auditing. So here is the audit logs. So you can see who has accessed, and there was an app session started by Alice to AWS Console prod. And every detail on that application access is in JSON. You can parse them, and you can send it to your preferred SIEM.
