How to configure credential_process in AWS CLI

Using an external credentials helper with AWS CLI is useful when a profile must receive short-lived credentials from another command instead of storing static access keys locally. That pattern fits vault-backed workflows, federated sign-in helpers, role-brokering scripts, and other environments where the shell should ask for fresh credentials when a command runs.

The credential_process setting lives in the shared AWS CLI config file for a profile. When that profile is used, the CLI runs the configured command, reads JSON credentials from STDOUT, and uses the returned access key, secret key, session token, and expiration time for the request. The helper output must use Version 1, and temporary credentials should include Expiration so the CLI and supporting SDKs know when to refresh them.

Examples here target AWS CLI v2 with a dedicated named profile such as developer. Keep the command string literal in the profile entry, avoid $HOME, %USERPROFILE%, or ~ inside the setting, and do not let the helper write secrets to STDERR. The external-process provider is not cached by the CLI the way assumed-role credentials are, so helpers that perform expensive sign-in work should implement their own cache.

Steps to configure credential_process in AWS CLI:

Choose the named profile that should use the external credentials.
```
developer
```
Use a dedicated profile when possible. If the current shell or profile already has valid credentials from a higher-precedence source, the external process might not be the credential source that the CLI actually uses.

Run the helper command by itself and confirm that it prints valid JSON to STDOUT.

$ /opt/bin/aws-creds-helper --profile developer
{
  "Version": 1,
  "AccessKeyId": "ASIAIOSFODNN7EXAMPLE",
  "SecretAccessKey": "coreSecretExample0000000000000000000000001",
  "SessionToken": "AQoDYXdzEJr...<remainder of security token>",
  "Expiration": "2030-01-01T00:00:00Z"
}

Version must be 1. The Expiration value should use RFC3339 format when the helper returns temporary credentials.

Keep secret material on STDOUT only. The AWS CLI and SDKs can capture STDERR in logs.

Save the external-process command into the target profile.
```
$ aws configure set credential_process "/opt/bin/aws-creds-helper --profile developer" --profile developer
```
This writes credential_process under [profile developer] in the shared config file without making a live AWS API call.

Use either a full path or a base file name that is already in PATH. Do not use $HOME, %USERPROFILE%, or ~ in the saved command string. If a path or argument contains spaces, wrap only that path or argument in double quotes.
Read the saved value back from the profile to confirm that the setting was written correctly.
```
$ aws configure get credential_process --profile developer
/opt/bin/aws-creds-helper --profile developer
```
aws configure get reads the stored profile value directly, so it is the cleanest check that the setting itself is correct before testing runtime credential resolution.
Inspect the shared AWS CLI config file when the profile section or file location needs to be confirmed directly.
```
$ sed -n '1,12p' ~/.aws/config
[profile developer]
credential_process = /opt/bin/aws-creds-helper --profile developer
```
Store credential_process in ~/.aws/config on Linux or macOS, or in
```
%UserProfile%\\.aws\\config
```
on Windows. Do not put it in the shared credentials file.
Related: How to find the AWS CLI config file

Check which credential source the AWS CLI resolves for the profile before making a service API call.

$ aws configure list --profile developer
NAME       : VALUE                    : TYPE             : LOCATION
profile    : developer                : manual           : --profile
access_key : ****************MPLE     : custom-process   :
secret_key : ****************EKEY     : custom-process   :
region     : <not set>                : None             : None

The custom-process type confirms that the helper is supplying the credentials for that profile. If the type shows env, shared-credentials-file, or another source, something else is overriding the intended process-backed profile.

Export the resolved credentials in process format to confirm that the saved profile can run the helper successfully.
```
$ aws configure export-credentials --profile developer --format process
{
  "Version": 1,
  "AccessKeyId": "ASIAIOSFODNN7EXAMPLE",
  "SecretAccessKey": "coreSecretExample0000000000000000000000001",
  "SessionToken": "AQoDYXdzEJr...<remainder of security token>",
  "Expiration": "2030-01-01T00:00:00+00:00"
}
```
This verifies credential resolution without sending a service request.

If another AWS CLI profile already handles the sign-in flow, a second profile can reuse it with credential_process = aws configure export-credentials --profile signin --format process.

Related: How to log in to AWS CLI with IAM Identity Center
Related: How to assume an IAM role using AWS CLI
Run a final identity check with the configured profile.
```
$ aws sts get-caller-identity --profile developer
{
    "UserId": "AROAEXAMPLEID:developer-session",
    "Account": "123456789012",
    "Arn": "arn:aws:sts::123456789012:assumed-role/DeveloperAccess/developer-session"
}
```
If this fails, re-run the helper by itself, confirm that the saved command string still matches exactly, and check for exported AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, or AWS_SESSION_TOKEN variables in the shell.

Related: How to check the current caller identity in AWS CLI
Related: How to use environment variables in AWS CLI