aws_ssm_parameter : arn output is incorrect

[awilkins]

Terraform Version

0.11.3

Affected Resource(s)

Please list the resources as a list, for example:

• data : aws_ssm_parameter

Terraform Configuration Files

data "aws_ssm_parameter" "passphrase" {
  name = "/service/gpg/passphrase"
  with_decryption = false // The lambda is fetching it, not this
  // Don't return it decrypted, it will go in the state file!
}

Expected Behavior

ARN should match the same ARN that using e.g. aws-sdk SSM.getParameter() attempts to use.

Actual Behavior

ARN includes an extra slash compared to output from ssm calls

SSM says :

... not authorized to perform: ssm:GetParameter on resource: arn:aws:ssm:eu-west-1:<redacted>:parameter/service/gpg/passphrase

---

Currently trying to get to the bottom of why my lambda function can't do GetParameter here, thought it might be down to the extra slash in the policy document ARN but it's not.

I'm doing a replace() in the TF script to remove it anyway.

[awilkins]

I note that the resource counterpart outputs the ARN without the additional slash.

[bflad]

Hi @awilkins! Sorry you ran into this. Indeed the aws_ssm_parameter data source was returning an extra slash in its arn attribute. We actually have a fix (#3211) that has been recently merged into master and will be included in v1.9.0 of the provider, expected to release at the end of this week. For that reason I'm going to close this ticket. 😄

PS for next time: please provide your AWS provider version as well in your issue reports via terraform version. Terraform was split into core and individual providers each on their own release cycle (we release every ~2 weeks), and if you look in our CHANGELOG we have a lot of enhancements/bug fixes each time so its helpful for the community/maintainers to have a frame of reference when investigating.

[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!