The End of the Long-Lived Key: Setting Up Just-in-Time Access and Zero Standing Privileges for AWS CLI

For years, the standard developer onboarding ritual involved generating an AWS Access Key ID and Secret Access Key, pasting them into ~/.aws/credentials, and forgetting about them entirely.

Static, long-lived credentials stored on local machines are a major security liability. If a developer’s laptop is compromised, or if a hardcoded key is accidentally pushed to a public repository, an attacker gains permanent, unencumbered access to the cloud infrastructure.

Zero Standing Privileges (ZSP) and **Just-in-Time (JIT) Access eliminate this vulnerability. Under this framework, developers carry zero permanent credentials on disk and zero default administrative rights**. When an engineer needs to run an AWS CLI command, they authenticate dynamically, acquire temporary tokens that automatically expire, and elevate their permissions only when a validated business reason exists.

Here is the step-by-step engineering blueprint to implement a continuous, zero-standing-privilege pipeline for the AWS CLI.

The Core Architecture

To transition the CLI from static keys to JIT access, the architecture shifts away from local IAM users toward a centralized identity broker.

[Developer Laptop] ──(aws sso login)──► [IAM Identity Center] ──► [IdP: Okta/Entra]
        ▲                                        │
        └─────── (Short-Lived STS Token) ────────┘

• The Identity Provider (IdP): Okta, Entra ID, or Google Workspace remains the single source of truth for human identity.
• AWS IAM Identity Center: Serves as the cloud-native broker, mapping external directory groups to short-lived AWS Permission Sets.
• AWS Security Token Service (STS): Issues ephemeral credentials valid for a bounded duration (typically 1 to 12 hours) directly to the local CLI environment.

2. Step 1: Configuring AWS IAM Identity Center

Before configuring the CLI, the infrastructure team must establish identity federation in the AWS Management Console.

• Federate the Directory: Navigate to AWS IAM Identity Center, enable the service, and connect your external IdP using SAML 2.0 and SCIM for automatic user synchronization.
• Define Permission Sets: Create distinct, role-based profiles. For standard daily operations, provision a low-blast-radius role like DeveloperPowerUser or ReadOnlyAccess. Avoid assigning global AdministratorAccess as a standing assignment.
• Set Session Durations: Configure the maximum session duration for the permission set. For high-velocity DevOps, limit the session lifetime to 1 to 2 hours to ensure old tokens decay quickly.

3. Step 2: Configuring the AWS CLI for SSO Sessions

With federation in place, developers can entirely delete the traditional ~/.aws/credentials file. The AWS CLI natively interacts with IAM Identity Center via automated browser redirection.

Run the interactive SSO configuration wizard on the terminal:

Bash

aws configure sso

The prompt will ask for your configuration details. Input them based on your organization’s environment:

Plaintext

SSO start URL [None]: https://my-company.awsapps.com/start
SSO region [None]: us-east-1
SSO registration scopes [sso:account:access]: 
Attempting to automatically open the SSO authorization page in your default browser.

The CLI will automatically launch a secure browser window requesting your corporate IdP login and Multi-Factor Authentication (MFA). Once authorized, the CLI will display the available AWS accounts and permission sets mapped to your identity.

Inspecting the Config File

This process populates ~/.aws/config with an explicit sso-session block, decoupling authentication from local file storage:

Ini, TOML

[sso-session corporate-sso]
sso_start_url = https://my-company.awsapps.com/start
sso_region = us-east-1
sso_registration_scopes = sso:account:access

[profile dev-core]
sso_session = corporate-sso
sso_account_id = 123456789012
sso_role_name = DeveloperPowerUser
region = us-west-2
output = json

4. Step 3: Daily CLI Workflow with Zero Standing Keys

Once configured, the daily operational workflow requires no manual password or token handling.

At the start of the workday, the engineer runs:

Bash

aws sso login --profile dev-core

The command verifies the local cached token status. If expired, it triggers a fast browser authentication loop. Once verified, AWS STS generates short-lived credentials and stores them securely in memory or encrypted local caches (~/.aws/sso/cache/).

The developer can now run standard commands safely:

Bash

aws s3 ls --profile dev-core

Security Note: If the laptop is lost or stolen at the end of the day, an administrator can immediately invalidate every active CLI session globally by clicking Revoke active sessions inside the AWS IAM Identity Center console, instantly rendering cached local tokens useless.

5. Step 4: Implementing Just-in-Time Elevation for Admin Actions

True Zero Standing Privileges means that no engineer — not even senior cloud architects — holds standing “Admin” access. For sensitive operations like deploying infrastructure modifications to Production, altering core networking, or running break-glass emergency fixes, access must be elevated dynamically.

This can be accomplished via native tooling or customized open-source workflows using the AWS TEAM (Temporary Elevated Access Management) application model.

The JIT Elevation Pipeline

• The Baseline State: The engineer’s standard CLI profile (dev-core) lacks permissions to modify production architectures.
• The Request Trigger: When elevated access is required, the engineer submits a request via a specialized web portal, a Jira ticket, or a ChatOps Slack integration, providing a valid change ticket ID and business justification.
• The Automated Approval Loop: For low-risk environments, an automated policy approves the request based on open schedules; for Production, it routes an active alert to an on-duty Team Lead.
• Dynamic Assignment Creation: Upon approval, an event-driven Lambda function calls the AWS Organizations API to dynamically create a temporary account assignment:

Bash

aws sso admin create-account-assignment \
    --instance-arn arn:aws:sso:::instance/ssoins-1122334455667788 \
    --target-id 987654321098 \
    --target-type AWS_ACCOUNT \
    --permission-set-arn arn:aws:sso:::permissionSet/ssoins-112233/ps-admin-set \
    --principal-type GROUP \
    --principal-id a1b2c3d4-e5f6-7a8b-9c0d-1e2f3a4b5c6d

• Execution: The developer triggers a profile reload (aws sso login --profile prod-admin), completes the authorized task, and logs off.
• Automatic Teardown: Once the specified time window closes (e.g., exactly 60 minutes), a time-enforced EventBridge rule triggers an automated deletion script, stripping the permission set away and restoring the engineer back to zero standing privileges.

6. Verification and Enforcement Best Practices

To guarantee that developers do not circumvent the JIT pipeline by manually creating legacy access keys, security leaders must enforce control boundaries at the organization level.

Service Control Policy (SCP): Block Legacy Key Creation

Deploy a global Service Control Policy across your AWS Organization to systematically prevent users from generating static, long-lived access keys:

JSON

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "BlockStaticAccessKeyCreation",
      "Effect": "Deny",
      "Action": [
        "iam:CreateAccessKey",
        "iam:UpdateAccessKey"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotLike": {
          "aws:PrincipalARN": [
            "arn:aws:iam::*:role/OrganizationAccountAccessRole",
            "arn:aws:iam::*:role/aws-reserved/sso.amazonaws.com/*"
          ]
        }
      }
    }
  ]
}

Conclusion

Moving your engineering team to Zero Standing Privileges for the AWS CLI eliminates the primary cause of modern cloud data breaches: leaked developer credentials. By replacing static files with native aws sso sessions, leveraging Policy-as-Code to govern boundaries, and introducing automated JIT approval loops for sensitive environments, you transform identity into a dynamic runtime parameter. The result is an infrastructure that remains agile, automated, and structurally closed to unauthorized lateral movement.