How Aembit uses AWS SigV4 and SigV4a

AWS Signature Version 4 (SigV4) and Signature Version 4a (SigV4a) are AWS request signing protocols that Aembit uses to sign HTTP requests from Client Workloads to AWS services when using credentials obtained from Aembit’s AWS Security Token Service (STS) Credential Provider. During authentication, SigV4 makes sure a request is authentic, unaltered in transit, and not replayed.

SigV4 versions

SigV4 has two versions:

• SigV4 is AWS’s standard signing process. It requires that you specify the exact AWS region where you’re sending a request (such as us-east-1, us-east-2). AWS scopes the signing key and signature to that specific region. AWS requires a new signature if you send the same request to a service in a different region. For most requests to AWS regional endpoints, AWS uses SigV4.

• SigV4a extends SigV4 to support multi-region AWS services, in cases where you route a request across multiple AWS regions. Instead of specifying a single region in the signature, SigV4a uses a region wildcard (*), allowing the signature to be valid across all AWS regions. For requests to AWS global service endpoints or any service that supports cross-region requests, AWS requires SigV4a.

SigV4 version selection

Aembit automatically determines whether to use SigV4 or SigV4a when a Client Workload uses an AWS STS Credential Provider to access AWS services. It works like this:

• When a Server Workload’s hostname includes a region (such as us-east-1 or us-east-2), Aembit uses SigV4, scoping the signature to only that region.

• When the Server Workload’s hostname doesn’t include a region (S3 Multi-Region Access Points or other global AWS services), Aembit uses SigV4a, which allows the signature to work across AWS regions.

Aembit performs this selection automatically based on the hostname structure, following AWS’s standard endpoint formats. You don’t need to make configuration changes to benefit from this and your existing AWS STS Credential Providers automatically gain support for SigV4a where applicable.

Workload identity and service access separation in AWS

When working with Aembit Trust Providers and Credential Providers in AWS environments, it’s important to understand the roles each of these play. Aembit uses Trust Providers to verify who a workload is, and Credential Providers to control what AWS services that workload can access.

1. Trust Providers (like the AWS Role Trust Provider) verify who a workload is by confirming the AWS environment it’s running in and the IAM Role it’s using.

2. Once Aembit verifies the workload’s identity, the AWS STS Credential Provider retrieves temporary AWS credentials for the workload, tied to the IAM Role verified by the Trust Provider.

3. When the workload makes API requests to AWS services like S3, Lambda, or SQS, Aembit’s Agent Proxy automatically signs those requests using AWS SigV4 for regional services, or SigV4a for global or multi-region services.

This clear separation makes sure that:

• Only attested workloads receive AWS credentials.

• Aembit secures All AWS service access using temporary credentials, eliminating the need for long-lived secrets.

• Aembit automatically applies the correct SigV4 or SigV4a signing process based on the destination service and hostname.