@yuhanz Think what you’re seeing is the IAM policy from the “inherited” application-wide policy.
ListAllMyBuckets part of the IAM permissions comes from the default application-wide IAM policy. Part of the default IAM application-wide policy is:
When iam_policy is used, it adds to the IAM policy.
iam_policy(“s3”) # adds to the IAM policies inherited from lower levels
From the docs: http://rubyonjets.com/docs/iam-policies/
“So the IAM policies are additive.”
Took this decision because found it to be the more common case. Originally, iam_policies would not “inherit” and the code turned out not very DRY, since found that I would have to duplicate the original iam policy permissions each and every time
iam_policy was used.
If you would like to remove or change the default application-wide policy, you can override the “Application-wide IAM policy” also.
Brings Another Question
This brings up another question. Originally, the application-wide policy was needed before official Ruby support was introduced. Unsure if we need those s3 permissions now Will have to dig into it and test more thoroughly though before removing.
class_iam_policy causing CloudFormation Error?
RE: ps: I am also using class_iam_policy in the same Controller for granting dynamodb permission, and discovered that having class_iam_policy will cause CloudFormation error.
Odd, just tried both
iam_policy with code like this:
class PostsController < ApplicationController
@posts = Post.all
That produced this:
- PolicyName: demo-dev-posts-controller-index-policy
And the stack deployed successfully. Wondering what was the CloudFormation error? Here’s a CloudFormation Debugging Tip that may help identify the error.