Open CpuID opened 5 years ago
anyone encounter this issue as well? I thought the signing key is suppose to last for a week
It's also possible users will need to follow this workaround for "dynamic upstreams", https://tenzer.dk/nginx-with-dynamic-upstreams/ - still waiting to see if it yields the results I expect or not but promising so far.
@CpuID can u explain more about your solution or provide with an example conf?
thanks
@melkayam92 https://tenzer.dk/nginx-with-dynamic-upstreams/ Ctrl+f "The free alternative". Basically change the proxy_pass
to that. Article explains the rationale, tl;dr - nginx DNS resolution doesn't honor TTLs by default.
I can confirm I haven't been able to repro the issues I had since doing this.
@CpuID thanks, so basically u regenerate key every day + the dynamic upstreams?
But I still don't understand wats the DNS resolution has to do with key expire issue?
@melkayam92 yep got a crontab on midnight UTC currently to rotate it, plus dynamic upstreams.
Unconfirmed, but a theory I had is maybe AWS cycle out the S3 backend instances at midnight UTC instead of rotating the keys on the existing instances... 🤷♂ :)
Damn, my crontab alone didn't seem to resolve this entirely, managed to get the The authorization header is malformed; Invalid credential date. Date is not the same as X-Amz-Date.
error again.
In https://github.com/anomalizer/ngx_aws_auth#security-considerations
In my experience, they are valid for the date of signing key generation only, as they are date specific.
If you attempt to use a signing key generated on the day before, you will get a
400 Bad Request
from S3 due to:Verified over 2 days, in a container with a UTC timezone. Making requests against nginx right after midnight UTC fail, re-running
generate_signing_key
(well, my ported variant of it, identical in nature with test coverage) and reloading nginx allows successful requests to occur again.Should the README be adjusted...?