Terraform Ephemeral resource with azuread_application_password

[bwrogo]

Community Note

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

Description

Now that Terraform 1.10 supports ephemeral resources, could the team consider updating the azuread_application_password resource to support this?

This would improve the management of application registration secrets.

Thank you for your attention to this matter.

New or Affected Resource(s)

• azuread_application_password

Potential Terraform Configuration

• Basic Config:

ephemeral "azuread_application_password" "example" {
  application_id = azuread_application_registration.example.id
}

• With Rotation:

resource "azuread_application_registration" "example" {
  display_name = "example"
}

resource "time_rotating" "example" {
  rotation_days = 7
}

ephemeral "azuread_application_password" "example" {
  application_id = azuread_application_registration.example.id
  rotate_when_changed = {
    rotation = time_rotating.example.id
  }
}

[jkroepke]

I looked into this and identity that this provider still depends on the old Terraform SDK v2 which does not support any ephemeral features. A migration to the new Terraform Framework is manatory first.

[nfrappart]

I did a little digging to understand your statement about Terraform SDK v2 not supporting ephemeral features. As I understand it, HashiCorp has stopped development of this SDK and the new plugin development platform is Terraform Plugin Framework. Is there a roadmap to moving to the Plugin Framework?
I'm not a golang developer (not a developer at all tbf), so I have no idea the level of effort required to move to the new framework. What I can say though is that having entra secrets not in state is probably one of the most wanted thing I want to improve security posture. So I'm crossing fingers here and rooting for, and thanking anyone involved in that task!

[sreallymatt]

Hi @bwrogo, @jkroepke

I'm hoping to get a better understanding of what you're looking for here, an ephemeral resource is generally used to retrieve a secret value from an existing remote object which can then be used in other write-only fields without being persisted to state. The API does not return the password (i.e. the secretText field) except during the initial POST request that creates it, so we'd have no way to retrieve the value of an existing secret.

The only way I can see of potentially making this work, is to generate a new application password on each open operation of the ephemeral resource and then leaving behind the secret object. This could lead to a mess of unmanaged secrets, and I don't think this is a great idea. (Would have to discuss this internally before we could even consider doing something like this, personally I'd be opposed to it.)

Curious to hear your thoughts on this.

[nfrappart]

(...) an ephemeral resource is generally used to retrieve a secret value from an existing remote object which can then be used in other write-only fields without being persisted to state.

Well not necessarily. While it is exactly what you decscribe with azurerm provider, in the case of a keyvault secret or cert, when using random or tls providers, there are ephemeral resources, like random_password that generates value at creation (similar to initial POST?), then not persist them in state.
We then use them the same way you describe, in other write-only fields.
I assume it is slightly different because random is a logical provider, working with terraform's internals, not with remote API.

The only way I can see of potentially making this work, is to generate a new application password on each open operation of the ephemeral resource and then leaving behind the secret object. This could lead to a mess of unmanaged secrets, and I don't think this is a great idea. (Would have to discuss this internally before we could even consider doing something like this, personally I'd be opposed to it.)

Strongly agree here, I would not want this either.
Again, I'm not much help, not being a developer, I can only points you to random_password and tls_private_key examples, hoping they can be useful.
Maybe the vault_database_secret is a better example as the secret is in the payload received from vault API. It's likely closer to the behaviour

[sreallymatt]

Hi @nfrappart, thanks for the response! You're right that there are certain ephemeral resources that do in fact generate a value, however the issue here is that we actually need the secret object to exist in Azure.

If Azure provided a way to retrieve the secretText value of an existing password then this wouldn't be too much of an issue (well, besides implementing framework support in this provider). Unfortunately, since we can't retrieve said value, I don't think this will be possible.

That said, I'll leave this issue open for now, open to suggestions!

[gp-cps]

Hi @sreallymatt
This is a good explanation on why the password object cannot be ephemeral.

I was thinking of a similar, but different approach that could work.

Instead of ephemeral object (or just for a few properties of said object), we have a new type of object/property named: readonly

The idea is that a readonly property (ending in _ro) can only be read during creating of object (in Terraform we already keep track of lifecycle) and this property will not be included in any other operations. Then it is mandatory for this type of property (which is inherently ephemeral) to be connected to a writeonly property.

Effectively this would bypass Terraform state management for this property and result in one-time operation of moving the data from one object to another object without being tracked.

[sreallymatt]

