Terraform-provider-aws: AWS OpsWorks ssh_key in app_source keeps re-applying

[hashibot]

_This issue was originally opened by @iroller as hashicorp/terraform#6648. It was migrated here as part of the provider split. The original body of the issue is below._

---

Hi there,

It looks like there's the same issue as https://github.com/hashicorp/terraform/issues/3635 existing in aws_opsworks_application -> app_source -> ssh_key.

Config:

resource "aws_opsworks_application" "app" {
  name        = "application"

  app_source = {
    type     = "git"
...
    ssh_key  = "${file("~/.ssh/private-key")}"
  }

On terraform plan/apply it keeps re-applying the ssh_key even though it's the same.

Also if it's filtered it shouldn't be displayed:

$ terraform plan

~ aws_opsworks_application.app
    app_source.0.ssh_key:  "*****FILTERED*****" => "-----BEGIN RSA PRIVATE KEY--- ... my-private-key-here"

Terraform Version

v0.6.15

Affected Resource(s)

• aws_opsworks_application
• app_source

[salimane]

I would like some idea on how to debug things, basically I want like a way for terraform to tell me why is it trying to recreate the resource

[STRML]

Note that adding to ignore_changes is not a solution, because then Terraform seems to write a blank key.

[ryym]

I gave up using ssh_key. Instead currently I use GitHub token from environment variable.

[xM8WVqaG]

One limitation of the above solution is it only works for short keys (like API tokens). OpsWorks environment variables are limited to 256 characters, see: https://docs.aws.amazon.com/opsworks/latest/APIReference/API_EnvironmentVariable.html

If you attempt to fit a large key in an environment variable Terraform will error with:

* aws_opsworks_application.my_application: ValidationException: Environment: variables contain illegal characters
    status code: 400, request id: $GUID

[wcampos]

Any luck here or recommended workarounds?

[xM8WVqaG]

As a work around in some of our stacks, we uploaded the deployment key to SSM Parameter Store (which is free) and pass in the key name as an environment variable. Then in the deploy recipe we pull the key from SSM PS.

For the stacks without the workaround, in Terraform 11 this problem was a nuisance but as TF 11 only printed the key it wasn't that hard to ignore during the plan/apply.

$ terraform plan

~ aws_opsworks_application.app
    app_source.0.ssh_key:  "*****FILTERED*****" => "-----BEGIN RSA PRIVATE KEY--- ... my-private-key-here"

Now Terraform 12 prints the entire opsworks_application config for every application it's now become really challenging to ignore.

$ terraform plan

 # aws_opsworks_application.my_application will be updated in-place
  ~ resource "aws_opsworks_application" "my_application" {
      <9 lines of configuration>

      ~ app_source {
          + ssh_key = "-----BEGIN RSA PRIVATE KEY-----\nREDACTED\n-----END RSA PRIVATE KEY-----\n"
            type    = "git"
            url     = "REDACTED"
        }

      <91 more lines of configuration>
    }

The diffs have gone from two lines (with a blob of private key) to at least 100 lines (if you have any number of environment variables) with the blob of private key and another blob of TLS certificate if supplied.

[wcampos]

Just reproduced this issue using Terraform v0.11.10

Any workarounds?

[francis-edejer]

Having the same exact issue for Terraform v0.12.3 with provider.aws v2.21.0

Any workaround suggestion is highly appreciated

[hashibot[bot]]

This has been released in version 2.39.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!

[hashibot[bot]]

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!