Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Why AccessKeyId is included in s3 pre-signed URL?

Why AccessKeyId is included in s3 pre-signed URL? Is it really necessary? The pre-signed URL already includes the Signature field, why it still requires the AccessKeyId as well? Wouldn't be the Signature sufficient?

like image 822
injoy Avatar asked Apr 05 '19 22:04

injoy


People also ask

What are S3 pre-signed URLs?

Pre-signed URLs are used to provide short-term access to a private object in your S3 bucket. They work by appending an AWS Access Key, expiration time, and Sigv4 signature as query parameters to the S3 object. There are two common use cases when you may want to use them: Simple, occasional sharing of private files.

Does S3 bucket need to be public for Presigned URL?

All objects and buckets are private by default. However, you can use a presigned URL to optionally share objects or allow your customers/users to upload objects to buckets without AWS security credentials or permissions.

Why should you use S3 Presigned URLs?

The main purpose of presigned URLs is to grant a user temporary access to an S3 object. However, presigned URLs can be used to grant permission to perform additional operations on S3 buckets and objects.

What is the main advantage to a pre-signed URL?

A presigned URL gives you access to the object identified in the URL, provided that the creator of the presigned URL has permissions to access that object.


1 Answers

The signature is used to prove two things:

  • that the signer authorizes this specific request, and
  • that the signer was in possession of the secret key associated with the specified access-key-id.

Importantly... the signature does not actually contain any meaningful information. It's either right or it's wrong.

It's an HMAC-based hash of public (the request being made) and private (the secret key) information. The service doesn't "decode" it or interpret it or learn anything from it.

Instead, the service -- using the access-key-id -- looks up the associated secret key,¹ takes the request; and internally generates the signature you should have generated for the same request... then it checks to see if that's what you actually generated.² If not, the error is SignatureDoesNotMatch. The error is not more specific because the signature for any given request at any moment in time has only one possible value. Any other signature is simply the wrong signature.

But the access-key-id must be specified so the service knows who's making the request. The signature does not contain any reversible/decodable/decryptable information.


¹ looks up the associated secret key is probably an oversimplification when using Signature Version 4 because there are layers of (date, region, service, signing) keys derived from the IAM user's secret key... and the structure and nesting implies that individual services have access only to the relevant values they need.

² you generated is an important phrase, since there is some potential for misunderstanding of the source of pre-signed URLs. These are generated entirely in your code, with no interaction with the service. S3 is unaware of the existence of any pre-signed URLs until they are actually used. This has implications that can sometimes be useful; for example, it is entirely possible to generate a pre-signed URL for an object that does not yet exist, and create the object later. Also, disabling or deleting the aws-access-key-id that was used to generate a pre-signed URL immediately invalidates all URLs that key ever generated.

like image 143
Michael - sqlbot Avatar answered Sep 22 '22 08:09

Michael - sqlbot