AWS Management Console

This guide explains what capabilities StrongDM can provide for managing access to AWS Management Console via a service account. It also provides setup and configuration instructions to add AWS Management Console as a resource in StrongDM and begin using StrongDM to control access for users who wish to access your console via a CLI application such as aws. StrongDM users are authenticated with AWS and granted the level of access that you configure on the AWS side.

In addition to access control and auditing, AWS Management Console access through StrongDM can be a part of a variety of use cases and access control methodologies:

• Least Privilege: For AWS Management Console clouds, least privilege can be accomplished by setting up multiple instances of the console as StrongDM resources. Each resource would connect to AWS using a different service account with different permissions granted to it.
• Just-in-Time Access: StrongDM users are able to use any access workflows you set up to request access to AWS, allowing you the choice between granting Just-in-Time (JIT) access with requests, or providing standing access to particular users or roles within your StrongDM organization. For more details, see the Access Workflows section.
  To avoid confusion during access requests, if there are multiple AWS Management Console cloud resources in StrongDM, it may be useful to name them in such a way that indicates the level of access, so that users know the name of the resource to request.
• Context-Based Policy: StrongDM policies that restrict or enable users’ ability to connect to AWS resources based on their context can be used to limit availability of your AWS Management Console to users in particular geographic locations or with good device trust scores. Policies can also be used to provide an MFA challenge prior to connection, and help solve for many more use cases. For more details, see the Policies section.

Limitations #

• Due to the limitations of this resource type, StrongDM does not log user interactions after authentication occurs. StrongDM logs activities such as setup or modification of the resource within StrongDM, or authentication of a user to the resource, but StrongDM does not log the queries performed by the user on the resource itself. We recommend the use of CloudTrail for logging further interactions with the resource once a user is authenticated.
• Similarly, some organization-level behaviors are also different for this resource type:
  • Inactivity timeouts set for the organization are not enforced.
  • Current connections to resources are not severed instantly when access is revoked.
  • Note that you can set an expiration field to enforce session timeouts. See Session Expiry Seconds in the AWS Management Console properties.

AWS Management Console Cloud Properties #

• AWS Management Console supports the aws command-line tool.

Authentication #

To manage access to your AWS Management Console via StrongDM, we support the following authentication modes:

• A static AWS access key, which comprises an Access Key ID and a Secret Access Key
• Environment-loaded credentials, which can be one of the following:
  • AWS access keys in standard AWS environment variables on the gateway
  • AWS access keys configured as a standard AWS profile on the gateway
  • An EC2 instance profile or ECS profile linked to the host or container running the gateway
  • An IAM role assumption, which can be used with Identity Aliases

If you use Identity Aliases, the identity selected for any given user does not relate to AWS IAM identities or authorization for that user account. The StrongDM user still only has rights belonging to the AWS Role defined in the resource, or via credentials on the gateway. The authentication setting for the resource only changes what name is used to log requests in AWS CloudTrail and the display name of the logged-in user in the AWS Management Console.

Prerequisites #

• In StrongDM, you must have the Admin permission level.
• You must have administrator access to your AWS environment and be familiar with aws.
• Have TLS certificates set up.
• Be aware of security considerations.
• Consider logging.

Generate TLS certificates #

You must have TLS certificates set up with StrongDM before adding an AWS Management Console resource. The certificates are usually generated automatically when an StrongDM organization is created, but in some cases, it might be necessary to explicitly create them. To check, go to the Resources > Websites page in the Admin UI. If the option to generate TLS certificates is displayed, click on the button to generate them.

Security considerations #

Before adding your AWS Management Console as a cloud resource, note the following.

• For your AWS configurations, allow the least amount of privilege possible.
• Keep your authentication type the same when possible. If your organization does not use static keys, do not configure StrongDM to use them.
• Logging:
  • StrongDM doesn’t log anything beyond authentication against the resource. If you need more complete log coverage than CloudTrail provides on the AWS side, you can use Identity Aliases and your own CloudTrail logs in AWS. With these, you can create an accurate picture of access.
  • Enable and log AWS Access Analyzer and CloudTrail Management events for the account to configure. When in use, the logging shifts from StrongDM logs to AWS logs. Having unified schemas and transactions ready for this is helpful for your security team.
• If AWS single sign-on (SSO) is being used organization wide, the feature should be configured from the account that provides SSO to your organization.
• Be vigilant of over-applied sts:assume in trust relations. For example, if using the trusted entity type of AWS account during role creation, the only condition to assume this role is that you must be assuming the role from the account given. The best practice is to observe least privilege when working with IAM roles.
• Use the AWS managed policy called ReadOnlyAccess when there is possible doubt in the configuration.
• If you are unsure about the configuration, diagram what the plan is and review it with a coworker.

Additional logging considerations #

Before you proceed with configuration, note the following logging information.

• If you use Identity Aliases within StrongDM, your CloudTrail logs are augmented. The logs show the Identity Alias instead of the user email address.
• If Identity Aliases is not enabled, StrongDM includes the user’s email in the “assume role” request, which displays in CloudTrail.

Configuration #

Admin UI setup #

If you prefer to set up your AWS resource in StrongDM using the CLI, skip this step and read CLI setup.

If you want to set up AWS Management Console as a cloud resource in the StrongDM Admin UI, go to Resources > Clouds in the Admin UI and click the Add cloud button. Note that there are two types and they have different properties.

For AWS Management Console, set the following properties:

For AWS Management Console (Static key pair), set the following properties:

Click Create to save the configuration settings.

Configuration notes #

How you configure your resource properties depends on how you connect your AWS Management Console.

