How to access AWS Console using AWS IAM

This blog post explores the traditional authentication and authorization processes to AWS Management Console, and how Teleport can replace them to further secure and audit your Infrastructure Access for AWS.

You can access your AWS Management Console through a variety of methods. If a user has AWS Administrator or Root Access, they can see and edit all infrastructure in its entirety. AWS has multiple tools available to mitigate access, but are they enough? This blog will shed light on Teleport’s AWS Management Console Access features in comparison to those native tools, and how you can use Teleport to further secure your AWS Console.

Logging into AWS Management Console without Teleport

Traditionally, your account and console access will start with the AWS User Portal. This may seem obvious, but protecting your critical infrastructure with usernames and passwords is not a secure best practice to say the least. To better secure your account, you should add 2FA to the main account owner for an additional security gate. Next, you can proceed to leverage IAM Roles and Users to further layer and restrict your AWS Accounts' permissions once they pass through the User Portal. This provides the foundation for RBAC and ABAC models to manage and secure your AWS Management Console.

Now, let’s say you want to access your AWS Console through a programmatic interface like the Command Line. You would then download AWS locally and move on to your CLI Tool. I personally love to use warp as my Terminal.

AWS()                                                                         

NAME
       aws -

DESCRIPTION
       The  AWS  Command  Line  Interface is a unified tool to manage your AWS
       services.

SYNOPSIS
          aws [options] <command> <subcommand> [parameters]

       Use aws command help for information on a  specific  command.  Use  aws
       help  topics  to view a list of available help topics. The synopsis for
       each command shows its parameters and their usage. Optional  parameters
       are shown in square brackets.

OPTIONS
       --debug (boolean)

       Turn on debug logging.

aws help command after package is installed

After you install the AWS CLI Package onto your local machine, you’re then able to export Access Keys (provided from your AWS Account), and paste those credentials into the CLI to authenticate. A key thing to note here: your Access Keys with AWS are static, meaning they never change. According to the Verizon 2021 Data Breach Investigations Report, 61% of data breaches are caused by leveraged credentials.

AWS is aware that these introductory methods of authentication are risky, so they have implemented their own identity provider (IDP) to enable single sign-on (SSO). It is called (you guessed it) AWS SSO. Unfortunately, this SSO tool can only be applied to AWS configured resources and microservices. So, if you’re not a 100% AWS shop, you will probably have a different SSO you want to use to avoid multiple user groups and directories. AWS has enabled their customers to leverage those third-party identity providers through their SAML Integration. All of these options can be utilized to configure access to your AWS Management Console; it is at the discretion of your leadership to compare the risk-reward ratio of tighter security processes to higher monthly cost to AWS and vice versa.

Pros and cons of traditional AWS auth methods

• Pros:
  • Permissions management on the user or policy level
  • Multi-factor authentication (MFA) enabled for identity confirmation
  • SSO provides passwordless access
  • SAML integration enables directory and groups uniformity
• Cons:
  • Passwords can still be utilized with User Portal
  • SSO integrations are limited to just AWS or SAML
  • Roaming local AWS credential files (AWS_RSA.pem for CLI SSH)
  • Static access keys that can be found in CLI Index
  • Redoing environment variable configuration
  • Potential spike in monthly AWS subscription costs

The problems with ‘AllowUsersToPerformUserActions’ users

Now that you know how AWS secures your console, let's discuss an imperative caution, using the default role AllowUsersToPerformUserActions. Having AllowUsersToPerformUserActions access is like having a universal key that works for every front door in the neighborhood no matter the lock.

This is where IAM and RBAC implementation is so important. This is similar to running root on a server. Once a user is authenticated as root, system changes can be conducted without confirmation. This can include directory manipulation, unauthorized revisions of important configurations, and accidental deletion of files or services. If you’re in an SSH session as root, programs that get run also get run with root privileges, meaning that you have full access to impact other systems and ports with no verification or checkpoints. There isn’t a way to account for root actions if multiple users are able to assume the same superuser login aka root. You should always strive to use accounts with the least amount of privilege to prevent these nightmares. This is why reducing AWS Access using IAM is as important as not running as root on a server.

Using IAM AssumeRole

Assuming a role in AWS IAM means you are using your current credentials to temporarily use a role with separate permissions. This enables your AWS Account to have a time to live subject to expiration when authorized in AWS Management Console. This is an improved security method, as it can enable the Least Privilege Model.

If you or another user requires elevated permissions in AWS Management Console, you’ll have to switch to an elevated role through an Assume Role policy granted. Then once assumed, your increased powers will have a countdown and expire after a certain point. You can even set the session durations for the users that have the assume role policy assigned to them. Furthermore, the assume role policy also creates an event in Cloud Trail, enabling auditing capabilities for your activity in your AWS Management Console.

JSON example of an Assume Role Policy to a root account

Teleport can bring this all together

Teleport Application Access enables you to establish an encrypted reverse tunnel to access your AWS Management Console with full auditing, compliance, and ability to use any SSO Provider (OIDC and SAML). With a Teleport Agent (Node with Teleport Daemon installed), you are able to configure Teleport Application Access service to connect to your Teleport Cluster and then to your AWS Management Console. Through the use of assume role policies as discussed above, Teleport can assume assigned IAM roles such as ReadOnly or PowerAccess:

Snippet of Teleport Cluster with AWS Console Access

This enables fine-grained specified access based on permitted user groups in your IDP/SSO, IAM Assume Roles, and Teleport’s RBAC mapping to those IAM ARNs to bring it all together. Teleport’s SSO integration ability can enable you to use your OIDC Identity Provider to authenticate into your AWS Console, as AWS SSO only supports SAML. Teleport’s Application Access Protocol provides a public URI that is gated via Teleport Login, so you can remove public traditional access to your console altogether.

Additionally, this setup removes the need to paste exported credentials into your CLI tool. With Teleport installed locally, you can access AWS programmatically using tsh app login –aws once authorized by your SSO. Lastly, all actions by the Teleport User in AWS are recorded in CloudTrail and the Access/App Session itself is recorded in Teleport's Audit Log in JSON format (if you use a SIEM, you can feed it these recorded events):

Example of Teleport’s Audit Log rotating certificates and storing AWS session data

AWS IAM Blog Recap

With organized IAM roles, implementation of assume role policies, SSO, and utilization of ephemeral credentials through Teleport, you can enhance your AWS Management Console security with no sacrifice to speed and efficiency. PSA: Teleport is open source. You can try Teleport Application Access as part of our community edition.

Want to try? See configuration guide

Learn more by visiting our Teleport Application Access AWS Management Console Guide.

Example Arch Diagram of Teleport App Access with CloudWatch:

teleport:
  # Data directory for the Application Proxy service. If running on the same
  # node as Auth/Proxy service, make sure to use different data directories.
  data_dir: /var/lib/teleport-app
  # Instructs the service to load the join token from the specified file
  # during initial registration with the cluster.
  auth_token: 2a20002b-EXAMPLE-fb0780
  # Proxy address to connect to. Note that it has to be the proxy address
  # because the app service always connects to the cluster over a reverse
  # tunnel.
  auth_servers:
  - acme.teleportdemo.com:443
app_service:
  enabled: "yes"
  apps:
  - name: "awsconsole"
  # The public AWS Console is used after authenticating the user from Teleport
    uri: "https://console.aws.amazon.com/ec2/v2/home"
auth_service:
  enabled: "no"
ssh_service:
  enabled: "no"
proxy_service:
  enabled: "no"

Example Teleport Agent Config File:

Example AWS Console Role in Teleport RBAC permitted to assume ARN: