When adding policy templates to functions one has to refer to the cloudformation documentation to find the correct intrinsic function to fetch the reference desired by the policy.
For example:
DynamoDBCrudPolicy requires a TableName that's exposed through Ref:
{
"DynamoDBCrudPolicy": {
"TableName": {
"Ref": "MyTable"
}
}
}
...but SNSPublishMessagePolicy expects a TopicName that's exposed via GetAtt:
{
"SNSPublishMessagePolicy": {
"TopicName": {
"Fn::GetAtt": [
"MyTopic",
"TopicName"
]
}
}
}
Would it be possible to somehow just provide the logical ID to the resource and let the policy template processor inject the correct intrinsic function for the resource?
Like this:
{
"DynamoDBCrudPolicy": {
"TableName": "MyTable"
}
}
...or maybe:
{
"DynamoDBCrudPolicy": {
"TableLogicalId": "MyTable"
}
}
Here's a video of what I'm trying to achieve. At the moment I'm defaulting the intrinsic function to Ref.
@ljacobsson What a cool issue description! Thank you for reporting this. This is a real issue that SAM could help ease the pain with. The biggest hurdle I see is that in CFN every resource has a non standard way of getting the ARN to it, so we would need to build that mapping. We will add this issue to our prioritization list, +1s will help immensely.
@praneetap
Fwiw, I've published this functionality as a standalone CLI here: https://www.npmjs.com/package/@mhlabs/sam-policies-cli
I've made some manual mapping of which intrisic functions to use.
Most helpful comment
@ljacobsson What a cool issue description! Thank you for reporting this. This is a real issue that SAM could help ease the pain with. The biggest hurdle I see is that in CFN every resource has a non standard way of getting the ARN to it, so we would need to build that mapping. We will add this issue to our prioritization list, +1s will help immensely.