In this short article, I'd like to share some insights I gained from a recent issue involving the combination of Lambda Function URLs, IAM authoriz...
For further actions, you may consider blocking this person and/or reporting abuse
Amazing high quality article, as always. 🙌
If you want a custom domain in front of an IAM auth furl, probably the best place to do your sigv4 signing is using a Lambda@Edge origin request function. Calculating the signature on the client based on the lambda url also works. It's unlikely the Lambda team will also support the X-Forwarded-Host header, without configuration knowing about the custom domain.
Is there something you are trying to gain with IAM auth? The timeout with CloudFront can be 60 seconds without a limit increase, so it's only 2X APIG.
Another option to secure your furl is to set your auth to NONE but check for a shared secret header value in your furl code and set that header on requests to the origin in CloudFront. It's less secure than IAM auth, and requests get into your lambda code before they are rejected, but depending on your use case it may work.
Signing the request on Lambda@Edge only ensures that the Lambda function is only callable from the CloudFront and not directly via its Function URL. But it doesn't address the authorization problem.
I actually hope they will, CloudFront already sets a few other
x-forwarded-*headers. I don't know if the Lambda team will add support for it, but it would be an easy fix to get IAM auth to Lambda through CF working.I think double the timeout is already a good bargain :-)
Lambda Function URLs only support IAM auth, so there's no alternative to it. I'd like to avoid custom auth options, because, as you said, tehy are less secure and will invoke the Lambda on every (unauthorized) call.