New Data Source: aws_iam_policy

[darkowlzz]

fixes #1346

[trung]

I would define as Required: true instead

[bflad]

@darkowlzz this data source is a great contribution; I certainly know I have been looking for it a few times. I'm hoping you or others will enhance it in the future so it can lookup AWS provided policies by name to fetch their ARN. 😄

This just does need the one change mentioned by @trung about making arn required instead of optional since in its current form that's the only lookup available. I'll get that really simple change in a commit after your commits and merge. Thanks again.

make testacc TEST=./aws TESTARGS='-run=TestAccAWSDataSourceIAMPolicy_basic'
==> Checking that code complies with gofmt requirements...
TF_ACC=1 go test ./aws -v -run=TestAccAWSDataSourceIAMPolicy_basic -timeout 120m
=== RUN   TestAccAWSDataSourceIAMPolicy_basic
--- PASS: TestAccAWSDataSourceIAMPolicy_basic (11.67s)
PASS
ok  	github.com/terraform-providers/terraform-provider-aws/aws	11.715s

[bflad]

This has been released in terraform-provider-aws version 1.9.0. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

[chris-weck]

Hi @bflad,
I´ve upgraded the tf provider to 1.10.0.
When I try this:

data "aws_iam_policy" "AdministratorAccess" {
arn = "arn:aws:iam::aws:policy/AdministratorAccess"
}
output "policy" {
value = "${aws_iam_policy.AdministratorAccess.arn}"
}
I will receive this error:

Error: output 'policy': unknown resource 'aws_iam_policy.AdministratorAccess' referenced in variable aws_iam_policy.AdministratorAccess.arn

[bflad]

@chris-weck for Terraform data sources you need to prepend data. to the front of your interpolation:

output "policy" {
  value = "${data.aws_iam_policy.AdministratorAccess.arn}"
}

Documentation:

Each data instance will export one or more attributes, which can be interpolated into other resources using variables of the form data.TYPE.NAME.ATTR.

[chris-weck]

Oh, many thanks. I´m new with terraform. It´s working now :)

[TBeijen]

Quoting @bflad:

I'm hoping you or others will enhance it in the future so it can lookup AWS provided policies by name to fetch their ARN.

Ran into this and was surprised it requires an arn as a lot of similar data sources (e.g. aws_iam_user, aws_iam_role) operate based on name instead of arn.

This looks like a nice thing to pick up and get my feet wet on contributing to Terraform.

What would be a good pattern to follow? As arn is already an argument, the situation of a user (inadvertedly) providing both arn and name should be handled. This could be:

1. Raise error, only one should be specified.
2. Use arn, ignore name
3. Use arn, raise error if resulting resource name doesn't match given name.

First seems best imo. Opinions?

[bflad]

@TBeijen its probably fine to raise an error for now. You can cross-add ConflictsWith: []string{"arn"}, to the new name attribute and ConflictsWith: []string{"name"}, to the existing arn attribute to have Terraform automatically error if both are specified.

[tomelliff]

@TBeijen are you still wanting to pick this up? I was just looking at this data source as I currently build the ARN of our managed policies and it would be nicer if we could just refer to it by name.

Also I would probably go with your third option where any combination of things can be specified but they still have to return exactly one result. So something like this should be fine:

data "aws_iam_policy" "AdministratorAccess" {
  arn  = "arn:aws:iam::aws:policy/AdministratorAccess"
  name = "AdministratorAccess"
  path = "policy"
}

But this would fail:

data "aws_iam_policy" "AdministratorAccess" {
  arn  = "arn:aws:iam::aws:policy/AdministratorAccess"
  name = "ReadOnlyAccess"
  path = "policy"
}

It would also be good to export/consume the account ID (also allowing for the magic aws account ID for AWS managed policies).

[TBeijen]

Hi @tomelliff,
Was ambitiously planning to but so far life/work got in the way so no progress whatsoever.

Feel free to pick this up, no risk of efforts crossing.

Btw, I would surely consider approach 1 from my previous comment, unless ofc. you have a use case that would require specifying both arn and name.
As mentioned by @bflad, option 1 can be handled by constructs like ConflictsWith in a declarative manner. Besides that, If I would do a code review that specifies both name and arn (which are consistent) there would be that bit of cognitive overhead when trying to grasp why there's seemingly redundant data.

[tomelliff]

I don't have an urgent need for it (just cleans up some code) so if you think you'd be able to look at it in the next month or so and did want to get your feet wet then I'll leave it for you.

If not then I'll think about picking this up when I get some free time later this week.

[saravanan30erd]

@TBeijen @tomelliff any update in this?

[TBeijen]

Was ambitiously planning to but so far life/work got in the way so no progress whatsoever.
Feel free to pick this up, no risk of efforts crossing.

@saravanan30erd Above is still 100% accurate, so no progress from my part.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!