Ditch IAM Static Keys: A Guide to SSO for AWS CLI

Are you still using IAM static keys (Access Key ID and Secret Access Key) to log in with AWS CLI?

It still works. But' there's a catch.

These keys are long-term. They are notorious for being accidentally committed to version control, shared improperly, or forgotten about until a security audit forces a painful rotation process. When you are rapidly provisioning infrastructure—whether that means running local Terraform plans, testing Ansible playbooks, or pushing container images—leaving static keys sitting on your hard disk is an unnecessary vulnerability.

The AWS-recommended best practice is to use AWS IAM Identity Center (formerly AWS SSO). Instead of relying on static keys, Identity Center provides temporary, short-lived credentials that automatically expire.

In this guide, we will walk through setting up a seamless, secure local development environment by configuring AWS CLI to authenticate via SSO (AWS Identity Center), allowing you to ditch those IAM static keys for good.

Prerequisite: Enable IAM Identity Center (For Cloud Admins)

If you are the cloud administrator reading this and realize you haven't actually turned this feature on yet, don't worry. Enabling IAM Identity Center and generating the Start URL only takes a few clicks.

(Note: Identity Center cannot be enabled via the AWS CLI or Terraform. The initial activation must be done manually in the AWS Management Console.)

Step 1: Enable the Service

1. Sign in to the AWS Management Console. (Crucial step: If you are using AWS Organizations, you must be logged into the **Management Account—often called the root or master account).
2. Using the top search bar, find and open IAM Identity Center.
3. Under the "Enable IAM Identity Center" section, click Enable.
4. You will be prompted to select an instance type:
5. Organization Instance (Recommended): Choose this if you use AWS Organizations. It allows you to manage user access centrally across all your AWS accounts.
6. Account Instance: Choose this only if you are managing a single, standalone AWS account with no sub-accounts.

Step 2: Locate Your Start URL and Region

Once the service finishes provisioning, you will be dropped onto the IAM Identity Center dashboard.

1. Find the Start URL: On the dashboard, look for the Settings summary box. You will see a field labeled AWS access portal URL. This is your SSO Start URL (it usually looks like [https://d-xxxxxxxxx.awsapps.com/start](https://d-xxxxxxxxx.awsapps.com/start)).
2. Find the Region: Your SSO Region is simply the AWS Region you were in when you clicked "Enable" (e.g., us-east-1 or eu-west-1). Check the top right corner of your console to confirm.

Step 3: Create Users

With the service enabled, you have two choices for managing your users:

• The Built-in Directory: You can create users and groups directly within the IAM Identity Center console. This is the fastest way to get started.
• External Identity Provider: You can connect Identity Center to your company's existing directory (like Google Workspace, Okta, or Microsoft Entra ID) using SAML and SCIM, allowing your developers to log in to AWS using their existing company credentials.

Once you have users created and assigned to AWS accounts via "Permission Sets," you can hand them the Start URL and **Region **so they can configure their CLI!

Prerequisites or Non Cloud Admins

If you are not the cloud admin, request these SSO Connection Details from your admin:

• SSO Start URL: The portal URL where you log in (e.g., [https://my-company.awsapps.com/start](https://my-company.awsapps.com/start)).
• SSO Region: The AWS Region where your Identity Center is deployed (e.g., us-east-1).
• Username and Password: This is your username and password created by the cloud admin in the AWS Identity Center

Setup your laptop: Install AWS CLI

You need AWS CLI Version 2: This is the most critical requirement. AWS CLI version 1 does not natively support SSO authentication without external plugins. You can check your version by running aws --version. If you see aws-cli/1.x, you must uninstall it and install version 2.

• File Paths: Throughout this guide, we will reference the AWS configuration file located at ~/.aws/config. This is the standard path for macOS and Linux users. If you are following along on Windows, this file is located at C:\Users\USERNAME\.aws\config.

The Step-by-Step Configuration Guide

Now you have everything ready.

To make the next step easy, AWS CLI has a built-in wizard.

Open your terminal and follow these steps.

Step 1: Start the Wizard

Kick off the interactive configuration by running the following command:

aws configure sso

Step 2: Provide Your Session Details

The CLI will immediately prompt you to define your sso-session (your authentication layer). Fill in the details as follows:

• SSO session name: Give this a recognizable name, like your company or organization name (e.g., my-company-sso). You will reuse this session name if you add more profiles later.
• SSO start URL: Paste the portal URL provided by your administrator (e.g., [https://my-company.awsapps.com/start](https://my-company.awsapps.com/start)).
• SSO region: Enter the AWS region where your Identity Center is physically deployed (e.g., us-east-1). Note: This is the region hosting your SSO directory, not necessarily the region where you plan to deploy your infrastructure.
• SSO registration scopes: Press Enter to accept the default value (sso:account:access).

Step 3: Authorize in Your Browser

Once you hit enter on the registration scope, the CLI will automatically attempt to open your default web browser and display an authorization code.

Note: If you are using WSL on windows, or VM environment like Multipass in your laptop, it will not be able to automatically open the browser. Just copy-paste the URL in the terminal output in to your browser.

1. If you aren't already logged into your company portal, you will be prompted to enter your credentials and pass any required Multi-Factor Authentication (MFA).
2. You will see a page asking you to authorize the CLI request. Click Confirm and continue (or Allow).
3. Once the browser displays a "Successfully logged in" message, you can close the tab and return to your terminal.

Step 4: Select Your Account and Role

Back in your terminal, the CLI has now successfully authenticated and retrieved a list of everything you are authorized to access.

1. Select an account: If you have access to multiple AWS accounts within your organization, use the up and down arrow keys to highlight the account you want to configure, then press Enter.
2. Select a role: Next, the CLI will display the IAM Roles assigned to you in that specific account. Select the role you need for this profile (e.g., AdministratorAccess or ReadOnlyAccess) and press Enter.

Step 5: Finalize Your Profile Preferences

Finally, the CLI needs to know how you want this specific profile (your authorization layer) to behave locally.

• CLI default client Region: Enter the AWS region you will be interacting with most often for this account (e.g., us-west-2 or ap-south-1).
• CLI default output format: Type json and press Enter. This is the most readable and widely used format for parsing AWS CLI output.
• CLI profile name: The CLI will suggest a long, messy auto-generated name combining the account ID and role. Delete it. Type a short, memorable name that describes this connection (e.g., dev-admin or prod-readonly). This is the name you will type every time you run a command.

Once you press Enter on the profile name, the wizard is complete! Your ~/.aws/config file is now populated with both your sso-session block and your newly created profile block.

Resolving the sso-session and the profile confusion

Check the resulting config file in ~/.aws/config.

[profile cloudqubes-admin]
sso_session = cloudqubes
sso_account_id = xxxxxxx
sso_role_name = AdministratorAccess
region = us-east-2
[sso-session cloudqubes]
sso_start_url = https://yyyyyyyyy
sso_region = us-east-1
sso_registration_scopes = sso:account:access
[default]
cli_auto_prompt = on-partial
cli_history = enabled

There are 2 confusing parameters here: profile and sso-session:

Understanding them is the "missing link" to mastering your local AWS setup. It boils down to the difference between authentication (who you are) and authorization (what you are allowed to do).

The sso-session (Authentication)

Think of the sso-session block as your corporate ID badge.

• It defines how you authenticate with your company's directory (using your Start URL and Region).
• It establishes a temporary, secure session between your local machine and your identity provider.
• You typically only have one sso-session block per company or AWS Organization.

The profile (Authorization)

Think of a profile block as a specific room key you are allowed to check out because you have a valid ID badge.

• It defines what you are accessing by specifying an exact AWS Account ID and an IAM Role name (like AdministratorAccess or ViewOnlyAccess).
• It defines your local command-line preferences for that specific role, such as your default AWS region and preferred output format (like JSON).
• You will usually have many profiles—one for every environment or role you manage (e.g., dev-admin, prod-readonly, staging-developer).

The 1-to-Many Relationship

The true power of this modern setup is how these blocks interact. In your ~/.aws/config file, multiple profile blocks will reference the exact same sso-session name.

Because they share a session, you only have to log in once at the start of your day. After that initial authentication, you can seamlessly switch between dozens of different AWS accounts and roles in your terminal without ever being prompted for a password again, until your session expires (about 12 hours later).

Assuming you have two different profiles cloudqubes-admin and deployment-user, here's how you can select the relevant profile for each command.

aws s3 ls --profile cloudqubes-admin

aws ec2 describe-instances --profile deployment-user

Setting Up a Default Profile (The Pro-Tip)

Appending --profile cloudqubes-admin to every single AWS CLI command gets tedious quickly. If you have a primary AWS account you work in most of the time, you can configure it as your default. When the CLI sees a [default] block in your configuration, it automatically uses those settings without requiring the --profile flag.

There are two ways to set this up.

Method 1: Manually Edit the Config File

If you have already completed the wizard and created a profile, you can easily convert it to your default by editing the config file directly.

1. Open your configuration file (~/.aws/config).
2. Locate the profile block you just created (e.g., [profile dev-admin]).
3. Rename the heading to exactly [default].

Before:

[profile dev-admin]
sso_session = my-company-sso
sso_account_id = 123456789012
sso_role_name = AdministratorAccess
region = us-west-2
output = json

After:

[default]
sso_session = my-company-sso
sso_account_id = 123456789012
sso_role_name = AdministratorAccess
region = us-west-2
output = json

(Leave your [sso-session] block exactly as it is at the bottom of the file.)

Method 2: Through the Wizard

If you haven't run the wizard yet, or prefer not to touch the text file, you can set the default directly during the aws configure sso process.

Follow all the steps as we did during initial setup, but when the terminal prompts you for the CLI profile name at the very end, delete the auto-generated string and type default.

Daily Usage and Workflow

With your configuration saved, your daily workflow becomes incredibly streamlined.

Starting Your Day

Because SSO tokens are temporary, they will expire (typically after 8 to 12 hours, depending on how your administrator configured Identity Center). At the start of your workday, you need to authenticate your session.

If you set up a default profile, run:

aws sso login

If you kept a named profile (e.g., dev-admin), specify it in the login command:

aws sso login --profile dev-admin

This will pop open your browser for a quick authorization click, and you are authenticated for the rest of the day.

Verifying Your Access

To confirm you are successfully authenticated and assuming the correct role, run the following command. It acts as the AWS equivalent of whoami:

aws sts get-caller-identity

(Remember to append --profile dev-admin if you didn't set a default).

If successful, this will return a JSON block displaying your Account ID and the specific SSO Role you are currently using.

Pro-Tip: The Environment Variable Shortcut

If you need to switch between multiple profiles (e.g., dev, staging, prod) and don't want to use the [default] block or type the --profile flag constantly, you can lock your terminal session to a specific profile by exporting an environment variable:

export AWS_PROFILE=staging-developer

Once exported, every AWS CLI command, Terraform run, or Python script executed in that specific terminal window will automatically use the staging-developer profile.

Wrapping Up

Transitioning away from static IAM Access Keys is one of the highest-impact security improvements you can make for your local development environment. By leveraging AWS IAM Identity Center, you eliminate the persistent risk of accidentally committing long-term credentials to version control, and you completely remove the administrative headache of mandatory key rotation. Instead, you get a clean, secure, multi-account workflow powered entirely by short-lived tokens.

Now that your CLI is authenticated, put it to the test. Try running your daily infrastructure tasks—whether that means applying a Terraform or OpenTofu configuration, running Ansible playbooks against your EC2 fleet, or executing Python automation scripts. Because standard AWS SDKs automatically recognize your configured ~/.aws/config profiles, your existing tools will pick up the active SSO session seamlessly.

Your next step: Audit your local machine and your AWS account to close the loop on your security upgrade.

1. Delete the local file: Permanently delete your old ~/.aws/credentials file from your computer.
2. Revoke the keys in AWS: Log into the AWS Management Console, navigate to the IAM dashboard, and find your old IAM User. Under the Security credentials tab, find your old Access Keys, make them Inactive, and then Delete them.

Local deletion only removes your copy; deleting them in the AWS console ensures those keys can never be exploited by anyone, anywhere. Your future self (and your security team) will thank you.