1 Answers
I have not tested it but I am pretty sure that the URL will be invalid after the credentials expired in one hour even if signed for one week.
This is the rationale:
When you call the presign command you are just signing an object with a set of credentials, but nobody checks that that credentials are valid. There is no API call to AWS to presign an URL, you can disconnect your computer from the network and you will be able to presign an URL. You are just doing the math to calculate the signature, you can sign anything, you will be able to presign with regular IAM user access keys that have ben revoked years ago, you can even sign with any value in the expires-in parameter.
When you presign the URL you are saying to the server evaluating the GetObject API call in the future: "I allow access to this object until this day and time". But is the server who checks in the moment of access that the signature is valid, that in the moment of access those credentials have access to that object and that the expire time in the signature has not passed. A perfectly valid signature whose API Key/Secret have been deleted from IAM at the moment of access just does not work.
So, you may sign with the temporary credentials of a role, you can sign with an expiration of one week. But the validity of the signature will be evaluated in the moment of access. If the credentials have expired in that moment, or the signature has expired in that moment the request will be denied.
Corollary: If you sign something and the realize that you made a mistake just revoke the Access keys in IAM.
Great and detailed answer, bcxpro – makes absolute sense. Thank you very much.
I forgot to add one thing: the principal that issued the signature with its access keys has to be able to get the object in the moment of access. If you sign now an URL and then you are denied access via a bucket policy your keys are valid but in that moment you have no access to the object.