• For a static key connection, select the static key pair cloud option and fill in the required fields.
• To use an EC2 instance profile or ECS profile, select the AWS Management Console cloud type, and leave the Enable Environment Variables box unchecked.
• For IAM roles with or without Identity Aliases as a connection, select the AWS Management Console cloud type, and leave the Enable Environment Variables box unchecked. Use the Enable Environment Variables option when you have an AWS user profile configured on the gateway box for the local account running the gateway process (that is, an EC2 IAM role).
• To use an AWS profile configured on the gateway, select the AWS Management Console cloud type, and leave the Enable Environment Variables box unchecked.
• To use environment variables, select the AWS Management Console cloud type and check the Enable Environment Variables box.

Credentials-reading order #

During authentication with your AWS resource, the system looks for credentials in the following places in this order:

1. Environment variables (if the Enable Environment Variables box is checked)
2. EC2 role or ECS profile
3. Shared credentials file

As soon as the relay or gateway finds credentials, it stops searching and uses them. Due to this behavior, we recommend that all similar AWS resources with these authentication options use the same method when added to StrongDM.

For example, if you are using environment variables for AWS Management Console and using EC2 role authentication for an EKS cluster, when users attempt to connect to the EKS cluster through the gateway or relay, the environment variables are found and used in an attempt to authenticate with the EKS cluster, which then fails. We recommend using the same type for all such resources to avoid this problem at the gateway or relay level. Alternatively, you can segment your network by creating subnets with their own relays and sets of resources, so that the relays can be configured to work correctly with just those resources.

CLI setup #

If you prefer to set up your resource using the CLI instead of the Admin UI, open your terminal. While logged in to StrongDM, use the following command:

sdm admin clouds add awsConsole

You can view all help text and options by appending --help or -h to the same command:

NAME:
   sdm admin clouds add - add one or more clouds

USAGE:
   sdm admin clouds add command [command options] [arguments...]

COMMANDS:
   aws                      create AWS cloud
   awsConsole               create AWS Management Console cloud
   awsConsoleStaticKeyPair  create AWS Management Console (Static key pair) cloud
   awsinstanceprofile       create AWS (Instance Profile) cloud
   azure                    create Azure (Password) cloud
   azurecert                create Azure (Certificate) cloud
   gcp                      create GCP cloud
   snowsight                create Snowsight (Snowflake Web Console) cloud

OPTIONS:
   --file value, -f value  load from a JSON file
   --stdin, -i             load from stdin
   --timeout value         set time limit for command
   --help, -h              show help

Logs #

For logs of access to an AWS Management Console cloud resource, in the Cloud logs section of the Admin UI (Logs > Cloud), you can find all of the activities of users connected through StrongDM. Note that StrongDM makes an attempt to drop the Authorization header of logs for display in the Admin UI. Note that any secrets displayed in the cloud logs are placeholder values. No actual keys or secrets are ever exposed in plaintext in the Admin UI.

CLI Usage #

When the resource is created and configured, you are ready for users to connect to the resource. In order for your organization’s users to access the AWS Management Console cloud resource via StrongDM, users need to install the following:

• StrongDM Desktop application
• Latest version of the StrongDM CLI; if already installed, you can run sdm update in the CLI to update it, or open the desktop app and click the Upgrade button
• AWS CLI; both v1 and v2 are supported but we encourage the use of v2

After installation, users must set up or update the AWS CLI configuration file to include a region, as explained in the AWS documentation. Once that is done, exit and restart the StrongDM desktop app, and then select the AWS Management Console cloud resource to connect to.

Click to connect to the resource in the desktop app, or run sdm connect <RESOURCE> in the CLI. Once connected, users can use aws through StrongDM at their terminal, with the base syntax of sdm aws instead of the usual aws.

You can use sdm aws --help to view example usage and command options:

NAME:
   sdm aws - aws commands

USAGE:
   sdm aws command [command options] [arguments...]

COMMANDS:
   cli        Execute an AWS CLI Command.
   env        Print environment variables required to access an AWS resource.
   run        Execute an external command with environment variables configured for AWS.
   terraform  Execute terraform commands with a SDM AWS proxy.

OPTIONS:
   --name value     The name of the AWS resource to access. By default if there is only one connected AWS resource, that resource is used. [$SDM_AWS_NAME]
   --help, -h  show help

aws cli #

The aws cli command is followed by an AWS CLI command that you wish to run against your connected AWS Management Console resource. For more information about gcloud CLI commands, see the AWS CLI documentation.

aws env #

The aws env command outputs the environment variables that are required in order to access an AWS resource. This output is a similar format of the output of the standard env command, but only contains the relevant environment variables for connecting to AWS.

aws run #

The aws run command is followed by a command that you wish to run against the connected resource, which is sent along with the necessary environment variables. An example of a use for aws run would be if you have a pre-existing script for managing AWS resources that uses aws commands. Instead of altering the script to work with StrongDM, you could use aws run shellscript.sh and run the script.

–name #

If your organization has multiple AWS Management Console cloud resources, and you are connected to more than one at once, you may specify a --name value in commands in order to specify which you intend to execute the command on. For example, sdm aws --name <RESOURCE_NAME> cli. The flag must come before the cli portion of the command in order to preserve the ability to use the command as normal with a single AWS Management Console cloud resource connected.

Error Cases #

Should you attempt to use a cloud resource when you are not connected to it, StrongDM’s CLI commands warn you. You can get around this warning in some contexts (for example, by setting environment variables in your terminal). In these cases, you may encounter SSL errors, and nothing happens when you run commands.