Terraform-provider-aws: `aws_ssm_parameter` does not support changing type from SecureString => String

Created on 21 Aug 2019  ·  6Comments  ·  Source: hashicorp/terraform-provider-aws

Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
  • Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform Version


Terraform v0.11.13

  • provider.aws v2.7.0

Affected Resource(s)

  • aws_ssm_parameter

Terraform Configuration Files

This is the original TF code that generated the resource to begin with.

# Original Resource Code
resource "aws_ssm_parameter" "my_param" {
  name        = "my_param"
  description = "This is not really a secret."
  type        = "SecureString"
  value       = "SomeValue"
  overwrite   = true
}

The issue comes up when I update that code to be the following:

# Updated Resource Code
resource "aws_ssm_parameter" "my_param" {
  name        = "my_param"
  description = "This is not really a secret."
  type        = "String"
  value       = "SomeValue"
  overwrite   = true
}

The only change is the type.

Debug Output

I'm going to skip the debug output here, unless requested. The root cause is
relatively plain to see, and the incidence of this I'm working with locally
contains secret values.

Panic Output

Expected Behavior


I would expect that the SSM parameter type would be updated to the String type,
as supported by the SSM put-parameter API.

Actual Behavior


The provider forwards along the original key_id value originally set by TF
(alias/aws/ssm by default). However, that value should not be included in the
API request for a String type, only SecureString. So the AWS API complains,
and does not update the parameter.

The result is the error seen here:

* aws_ssm_parameter.my_param: 1 error(s) occurred:

* aws_ssm_parameter.my_param: error creating SSM parameter: ValidationException: KeyId is required for SecureString type parameter only.
    status code: 400, request id: d0b01305-01a9-478e-8e7f-e94cedd27541

Steps to Reproduce

  1. terraform apply of original resource code above.
  2. Update original code to the Updated snippet provided.
  3. terraform apply again.

Important Factoids

I think that the fix for this may be as simple as modifying this conditional:
https://github.com/terraform-providers/terraform-provider-aws/blob/master/aws/resource_aws_ssm_parameter.go#L214

I think it should only set the keyID on the request If, and only If, the Type
on the request is SecureString.

The PutParameter API call does support updating the type from SecureString to
String, but it will always complain if key_id is set in the request but the
type is not SecureString.

References

  • #0000
bug servicssm

Most helpful comment

The fix for this has been merged and will release with version 2.47.0 of the Terraform AWS Provider, Thursday next week. Thanks to @chroju for the implementation. 👍

All 6 comments

Hi. I have created a pull request because I was bothered by the same thing. Thanks.

This also happens when you do specify the key_id originally for the SecureString type.

Faced the same issue, would be happy to have this on board.

The fix for this has been merged and will release with version 2.47.0 of the Terraform AWS Provider, Thursday next week. Thanks to @chroju for the implementation. 👍

This has been released in version 2.47.0 of the Terraform AWS provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template for triage. Thanks!

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!

Was this page helpful?
0 / 5 - 0 ratings