@gp-cps unfortunately this isn't possible because for a resource to reference a value from another resource it must either be tracked in state, or the referenced value must be retrieved using an ephemeral resource (not stored in state, but must be retrievable via an API)

Terraform has no concept of a readonly (readonce may be a better description) property in the way you're describing, the closest thing is an ephemeral resource which doesn't work in this scenario

[git-Maxim]

In case someone else stumbles across this, this is how I managed to create secrets and store them in Key Vaults, without saving the secret values in the Terraform state:

locals {
  expiration_date = timeadd(timestamp(), "${24*var.client_secret_ttl_in_days}h")
}

# optional block to create a new secret if the display name changes
resource "null_resource" "new_name_rotation_trigger" {
  triggers = {
    new_name = var.client_secret_display_name
  }
}

# this rotation resource prevents the creation of new secrets, if the remaining expiration time is bigger than 30 days
resource "time_rotating" "rotation" {
  rotation_days = max(var.client_secret_ttl_in_days - 30, 1)

  lifecycle {
    replace_triggered_by = [
      null_resource.new_name_rotation_trigger
    ]
  }
}

# this block creates a new secret and stores it in a key vault as a new version
resource "null_resource" "create_and_store_client_secret" {
  triggers = {
    rotation = time_rotating.rotation.id
  }

  provisioner "local-exec" {
    command = join(" ", [
      "az ad app credential reset",
      "--id", "'${var.ad_app.id}'", # make sure that you remove the "/applications/" substring from the id
      "--display-name", "'${var.client_secret_display_name}'",
      "--append",
      "--query password",
      "-o tsv",
      "|",
      "xargs -I {}",
      "az keyvault secret set",
      "--vault-name", "'${var.kv_name}'",
      "--name", "'${var.client_secret_display_name}'",
      "--value", "'{}'",
      "--expires", "'${local.expiration_date}'"
    ])

    interpreter = ["bash", "-c"]
  }
}

This way you can append new secrets 30 days before they expire to the ad app and the key vault. So you will have an intersection of 30 days in which both your old and new secret will be valid.

The downside of this approach is that your secrets will not really be managed by Terraform, so if you change something in your configuration, you will create new secrets, but not destroy old ones.

I am using it that way, because I am managing a bunch of Service Principals and Key Vaults which I inject as dependencies with Terragrunt, so the integration into my resources is quite nice and i dont have to manage the dependencies in an additional file.

[lennartskogmo]

Seems like this could be made to work if azuread_application_password / azuread_service_principal_password had a value_wo attribute similar to azurerm_key_vault_secret.

Then another ephemeral resource like random_password could generate the value while the two azuread resources would only set the password and then forget it and never store it in state.

The same ephemeral resource could then be used to store the actual password into a keyvault secret using the value_wo attribute at the same time so even though its not in the state, its still not lost.

This is just speculation though. I'm just a user and have no knowledge about the internal limitations.

Also I guess its not that different from the OP's suggestion, except it will still use a standard resource, just with a new attribute.

[sreallymatt]

Hi @lennartskogmo - Unfortunately a write-only argument for the value isn't possible as the API doesn't allow specifying it. The API generates a value on creation, this value is only returned once in response to that request and is not retrievable afterwards.

[lennartskogmo]

@sreallymatt Ok thanks for looking into it 😃

I suppose a ephemeral resource that just keeps asking for a new secret every time it runs or is up for rotating, would be the only way it could work then, except it wasn't possible to support ephemeral resources currently 😄

Too bad 🥲

[pmjansson]

@gp-cps unfortunately this isn't possible because for a resource to reference a value from another resource it must either be tracked in state, or the referenced value must be retrieved using an ephemeral resource (not stored in state, but must be retrievable via an API)

In our case, we have stakeholders who care about secrets being stored unencrypted. I'd been thinking that an ephemeral resource was the right answer, but, reading this thread, I understand why it's not the right answer.

But...does your comment mean that, since the value cannot be retrieved on subsequent API calls, does that mean that the value isn't actually persisted in the terraform state?

(Someone suggested using the msgraph provider, however it won't work for us, because we need to manage the azuread_application resources (for rotating the client secrets) and the msgraph provider doesn't seem to be able to do that. (If you're wondering why, it's because we're really implementing Google Cloud Workforce Identity Federation, which needs a client ID and secret in order to authenticate using a CODE response type).