Skip to content
By using AWS re:Post, you agree to the AWS re:Post Terms of Use
AWS re:Postre:Post
About re:Post

Restrict API Gateway HTTP API access through CloudFront

0

I want to restrict API Gateway HTTP API access through CloudFront. I was looking at this blog post. Blog post recommendeds 3 approaches.

  1. CloudFront can insert the X-API-Key header before it forwards the request to API Gateway, and API Gateway validates the API key when receiving the requests.
  2. CloudFront can insert a custom header (not X-API-Key) with a known secret that is shared with API Gateway. An AWS Lambda custom request authorizer that is configured in API Gateway validates the secret.
  3. CloudFront can sign the request with AWS Signature Version 4 by using Lambda@Edge before it sends the request to API Gateway. Configured AWS Identity and Access Management (IAM) authorization in API Gateway validates the signature and verifies the identity of the requester.

Approach 1 is only applicable to customers who are using REST API endpoints.

Approach 2 there is an operational overhead for managing keys and rotating the keys periodically.

Approach 3 looks best choice but I also want to validate JWT token sent with each API call. So, using approach 3 can we do both IAM authorization to make sure requests are coming from CloudFront only and also use JWT authorizer or custom authorizer for OAuth token validation?

If this is not possible, then approach 2 is the best choice for this use case? I can do both secrect validation and OAuth token validation in Lambda custom authorizer.

Topics
Front-End Web & MobileNetworking & Content Delivery
Tags
Amazon API GatewayAmazon CloudFront
Language
English

asked 2 years ago3.3K views

1 Answer
2

If it were me, I'd use option 2 because it's pretty simple and it just works.

Why do you think there is operational overhead? (Yes, I'm aware I'm disagreeing with the authors of the blog post.)

Why does the secret need to be periodically rotated? If it's only known to CloudFront and APi Gateway; if it's long and random why does it need to be changed? This is a question only you and your security/risk management team can answer but (again, if it were me) I see this as a very small risk. Given that traffic from CloudFront to APi Gateway is encrypted the only realistic way it can be discovered is by someone looking at the configuration or the source code.

If it was a concern, I'd have some sort of automation to rotate the secret - noting that you'd need to do it at the exactly same time; or have the Lambda authorizer keep track of the previous key for a specified period of time. Once the code is written and running, the operational overhead is zero (or very close to it).

EXPERT

answered 2 years ago

EXPERT

reviewed 2 years ago

  • Ravi Teja
    2 years ago

    Thank you for your answer. Can you confirm approach 3 does not support my use case to do both secret & OAuth token validation?

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Relevant content