Roles, temporary credentials, and SigV4

Using AWS Security for Developers

Rahul Singh

Technical Product Manager

The key that outlives the task

To speed up work, a key gets created in a script and is stored in a configuration file.

Inside the file it is:

Never rotated
Never revoked
Never expired

One access key fanning out into six storage locations, with a time axis on the right showing it still valid at month eighteen

The key that outlives the task

To speed up work, a key gets created in a script and is stored in a configuration file.

Inside the file it is:

Never rotated
Never revoked
Never expired

18 months later, it is still valid

One access key fanning out into six storage locations, with a time axis on the right showing it still valid at month eighteen

Credentials that expire on their own

Make expiry the default using AWS STS

Request a role, get credentials with a built-in clock
Security Token Service (STS): expiry attached, one hour by default

An application calls AssumeRole on AWS STS, and STS returns credentials carrying a built-in clock.

Credentials that expire on their own

Make expiry the default using AWS STS

Request a role, get credentials with a built-in clock
Temporary credentials start with ASIA and carry a session token
Security Token Service (STS): expiry attached, one hour by default

An application calls AssumeRole on AWS STS and receives credentials with a built-in clock. Below it, two credentials side by side: a long-lived key beginning AKIA that carries no session token and never expires, and temporary credentials beginning ASIA that carry a session token and expire in one hour.

Credentials that expire on their own

Make expiry the default using AWS STS

Request a role, get credentials with a built-in clock
Temporary credentials start with ASIA and carry a session token
The same call is accepted, then it is not
Security Token Service (STS): expiry attached, one hour by default

An application calls AssumeRole on AWS STS and receives credentials with a built-in clock. Below it, a long-lived key beginning AKIA that never expires beside temporary credentials beginning ASIA that carry a session token and expire in one hour. Below that, the same GetObject call returning 200 OK at ten o'clock and ExpiredToken at five past eleven.

How your code finds them

Checking the credential provider chain

The AWS SDK, the library in your code, does the searching
A fixed list, checked in order
Stops at the first match

Credential lookup order: a key passed in code is struck through above the chain, and the search then runs down environment variables, config file and container credentials, stopping at the first match and never reaching instance metadata

How your code finds them

Checking the credential provider chain

The AWS SDK, the library in your code, does the searching
A fixed list, checked in order
Stops at the first match

Hard-coded keys are checked first, and therefore need to be deleted

The chain, link by link

1. explicit      a key passed in your code
2. environment   AWS_* variables, and on Lambda
                 that is the execution role
3. config file   ~/.aws/credentials
4. container     ECS or EKS task role
5. instance      EC2 instance profile, via IMDS

First match wins
Delete the stored key, the search continues to the role

Proving identity from outside AWS

Code pipelines often run outside AWS, so the credential chain cannot be attached

Runs on GitHub or GitLab
Nothing for the chain to find

A CI runner and its platform drawn outside the AWS boundary, the runner marked as having no role to attach, and the platform signing an OIDC token that names one repository and one workflow

Proving identity from outside AWS

Code pipelines often run outside AWS, so the credential chain cannot be attached

Runs on GitHub or GitLab
Nothing for the chain to find

OIDC token (OpenID Connect)

Signed and short-lived
A statement of identity, not a credential

A CI runner and its platform drawn outside the AWS boundary, the runner marked as having no role to attach, and the platform signing an OIDC token that names one repository and one workflow

A rule instead of a stored key

An OIDC token naming a repository, exchanged through AssumeRoleWithWebIdentity for temporary credentials that expire in one hour, because the role's trust policy already names that issuer and that repository

Trading the token for credentials

A rule instead of a stored key

Trading the token for credentials

AssumeRoleWithWebIdentity: AssumeRole, with an outside token as proof
Trust policy: written on the role in advance, not stored in the pipeline
Claim: one fact inside the token
Issuer is shared by every repository on the platform, so pin the repository too

Repository secrets: now empty

Every request is signed

Signature Version 4, or SigV4

Proves which credential made the request
Proves the request was not altered in transit
Signed by the CLI and SDK on every call

Signing flow in which a request and your credentials produce a signature sent in the Authorization header, which AWS recomputes and compares, accepting on a match and returning SignatureDoesNotMatch on a mismatch

A signature you can hand over

Temporary credentials

Many actions, scoped by the role
Held by your code

Your code calling four different AWS services, S3, DynamoDB, SQS and KMS, with temporary credentials

A signature you can hand over

Temporary credentials

Many actions, scoped by the role
Held by your code

Pre-signed URL

One object, one action, and anyone holding the link
An expiry you choose, then nothing
Carries your permissions, not the holder's

Your code calling four different AWS services, S3, DynamoDB, SQS and KMS, with temporary credentials

Someone else's browser reaching exactly one object through a single path, interrupted by a clock labelled the expiry you set

Let's practice!

Using AWS Security for Developers