-
Notifications
You must be signed in to change notification settings - Fork 144
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Signing Key Expire within a day #70
Comments
I've got the same issue, haven't resolved it yet. |
@qdchong can you try implement something looking like https://tenzer.dk/nginx-with-dynamic-upstreams/ in your configs and see if it yields a difference for you? I did it about 2 days ago, so far rolled over UTC twice and haven't had an issue. Not sure if this is what did the job or not, but potentially... |
Hmm wow i shall try it. I was looking at what other options r there. Thanks so much |
I ended up getting the |
Hello :) The README of this module is wrong. So, even if "It is an insecure practise to let the secret key reside on your nginx server.", we are all forced to have a cronned script at midnight exactly that regenerates the nginx configuration. In fact, the module SHOULD generates the signing key since the promise of security is not possible. I'm a bit disapointed by the date validation in the signature v4 protocol :( |
I've got a proposed solution to this that uses temporary credentials and a python script that will regenerate a new signature upon expiration. It's limited by how often it gets run by cron (minutely), but you might be able to have it run continuously and check for expiration ahead of time. I've also thought about using lua for something a bit more robust that doesn't require a hot reload. See the PR #74 |
I wonder if we convert the python code to C++ and include it in the module. It could update the config struct in a lazy fashion. The date found in the key scope should be checked against the current date and if different update the struct with new key scope and signing key. The single requests around midnight UTC will run a little slower but subsequent requests will have normal performance. |
I'm currently working on a solution - my C is pretty rusty - I should really write some unit tests for it. Will post back once ive tested it in my pre-prod environment. |
I have produced a forked version which calculates the signing key when the date changes. It subsequently caches the signing key and key scope in the configuration. It does break the best practices of keeping the secret key off the nginx server. I have simplified the nginx configuration to that similar to AWS2 config found in earlier versions. It still uses AWS4 for the signing method so no change there. Not sure how you would do it otherwise as at 23:59:59:999 a request could be in flight and reach Amazon the following day at 00:00:00:000. Amazon would then deem the request erroneous by AWS as there would be a discrepancy between the header date, the signing key and key scope. I have added some unit tests to test the new functionality. By all means take from it what you wish. I agree with the original author intent of keeping the keys off the box, but couldn't see a way round it without over complicating the hack. Fork here >> https://github.com/hexmarkrecords/ngx_aws_auth If you would like to provide a better solution, poke holes, please chime in. |
I have tested it the following day and my assets still load: All dynamic assets are now served from S3 without expiry .... Yay |
@hexmarkrecords Trying to use your fork, as I couldn't get the original here to work at all. Says "unknown direct aws_service" when using your example nginx.conf. Tried taking this out and get returned a 403 with "The request signature we calculated does not match the signature you provided" using following code
|
I have something like this:
And that worked for me bud. Ive just copied it from my config that is in production. Hopefully that should help you. |
i'm gonna look in to the aws_service param as that should be work also. It defaults to 's3' anyway. |
Spotted an issue with the service parameter so i will fix that - but in the mean time it defaults to 's3'. Thanks for letting me know @leffuy |
pushed to master and created new tag 2.2.2 - fixed missing service optional parameter |
Hello @hexmarkrecords i am trying to compile this with nginx-1.19.0 with --add-module=/home/admin/building/ngx_aws_auth-2.2.2, but when i run make this is what i get
Kindly help |
I can take a look over the weekend. |
Hi @mwangaben I have now updated the branch (2.3.0 and master) to build a dynamic module exporting it to /private/tmp on the host machine when using docker. It now works with Open SSL 1.1.1 and therefore compatible with Nginx 1.19.1. Hope it helps you out. |
I wonder if I should try to turn this into a proper pull request for the main repos instead of on a fork? |
i encountered the error
AuthorizationHeaderMalformed
The authorization header is malformed; Invalid credential date. Date is not the same as X-Amz-Date.... after a day.I thought the signing key was suppose to last for a week. can anyone help? How do i set the X-Amz-Date? Or do i need to set the amz-expire field??
The text was updated successfully, but these errors were encountered: