Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[lambda] feat: allows to use YAML instead of JSON for IAM policy #692
[lambda] feat: allows to use YAML instead of JSON for IAM policy #692
Changes from 3 commits
ac1341d
1332ead
ffe20b2
c01a181
e58b512
a3aa15f
72aad7c
b6245bc
159e269
61ede2a
c762aee
c7945d5
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cloud Posse has made a high-level design decision NOT to use YAML for IAM policies. While I would consider a community PR that adds support for YAML, I do not support one that removes support for JSON policies.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah what was the reasoning behind JSON > YAML policies? I'm surprised as sticking with YAML support for policies seems logical since JSON policies inside Stacks feels like we're mixing and matching our formats in an ugly way. It seems inconsistent in the components as there is a JSON policy variable input in the kms component, but the
s3-bucket
component has an policy statements input as a map.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
JSON is the native format of IAM policies: it is what is published in AWS documentation and it is output by Terraform AWS data sources and resources. Practically no one uses YAML for IAM policies.
We have old code that uses old policy modules that takes Terraform objects and converts them to policies, but what that entails is us developing an alternate specification language for policies when we already have to deal with 2: JSON and Terraform. So we are trying to move away from that and instead only specify policies in JSON or Terraform.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's interesting. I also thought exposing the statements to the yaml interface was convenient and handy. I recall a client doing that and another client asking for it which led to creating a generic interface for https://github.com/cloudposse/terraform-aws-iam-policy in order to expose policy statements as a generic any map.
In ref to maybe old code (in addition to matts references), we currently have some components that expose iam policy statements as an input that can be fed via yaml.
https://github.com/cloudposse/terraform-aws-components/tree/main/modules/ecs-service#input_iam_policy_statements
There may be other components too
https://github.com/search?q=repo%3Acloudposse%2Fterraform-aws-components%20iam_policy_statements&type=code
I think the efs controller has a recent addition to its iam policy statement resource file too
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Nuru I've added back JSON policy support, so it's possible to set one of them. Please review if that fits better the community best practices. Thank you!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think @gberenice's support for both looks good, but I question if we want to do that. I would double down on wanting to use YAML > JSON in components. All good if that is not what Cloud Posse wants to support, but I'd reiterate that it just feels wrong to be using JSON blocks within our YAML when the two are so portable between one another and whenever we're including custom policies inside Atmos Stack YAMLs, we're doing so because they require customization from standard AWS IAM Policies 90% of the time (otherwise, they'd likely just be built into the component).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tend to agree with @Gowiem on this. If we're already supporting IAM policies as a JSON input, I can understand wanting YAML for consistency.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It should be noted that as implemented (lists), it doesn't support the finer points of atmos's ability to deepmerge. I understand why - since the interface was copied from how it already works in JSON. Just point it out, as a consideration.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nitrocode Note that if someone wanted to use terraform-aws-iam-policy to take the YAML input and generate a policy, the way to do that with the current version of this module is to take the JSON output of
terraform-aws-iam-policy
and feed it intopolicy_json
input.@osterman I am opposed to creating a third parallel syntax (YAML) for IAM policies, but if we are going to do it, I would prefer that we standardize on using
terraform-aws-iam-policy
and make it full-featured, so that everywhere we allow it, it has the same interface, and we do not need to invest energy reinventing it.Regarding the input being a list and not allowing deep merging, I am not as concerned, because the downside of deep merging is that it is difficult (impossible?) to delete an inherited value.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Nuru I've utilized terraform-aws-iam-policy in my recent changes. That also allows us to avoid creating the excessive (in this case)
aws_iam_policy
resource. Please let me know your thoughts.