Ctrlk
Help CenterGet A Demo
For the complete documentation index, see llms.txt. This page is also available as Markdown.

AWS CLI and SDK Tools

This guide for developers who access AWS accounts through StrongDM cloud datasources (AWS instance-profile/assumed-role resources).

Overview

StrongDM is credential-less by design. When you access an AWS datasource:

  • StrongDM's proxy performs the AssumeRole and holds the real temporary credentials.

  • Your local traffic is routed to a StrongDM proxy listener, which re-signs each request with the real credentials before forwarding it to AWS.

  • Your client never receives the real temporary credentials. This is intentional and cannot be changed. There is no way to have StrongDM hand back usable aws_access_key_id or aws_secret_access_key or session token values.

Key mental model: sdm connect creates the per-datasource proxy listener, whereas HTTPS_PROXY selects which listener (account) your traffic goes to. The credentials and any AWS profile are passive. They never route and never determine your identity.

The command that wires this up is sdm aws env, which prints the environment variables your tools need. It does not execute anything or change your environment on its own (that is, you load its output into your shell).

Prerequisites

Before you begin, ensure you have the following:

  • StrongDM Desktop application installed and running

  • StrongDM CLI installed

  • Network access to Global Protect (Prisma Access) or your organization's VPN

  • Target AWS resource connected in StrongDM via the CLI or StrongDM Desktop

Steps

Step 1: Connect to StrongDM

In the terminal, run:

Use the exact name of your AWS resource as it appears in StrongDM. You can keep multiple resources connected simultaneously if needed.

Step 2: Inject AWS Environment Variables

Use the following command to inject the StrongDM-provided environment variables into your current shell session.

The set -a / set +a wrapper is required so the variables export to child processes (your scripts, IDEs, and tools).

Without set -a / set +a, eval sets the variables only in your interactive shell and they will not reach the programs you launch, and your tools will then fail with Unable to locate credentials.

What sdm aws env provides

When you run sdm aws env, it prints output such as the following:

Variable
Role

HTTPS_PROXY

Routes AWS traffic to StrongDM and selects which datasource/account you hit; this is the essential one

AWS_CA_BUNDLE

Tells the AWS CLI to trust the StrongDM proxy's TLS certificate

AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY

