Use case description
I spent 2 days trying to figure out why API Gateway was rejecting my resource policy because I had simply pasted it into the provider.resourcePolicy section of my serverless.yml file without thinking.
Example "incorrect" resource policy
provider:
name: aws
resourcePolicy:
{
"Version": "2012-10-17",
"Statement":
[
{
"Effect": "Allow",
"Principal":
{
"AWS":
[
"arn:aws:iam::123456789012:root",
],
},
"Action": "execute-api:Invoke",
"Resource": "execute-api:/*/POST/api/sample",
},
],
}
It turns out that the Serverless Framework helpfully wraps the provided resource policy in the necessary { "Version": "2012-10-17", "Statement": [ ... ] } bits, so API Gateway didn't like the result.
I thought that my policy document was just fine, and in fact it was copied directly from a working one in the console, so it was very difficult to understand until I looked at the generated CloudFormation. Twice, really, because the first time everything looked OK, and it took a re-read to notice the wrapping around my policy.
Generated CloudFormation excerpt
"ApiGatewayRestApi": {
"Type": "AWS::ApiGateway::RestApi",
"Properties": {
"Name": "sample",
"Policy": {
"Version": "2012-10-17",
"Statement": {
"Version": "2012-10-17", <-- THIS IS WHERE THINGS GO BAD
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::123456789012:root"
]
},
"Action": "execute-api:Invoke",
"Resource": "execute-api:/*/POST/api/sample"
}
]
}
}
}
},
Each attempted deploy took 20 minutes and failed with the message Invalid policy document. Please check the policy syntax and ensure that Principals are valid.. Because I'd taken the policy document from a working version in the console, I was stumped for quite a long time.
Proposed solution
It would be super-helpful if the Serverless Framework checked that the provided resourcePolicy value was the right shape (even just checking for Version and Statement attributes or simply checking if the value is an object instead of an array) and failed quickly, or if it didn't add the wrapper if there were already Version and Statement attributes or if the value was an object.
Thoughts? If folks agree with this idea, I'm happy to try implementing a solution.
Use case description
I spent 2 days trying to figure out why API Gateway was rejecting my resource policy because I had simply pasted it into the
provider.resourcePolicysection of myserverless.ymlfile without thinking.Example "incorrect" resource policy
It turns out that the Serverless Framework helpfully wraps the provided resource policy in the necessary
{ "Version": "2012-10-17", "Statement": [ ... ] }bits, so API Gateway didn't like the result.I thought that my policy document was just fine, and in fact it was copied directly from a working one in the console, so it was very difficult to understand until I looked at the generated CloudFormation. Twice, really, because the first time everything looked OK, and it took a re-read to notice the wrapping around my policy.
Generated CloudFormation excerpt
Each attempted deploy took 20 minutes and failed with the message
Invalid policy document. Please check the policy syntax and ensure that Principals are valid.. Because I'd taken the policy document from a working version in the console, I was stumped for quite a long time.Proposed solution
It would be super-helpful if the Serverless Framework checked that the provided
resourcePolicyvalue was the right shape (even just checking forVersionandStatementattributes or simply checking if the value is an object instead of an array) and failed quickly, or if it didn't add the wrapper if there were alreadyVersionandStatementattributes or if the value was an object.Thoughts? If folks agree with this idea, I'm happy to try implementing a solution.