sec(iac): require AWS_IAM auth on production Lambda Function URL (closes #424)#885
sec(iac): require AWS_IAM auth on production Lambda Function URL (closes #424)#885cristim wants to merge 1 commit into
Conversation
#424) Set enable_cdn = true in github-prod.tfvars and github-staging.tfvars. The compute.tf local derives lambda_function_url_auth_type = "AWS_IAM" when enable_cdn = true, so these two tfvars changes are the single lever that activates the full security chain: CloudFront OAC (frontend module) -> SigV4-signed request -> Lambda Function URL (authorization_type = AWS_IAM) -> aws_lambda_permission.function_url_cloudfront (principal = cloudfront.amazonaws.com, source_arn = distribution ARN) The dev environment retains enable_cdn = false (NONE auth) because the browser-served SPA hits the Lambda URL directly and cannot SigV4-sign. Auth in dev is enforced at the application layer (login session, CSRF, API keys) as documented in compute.tf. Prod and staging lambda_allowed_origins still carry .invalid placeholders (the envs are not yet deployed); any accidental terraform apply will fail fast at hostname resolution until the operator supplies real origins.
|
Warning Review limit reached
More reviews will be available in 37 minutes and 17 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
Summary
enable_cdn = trueingithub-prod.tfvarsandgithub-staging.tfvars, which activates the full AWS_IAM auth chain for the Lambda Function URL in production and staging environments.compute.tflocallambda_function_url_auth_typeis derived fromenable_cdn, so this single lever closes the exposure described in sec(iac): production Lambda Function URL uses authorization_type=NONE — no IAM gate #424 without touching any module logic.enable_cdn = false(auth_type = NONE) because the browser-served SPA hits the Lambda URL directly and cannot SigV4-sign.Auth chain (prod/staging with enable_cdn = true)
The Function URL rejects every request not SigV4-signed by the OAC-bearing distribution. Direct hits to the Function URL hostname return HTTP 403, even for requests with valid application-layer credentials.
The OAC resource, the CloudFront permission, and the derived auth-type local were all introduced in the base branch (
feat/multicloud-web-frontend) as part of the preparatory refactor. This PR activates the mechanism for prod and staging by flippingenable_cdn = true.Rollout notes
lambda_allowed_originsstill carry.invalidplaceholder origins). Any accidentalterraform applywill fail fast at hostname resolution until the operator sets real origins and custom domain names.lambda_allowed_originsto the CloudFront distribution domain (or custom domain if configured) before applying.Test plan
terraform fmt -checkpasses on changed files (CI)tflintpasses onterraform/environments/aws/(CI)locals.lambda_function_url_auth_type = "AWS_IAM"for prod/staging plan output afterenable_cdn = trueaws_lambda_permission.function_url_cloudfront[0]is created (count = 1) in planaws_lambda_permission.function_url[0](principal = "*") is NOT created in plan (count = 0 when auth_type = AWS_IAM)Closes #424