Placeholders (AWS's own documentation example keys) that exist only so the AWS CLI/SDK won't refuse to run with "no credentials"; their values are irrelevant, as StrongDM re-signs with the real role; seeing this is expected, not an error

AWS_SESSION_TOKEN=

Empty, to clear any stale token inherited from the parent shell

Step 3: Set the Proxy

The proxy value is already included in the output from step 2, but ensure it's explicitly available:

Obtain the exact HTTPS_PROXY value from:

  • The output of sdm aws env (already loaded in step 2)

  • sdm status output for the resource

  • StrongDM Desktop application resource details

This routes all AWS traffic through the StrongDM local proxy.

Setting HTTPS_PROXY globally can interfere with StrongDM CLI commands (such as sdm status, sdm connect, and so forth). See Troubleshooting for solutions.

Step 4: Export CA Bundle If Required

Only run this step if you encounter certificate validation errors. If step 2 worked without errors, you can skip this.

Step 5: Launch VS Code

Launch VS Code from the same terminal where you ran the above steps. This ensures that VS Code and its integrated terminal inherit the environment variables and proxy settings.

Why --user-data-dir? This runs VS Code as a separate instance with its own settings profile, so it coexists with a normal VS Code window (VS Code is otherwise single-instance and a second launch would open a window in an existing, un-wired process). VS Code extensions are still shared across instances.

If code is not in your PATH (common on macOS):

Find the exact path with find /Applications -name "Visual Studio Code.app" and quote it properly.

In VS Code:

  • Integrated terminal: Run aws ..., scripts, and Terraform with no prefix.

  • AWS Toolkit: Select your profile in the connection picker; it authenticates and browses resources through StrongDM.

  • The echo should show non-empty values for both HTTPS_PROXY and AWS_CA_BUNDLE.

  • aws sts get-caller-identity should return the AWS identity/role you expect from StrongDM.

Both commands should succeed:

In the terminal (or VS Code's integrated terminal), confirm the setup is working:

Step 6: Verify

In the terminal (or VS Code's integrated terminal), confirm that the setup is working:

Both commands should succeed:

  • The echo should show non-empty values for both HTTPS_PROXY and AWS_CA_BUNDLE.

  • aws sts get-caller-identity should return the AWS identity/role you expect from StrongDM.

Step 7: Switch to Another AWS Resource

If you need to work with a different AWS account or datasource, follow these steps:

1. Connect to the new resource:

2. Refresh the environment variables:

3. Update the HTTPS_PROXY value for the newly connected resource (repeat step 3).

4. Continue working, or relaunch VS Code from the updated terminal if needed.

You can keep multiple resources connected and switch as required, but always ensure that the proxy and environment variables match the active resource you're targeting.

Troubleshooting

Symptom
Cause
Fix

SSL validation failed … CERTIFICATE_VERIFY_FAILED (self-signed certificate…)

Traffic is reaching the StrongDM proxy but the CLI doesn't trust its cert — AWS_CA_BUNDLE not set/exported.

Run export AWS_CA_BUNDLE="$HOME/.sdm/org.crt". For the AWS Toolkit, also export NODE_EXTRA_CA_CERTS="$AWS_CA_BUNDLE".

Unable to locate credentials / NoCredentials

eval was run without set -a, so vars didn't export to child processes.

Use set -a; eval "$(sdm aws env)"; set +a. Verify with env | grep HTTPS_PROXY.

SSL validation failed … unable to get local issuer certificate on a real AWS endpoint

Request went direct to AWS — HTTPS_PROXY not set, so StrongDM was never used.

Set HTTPS_PROXY (via Step 3 or sdm aws env).

sdm connect → error loading datasources; other sdm commands fail

HTTPS_PROXY is set shell-wide, so sdm's own control-plane calls are misrouted through the AWS proxy.

Set NO_PROXY (see below) or use per-command HTTPS_PROXY.

VS Code cannot authenticate or run AWS commands

VS Code was not launched from the wired terminal, so it didn't inherit the environment variables.

Launch VS Code from the same terminal where you ran Steps 1–4. Verify the terminal itself can run aws sts get-caller-identity before opening VS Code.

Keep StrongDM CLI commands working

If you export HTTPS_PROXY shell-wide, the sdm CLI's own control-plane calls will also try to use that proxy and fail. Consider the following two solutions:

  • Preferred: Don't set HTTPS_PROXY shell-wide. Instead, use the per-command form (below), so your interactive shell never has it set.

  • Alternatively, carve StrongDM's hosts and loopback out of the proxy:

Add your organization's custom SDM domain if it isn't under strongdm.com.

Advanced: Terminal-only workflow (no VS Code)

If you prefer the command line and don't use VS Code, the setup is simpler:

This works for the AWS CLI, boto3/SDKs, Terraform, and any script.

Advanced: Per-command proxy (multiple accounts, no shell-wide state)

Set the proxy inline for a single command. You can hit any connected account per command without changing your shell's proxy:

Helper function for your ~/.zshrc:

Set a fixed port override on each datasource in StrongDM so every account has a stable, predictable listener host:port.

Advanced: AWS named profiles

AWS named profiles are optional and only play a supporting role:

  • Can hold ca_bundle, region, and the placeholder credentials.

  • Cannot hold the proxy. There is no proxy field in ~/.aws/config. HTTPS_PROXY always must be set in the environment (or as VS Code's http.proxy setting).

  • Does not select the account or determine your identity. That's the proxy and the StrongDM datasource, respectively.

If you prefer a named profile to carry the static pieces:

~/.aws/config

~/.aws/credentials

Then:

Limitations

  • No real temporary credentials are exposed. By design; there is no workaround.

  • HTTPS_PROXY is the only routing mechanism. It can't live in an AWS profile, and only the standard variable name works (an SDM_-prefixed name does nothing).

  • One account per shell / window. Switching accounts means changing the proxy value.

  • Session-wide HTTPS_PROXY affects non-AWS traffic too. Any HTTPS call in that shell/window (including sdm commands and things like a plugin fetching from GitHub) routes through the proxy. Use NO_PROXY or per-command scoping to contain it.

  • GUI profile switching is not account switching. Selecting a different profile in the AWS Toolkit does not switch which StrongDM account you reach. The account is determined by the proxy, which is a single value per window. To switch accounts in the GUI, repoint the proxy (edit the http.proxy VS Code setting and reload, or relaunch wired to the other datasource). For genuine multi-account work, use the terminal.

Quick Reference

Last updated

Was this helpful?