Terraform Update RDS Proxy without Deleting Existing Secrets

Terraform Providers AWS
1

Terraform v1.1.4. I am using it to provision Aurora Postgres SQL. I am also provisioning an RDS Proxy using Terraform. As part of RDS Proxy, I am also creating a secret. After this, another application also creates some secrets and associates with this proxy. Recently, I had to update a setting in the Proxy. When I ran a TF apply, it reapplied all the settings and the secrets created by the other application got wiped out. Is it possible to update RDS proxy using TF without touching secrets? Rather, is it possible to TF apply without touching authentication information like secrets?

2

Terraform will only touch resources that are managed by it. If you are managing the secret within your TF code, then it will attempt to reconcile it.

Can you provide the relevant parts of your code?

3 
resource "aws_secretsmanager_secret" "superuser" {
  name        = var.secret_name 
  description = "Secret for DB Cluster credentials"
  kms_key_id  = data.aws_kms_key.kms_key_id_alias.id

  tags = var.tags
}

resource "aws_secretsmanager_secret_version" "superuser" {
  secret_id = aws_secretsmanager_secret.superuser.id
  secret_string = jsonencode(var.secret_string)
}

Does this help? This is the piece of code inside the RDS Proxy TF file.

4

Are those different secrets or different versions of the same secret?

If Terraform didn’t know about the existence of the other secrets, it also wouldn’t know how to wipe them out.

Perhaps you can illustrate what happened by using examples like:

  • Terraform created secret A
  • App X created secret B
  • Terraform erased secret A and B
  • B is referenced in Terraform code here and here…

Do you have the output of the Terraform plan that shows secrets being destroyed?

Maybe also add the bit that contains the proxy resource.

5

First of all, thanks a lot for the prompt response. Let me explain.
Terraform created secret A
AppX created secret B
Terraform erased secret A & B
B is not there anywhere in Terraform code

When I ran a TF plan, it showed that it will destroy A & B. I will check with customer and share more code accordingly. Please apologize.

6 
 - auth {
          - auth_scheme               = "SECRETS" -> null
          - client_password_auth_type = "POSTGRES_SCRAM_SHA_256" -> null
          - iam_auth                  = "REQUIRED" -> null
          - secret_arn                = "arn:aws:secretsmanager:us-east-1:<my-acct-id>:secret:dev-lab/rds/postgres/01/myApp_rds_rw_user-nv41Tv" -> null
        }
      - auth {
          - auth_scheme               = "SECRETS" -> null
          - client_password_auth_type = "POSTGRES_SCRAM_SHA_256" -> null
          - iam_auth                  = "REQUIRED" -> null
          - secret_arn                = "arn:aws:secretsmanager:us-east-1:<my-acct-id>:secret:dev-lab/rds/postgres/01/myApp_rds_ro_user-nayvhn" -> null
        }
     
        # (1 unchanged block hidden)
    }

The above is the output from TF plan. As you can see, it is trying to delete the secrets which are created by the App. Does this help?

7

That doesn’t look like a secret resource.
That looks like an auth block of a different resource that references the secret. If those blocks are changed outside Terraform, it will definitely try to correct the drift.

8

Sorry for the confusion. Yes, it is listed under Auth block. But it is referenced inside the same proxy and TF says it will delete it. Is there a way to avoid it?

9

Is it possible to exclude modifying Auth block? Please advise.

10

You’d need something similar to ignore_changes for blocks instead of attributes but I don’t think that exists.

1 Like
11

The problem is that you are trying to manage a resource that Terraform controls from elsewhere, so Terraform will try to change that.

The two options are, either to stop managing that from Terraform - some providers allow for multiple different ways to manage a resource to reduce the scope of what is or isn’t managed, but I don’t know if that is possible in this case (or could be requested as a new feature of the provider).

Alternatively you could manage those passwords from within Terraform instead of the other process you are using.

12

Thank you @macmiranda and @stuart-c. Let me also check with my customer.

13

Didn’t get you. ignore_changes won’t work in my case? Can you please explain a little more?

14

No, it won’t because the thing that you want to ignore isn’t an attribute. It’s a block.

15

I tried with the following block inside my aws_db_proxy resource. Looks like it is working. However, I am testing once again.

lifecycle {
       ignore_changes = [
         auth,
      ]
     }
16

Didn’t expect that to be true solely relying on what the documentation says.

17

Yes @macmiranda. It seems to be working fine. Thanks a lot for your help.