aws_sign
The aws_sign directive enables AWS Signature Version 4 authentication when proxying requests to AWS services.
Description
The aws_sign directive is used in NGINX configurations to enable automatic signing of requests to AWS services, specifically for authenticated proxying to Amazon S3 or other AWS endpoints using the Signature Version 4 signing process. This directive does not take any arguments and is implemented in conjunction with other directives such as aws_access_key, aws_key_scope, and aws_signing_key that provide the necessary credentials and context for the signing process.
When this directive is included within the server or location block, NGINX utilizes the configured AWS credentials and signing information to sign outgoing requests. The signing takes into account factors such as the request URI, headers, and timestamp, generating a valid authorization header that AWS requires to authenticate the request. Using this directive helps ensure that sensitive AWS keys are not directly exposed while maintaining the ability to interact with AWS services securely through NGINX.
It's important to properly configure the aws_access_key, aws_key_scope, and aws_signing_key along with the aws_sign directive to ensure the signing process works seamlessly. A misconfiguration could lead to authentication errors when NGINX tries to communicate with AWS services.
Config Example
server {
listen 8000;
aws_access_key your_aws_access_key;
aws_key_scope scope_of_generated_signing_key;
aws_signing_key signing_key_generated_using_script;
aws_s3_bucket your_s3_bucket;
location / {
aws_sign;
proxy_pass http://your_s3_bucket.s3.amazonaws.com;
}
}Ensure all related AWS credentials are correctly specified; mismatched keys can lead to authentication failures.
Signing keys generated have a limited validity (one week); ensure they are refreshed regularly.
The order of directives is critical; aws_sign must be properly defined within the relevant context (server or location) to take effect.