Configure AWS Secrets Manager Integration

Secret store integrations allow you to use your existing third-party secret stores with StrongDM. Your credentials are stored in a tool that is controlled by you, and those credentials are never transmitted to StrongDM in any form. If you would like to learn more about how this integration works and why you might wish to use it, please read the Secret Stores Reference.

This guide will walk you through how to integrate AWS Secrets Manager with StrongDM and how to use it to connect to resources.

Set up AWS Secrets Manager #

To get started with AWS Secrets Manager, store credentials to some of your resources in it and note the correct paths to those credentials. Then, set up your Relay server to be able to authorize to the Secrets Manager with an access key.

Set up your credentials #

Set up your credentials in AWS Secrets Manager. This should be as simple as heading to Secrets Manager in the AWS Management Console and following the prompts to create your first secret.

Authenticate with AWS #

You can authenticate your gateway server with AWS in several ways.

Option 1: Access keys via environment variables #

1. Get an access key for AWS and set the necessary environment variables on your Relay server (AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY).

2. Edit the file /etc/sysconfig/sdm-proxy (unless you have moved or renamed your sdm-proxy file) and add the following lines, substituting your ID and key:

   AWS_ACCESS_KEY_ID=aswf234rt4rsag4t3g
   AWS_SECRET_ACCESS_KEY=23452321h2893hf2ioufh2938229fh2oufgh23890fh29fh23bif2f0928hf02f3n2bf290fn9230f
   

3. Restart the sdm-proxy service (with something like sudo systemctl restart sdm-proxy, depending on your distribution).

Option 2: IAM via EC2 role #

1. In your AWS Management Console, navigate to IAM, click on Role, and click on Create Role.
2. Select EC2 for Service.
3. In the policy, select SecretsManagerReadWrite, and click Next.
4. Add the role name and description, and then go to EC2 and click on Instances.
5. Select the instance that houses the gateway, and click on Actions > Security > Modify IAM Role.
6. Choose the name of the IAM role created earlier.

Option 3: ECS authentication #

In the task definition for the ECS cluster, the Task Role must have a policy allowing access to Secrets Manager attached to it, as in the following example:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "secretsmanager:GetSecretValue"
            ],
            "Resource": [
                "arn:aws:secretsmanager:us-east-1:12345678910:secret:*"
            ]
        }
    ]
}

If Resource Permissions is configured for Secrets Manager, the policy statement also needs to allow the Task Role to access that particular Secrets Manager.

Credential reading order #

During authentication with Secrets Manager, the system looks for credentials in the following places in this order:

1. Environment variables
2. EC2 role
3. ECS authentication or other remote authentication methods (set via AWS_CONTAINER_CREDENTIALS_FULL_URI or AWS_CONTAINER_CREDENTIALS_RELATIVE_URI)
4. 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.

This behavior was changed in CLI version 39.51.0. If you experience unexpected errors when upgrading to this version or above, you can set the environment variable SDM_AWS_LEGACY_PRIORITY to a truthy value such as 1 or true, to temporarily revert to the old behavior. In a future release, this option will go away.

Configure the Secret Store with the Admin UI #

Once you have AWS Secrets Manager set up, credentials stored, and your Relay server able to access said credentials, it’s time to integrate the secret store with StrongDM.

1. In the Admin UI, go to Settings > Credentials Management and to the Secret Stores tab.

2. Click the add secret store button.

3. On the Add Secret Store form, set the following:

   

   1. Display Name: Enter a name. This name will show up in the Admin UI.
   2. Secret Store Type: Select AWS Secrets Manager.
   3. Region: Fill the AWS region (e.g., us-west-2) for your AWS Secrets Manager.

If you’ve configured the Relay server correctly for secret store access and authorization, you will see the green online indicator.

Now, create a resource that uses the secret store, assign it to a Role that is assigned to a User, and verify that you can connect.

1. In the Admin UI, add a new resource such as a Server or Datasource and choose the AWS Secrets Manager Secret Store type.
2. Fill out the information for a resource whose credentials you have stored in your secret store.
3. Select the AWS Secrets Store you created for the Secret Store field, and then fill in the path to the secrets that you’ve stored in your secret store.
   1. AWS accepts plaintext secrets, which you would use to store one credential field per secret, or you can write out JSON secrets in the field, which could include many credential values with different keys. If using JSON, add the key along with the path to the credential, (e.g., example-secret?key=username).
   2. It is preferred that certificates be Base64-encoded. If the secret you are storing is a certificate, you should Base64-encode it, and then enter the path as follows when setting up a resource to use it: example-secret?key=certificate&encoding=base64.
4. Submit the form.
5. Go to Roles, create a Role with an access rule that grants access to the resource, and assign the Role to the User.
6. Log in as that User in your local GUI (or have the User do so, if not yours) and verify that the resource exists, test a connection, and execute a query.

Congratulations, you’ve connected to a resource using secret stores.