sts PresignGetCallerIdentity - make it simpler to add custom HTTP headers

[rittneje]

Describe the feature

This is a followup to #1137.

It is very common to use a presigned GetCallerIdentity URL as an authentication token. And in these use cases, it is very common to add a custom HTTP header to it, to verify the URL has the right "purpose". For example, Kubernetes uses a presigned URL with the x-k8s-aws-id header set to the cluster name.

Currently, the only way to set a custom header is with a convoluted and unintuitive process shown here:
https://github.com/bluestealth/aws-iam-authenticator/blob/ff550b8c35816a14c256aa064973f6d710334692/pkg/token/token.go#L333-L348

This is in stark contrast to your v1 SDK, which was way simpler:

req, _ := p.stsClient.GetCallerIdentityRequest(&sts.GetCallerIdentityInput{})
for k, v := range header {
    req.HTTPRequest.Header[k] = v
}
presigned, _, err := req.PresignRequest(15 * time.Minute)

Please make setting custom headers a first-class feature of sts.PresignOptions so we don't have to jump through several layers of hoops. At the very least, the v2 SDK docs should explicitly explain how to set custom headers so we don't have to dig it out of closed issues or other library implementations.

Use Case

See above

Proposed Solution

see above

Other Information

No response

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

AWS Go SDK V2 Module Versions Used

n/a

Go version used

n/a

[lucix-aws]

I view this as more of an indictment of middleware than lack of an API for this common use case. Middleware as written is way too generic of an API to be customer-facing, it's a sentiment I've had for some time.

I don't really think a more explicit "add header" API in say the sts namespace (sts.WithHTTPHeader) is any more discoverable, I think the customer experience for request manipulation needs a complete facelift.

The smithy client reference architecture specifies a design for typed "HTTP interceptors" which gives a customer experience MUCH closer to what we had in v1. We plan to implement that on spec but haven't yet created a public issue to track, I'll do so separately in a bit.

Note that if people still think that experience ends up being too generic/obscure, we can explore commonizing some of these things for specific APIs/use cases, but I think doing that right now before fixing the experience in general is just premature.