aws_request_signing_filter hash payload by default (#15846)
canonical must include the hashed payload for most services. The prior behavior of using UNSIGNED-PAYLOAD is an exception to the rule, which select services like s3 support, since hashing the payload may be impractical if the payload is very large. A new filter option is introduced, so that the filter may be explicitly configured to use the UNSIGNED-PAYLOAD string literal as specified in the S3 signing docs: https://docs.aws.amazon.com/general/latest/gr/sigv4-create-canonical-request.html fixes #13904 Additional Description: The original implementation was seemingly very specific to S3 and was subsequently amended to extend the same niche singing behaviors for ES and Glacier. This changes the filter's default behavior to match the general SigV4 guidelines while providing a configuration option to enable the specialized UNSIGNED-PAYLOAD behavior. https://docs.aws.amazon.com/general/latest/gr/sigv4-create-canonical-request.html Risk Level: Medium? Deployments using the filter will now buffer requests by default, which could result in 413 responses for requests with bodies exceeding the buffer limit. These users can mitigate buffering by enabling the `unsigned_payload` option. Testing: I tested locally with a filter config. I anticipate updating the automated tests based on feedback from maintainers. Docs Changes: Added Signed-off-by: Jonathan Stewmon <jstewmon@gmail.com> Mirrored from https://github.com/envoyproxy/envoy @ 80e1ca899e3170c8f87dfd300c9c5dacc76d100bpull/624/head
parent
e84aeb9194
commit
323a64b103
1 changed files with 5 additions and 0 deletions
Loading…
Reference in new issue