Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Container apps key vault secret ignore_changes not recognised #25727

Open
1 task done
jordanhavard opened this issue Apr 23, 2024 · 6 comments
Open
1 task done

Container apps key vault secret ignore_changes not recognised #25727

jordanhavard opened this issue Apr 23, 2024 · 6 comments

Comments

@jordanhavard
Copy link

Is there an existing issue for this?

  • I have searched the existing issues

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 and review the contribution guide to help.

Terraform Version

1.5.7

AzureRM Provider Version

3.100

Affected Resource(s)/Data Source(s)

azurerm_container_app

Terraform Configuration Files

Adding the following secret block to a standard container apps block

secret {
    name  = "password"
    identity = var.container-apps-identity-id
    key_vault_secret_id = "https://kv.vault.azure.net/secrets/password"
    ignore_changes = true
    value = ""
  }


### Debug Output/Panic Output

```shell
╷
│ Error: Unsupported argument
│ 
│   on module/container/env_staging.tf line 186, in resource "azurerm_container_app" "oct-staging-auth":
│  186:     ignore_changes = true
│ 
│ An argument named "ignore_changes" is not expected here.
╵

Expected Behaviour

When running terraform plan no updates / changes are made to this block

Actual Behaviour

Unable to run terraform plan.
Removing ignore_changes results in terraform advising an update to this block is expected

Steps to Reproduce

Run terraform plan -out tfplan.plan

Important Factoids

no

References

Docs: https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/container_app#secret

@jordanhavard jordanhavard changed the title Container apps key vault secret keeps updatingduring plan phase Container apps key vault secret ignore_changes not recognised Apr 23, 2024
@ASHR4
Copy link
Contributor

ASHR4 commented Apr 24, 2024

Hi @jordanhavard,

This is correct as you're supplying that argument as if it's a part of the resource scheme, which it's not.

If you wish to ignore the changes then wrap it in a lifecycle block as per the docs

resource "azurerm_container_app" "oct-staging-auth" {
  ...
    secret {
        name  = "password"
        identity = var.container-apps-identity-id
        key_vault_secret_id = "https://kv.vault.azure.net/secrets/password"
        value = ""
    } 

    lifecycle {
        ignore_changes = [ secret ]
    }
}

@mmillican
Copy link

I am running into this issue as well and the docs are definitely confusing/contradictory.

Ignoring all secret blocks is not reasonable, because what happens when you need to add a new secret to the container?

  • If you remove the ignore_changes = [ secret ] it will think that the existing secrets are being modified, which they are not. Further, I am afraid this will cause an error when trying to execute since per the provider docs, you can't actually remove a secret (which baffles my mind, but that's a separate discussion)
  • If you leave the ignore_changes = [ secret ] in place, it will not see that there are new secrets to be added, which is to be expected.

When attempting to do something like the following, it complains that the blocks cannot be addressed and recommends using a for loop, but that also throws an error because its not a static list.

lifecycle {
  ignore_changes = [
    secret[0].value
  ]
}

@jordanhavard
Copy link
Author

jordanhavard commented Apr 24, 2024

Hi @jordanhavard,

This is correct as you're supplying that argument as if it's a part of the resource scheme, which it's not.

If you wish to ignore the changes then wrap it in a lifecycle block as per the docs

resource "azurerm_container_app" "oct-staging-auth" {
  ...
    secret {
        name  = "password"
        identity = var.container-apps-identity-id
        key_vault_secret_id = "https://kv.vault.azure.net/secrets/password"
        value = ""
    } 

    lifecycle {
        ignore_changes = [ secret ]
    }
}

Hey @ASHR4

Can you advise how we should best use this case when setting up a resource and adding a new secret?

Something like @mmillican mentioned below would be nice too as then the key_vault_secret_id could still be updated if using versioned secrets.

lifecycle {
  ignore_changes = [
    secret[0].value
  ]
}

@lonegunmanb
Copy link
Contributor

According to the schema, the secret is a set so we cannot use secret[0] to access it.

I have a question to @jordanhavard:

secret {
    name  = "password"
    identity = var.container-apps-identity-id
    key_vault_secret_id = "https://kv.vault.azure.net/secrets/password"
    ignore_changes = true
    value = ""
  }

It looks like your real password is stored in the key vault, and you've referenced this secret via a versionless id, why you want to ignore change on this password? If you'd like to change the password you can upgrade the secret in your Key Vault, the secret id could stay unchanged.

@jordanhavard
Copy link
Author

It looks like your real password is stored in the key vault, and you've referenced this secret via a versionless id, why you want to ignore change on this password? If you'd like to change the password you can upgrade the secret in your Key Vault, the secret id could stay unchanged.

@lonegunmanb Even when doing this, during the plan phase, its mentioned that a change will be made however like you mentioned, this is a versionless id so I was confused as to why this was happening in the first place

@lonegunmanb
Copy link
Contributor

@jordanhavard Could you please share us a minimum example code that could reproduce your issue? Once we can reproduce the issue on our side we can try to solve it. Thanks in advance!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants