random_string: add case-insensitive rejection string

[ari-becker]

Terraform CLI and Provider Versions

terraform 1.9.4
random: 3.6.3

Use Cases or Problem Statement

We rely upon random_string to generate resource identifiers for Azure resources.

Today, in a particular case, it generated xbox7zw6jugefzbnlvi8dl1z.

This lead to the following error:

unexpected status 400 (400 Bad Request) with error: ReservedResourceName: The resource name 'xbox7zw6jugefzbnlvi8dl1z' or a part of the name is a trademarked or reserved word

So the generated string ran afoul of https://learn.microsoft.com/en-us/azure/azure-resource-manager/troubleshooting/error-reserved-resource-name and caused the Terraform apply to error out.

Proposal

Some way of configuring the random_string provider with the Azure-provided list of reserved/trademarked strings in order to guarantee that the random provider doesn't provide random strings that violate this limitation.

How much impact is this issue causing?

Medium

Additional Information

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[ramonvermeulen]

Would adding two properties:

• exclusions Set of String
• exclusions_case_sensitive Boolean (default false)

Be a good solution to this issue? Ability to add an exclusion set either being case sensitive or case insensitive. When a random string gets generated and matches the exclusion set, it will regenerate until it has a string that does not match any of the strings in the exclusion set. Another idea could be instead of a Set of Strings to accept a Set of Regex patterns, if the generated string matches the pattern it will regenerate a new one?

If so, I'm willing to create a PR for this feature.

EDIT: opened draft PR.

[ari-becker]

Would adding two properties:

• exclusions Set of String
• exclusions_case_sensitive Boolean (default false)

Be a good solution to this issue? Ability to add an exclusion set either being case sensitive or case insensitive. When a random string gets generated and matches the exclusion set, it will regenerate until it has a string that does not match any of the strings in the exclusion set. Another idea could be instead of a Set of Strings to accept a Set of Regex patterns, if the generated string matches the pattern it will regenerate a new one?

If so, I'm willing to create a PR for this feature.

EDIT: opened draft PR.

All of the above would be helpful :) thanks

[austinvalle]

Hey there @ari-becker 👋🏻 , thanks for raising the issue and sorry you're running into trouble here.

Before looking to design a solution for this, I'd be interested in hearing:

• If you run into this issue often or if it was a one-time problem.
• What your workaround looked like when you ran into this

From my initial assumption, if you created a random_string that produced an error in a remote system like this, you could either taint the random_string via a command like terraform apply -replace="random_string.example" to regenerate it, or you could use the keepers attribute on the random_string resource to recreate it via config.

---

Ref #630 (comment)

One concern we have about introducing some form of exclusions set of strings is the general maintenance of the exclude list itself and offloading the responsibility of using that data to the practitioner writing the config. I'd imagine you'd want to retrieve that data from the azurerm provider (and same for any other individual service, or other CSP provider resource that may have different reserved names), which is now on each of those providers to introduce/maintain that functionality.

I'm also wondering if practitioners using random_string would explicitly have the foresight to add a complete/accurate exclusion list before attempting to run an apply, or if it would be used reactively, which would have the same workflow as I mentioned above, but rather than adding a keepers attribute, they would be adding an excludes = ["xbox"] attribute.

[ari-becker]

Hi @austinvalle , yes we resolved this by tainting the resource, but that's not ideal in our case. We're using this resource at a very large (numbers are not public) autonomous scale, and every time this error comes up (and it did come up a couple times in the last couple of months), we need to manually intervene by tainting in order to fix the error. The only other solution we can think of at the moment is to adjust our Terraform automation to look for this error specifically (i.e. grepping console output) and taint this resource specifically in response before re-trying, which sounds very imprecise and a drag on overall automation runtime in response to a rare error.

I'm less concerned with getting support from an upstream provider to provide a list of exclusions - that would be nice, and more reliable if the upstream provider updated their exclusion list, but it's a nice to have. Just adding this field at least lets me fix the problem on my own.

How would you propose using keepers here? Doesn't that make it a circular reference, i.e. feeding the result through a filter that is then fed back into the keepers map?

[austinvalle]

We're using this resource at a very large (numbers are not public) autonomous scale, and every time this error comes up (and it did come up a couple times in the last couple of months), we need to manually intervene by tainting in order to fix the error.

Ah, that's unfortunate 🙁

How would you propose using keepers here? Doesn't that make it a circular reference, i.e. feeding the result through a filter that is then fed back into the keepers map?

I was just referencing that you could achieve the same result of recreating the random string via using keepers as an config-based alternative to running terraform taint via the CLI. Not proposing it as a solution, rather an alternative workaround.

resource "random_string" "random" {
  length           = 16

  keepers = {
    # Generate a new string each time this variable changes
    regenerate_str = var.regenerate_str
  }
}

---

So if there was a hypothetical exclusions list of values, would you maintain a "master list" via variable inputs/an external data source? Just trying to understand a little deeper what you were thinking of.

As well, I'm wondering if a list like this should essentially never prompt any changes to the resource? So like if we generated a random string of xbox7zw6jugefzbnlvi8dl1z, with no exclusions:

resource "random_string" "random" {
  length           = 16

  exclusions = [] # none at the moment
}

And then after applying, I run another plan with this:

resource "random_string" "random" {
  length           = 16

  exclusions = ["xbox"]
}

Would you expect the resource to recreate and replace the string now that it contains one of the exclusions retroactively? Wondering if maintaining a master list of exclusions and updating it could cause unwanted recreations

[ramonvermeulen]

We're using this resource at a very large (numbers are not public) autonomous scale, and every time this error comes up (and it did come up a couple times in the last couple of months), we need to manually intervene by tainting in order to fix the error.

Ah, that's unfortunate 🙁

How would you propose using keepers here? Doesn't that make it a circular reference, i.e. feeding the result through a filter that is then fed back into the keepers map?

I was just referencing that you could achieve the same result of recreating the random string via using keepers as an config-based alternative to running terraform taint via the CLI. Not proposing it as a solution, rather an alternative workaround.

resource "random_string" "random" {
  length           = 16

  keepers = {
    # Generate a new string each time this variable changes
    regenerate_str = var.regenerate_str
  }
}

---

So if there was a hypothetical exclusions list of values, would you maintain a "master list" via variable inputs/an external data source? Just trying to understand a little deeper what you were thinking of.

As well, I'm wondering if a list like this should essentially never prompt any changes to the resource? So like if we generated a random string of xbox7zw6jugefzbnlvi8dl1z, with no exclusions:

resource "random_string" "random" {
  length           = 16

  exclusions = [] # none at the moment
}

And then after applying, I run another plan with this:

resource "random_string" "random" {
  length           = 16

  exclusions = ["xbox"]
}

Would you expect the resource to recreate and replace the string now that it contains one of the exclusions retroactively? Wondering if maintaining a master list of exclusions and updating it could cause unwanted recreations

Maybe it could be an extra option to recreate or not recreate existing resources (e.g. existing resource in terraform state) that match the exclusions after updating the exclusions? Downside is that there will be a second configuration option.

Also, I would go with a set of Regex patterns as exclusions, because I think it offers more flexibility and less configuration.

[ari-becker]

I was just referencing that you could achieve the same result of recreating the random string via using keepers as an config-based alternative to running terraform taint via the CLI. Not proposing it as a solution, rather an alternative workaround.

resource "random_string" "random" {
length = 16

keepers = {
# Generate a new string each time this variable changes
regenerate_str = var.regenerate_str
}
}

Running "terraform taint" manually is less the problem, which is needing to intervene manually in the first place. Using keepers, we would still need to intervene manually by setting the variable, and actually we would need such a variable per random_string, i.e. per name we create per resource, i.e. per Azure resource being created. I know there's some tricks here, like using a map variable and lookup to find a particular resource name in the map that would ordinarily be empty, but it's beside the point that I'm looking for a way to handle this without future manual interventions.

So if there was a hypothetical exclusions list of values, would you maintain a "master list" via variable inputs/an external data source? Just trying to understand a little deeper what you were thinking of.

At the moment, I would have a local with the list of exclusion terms, to be shared across all the random_string usages.

As well, I'm wondering if a list like this should essentially never prompt any changes to the resource? So like if we generated a random string of xbox7zw6jugefzbnlvi8dl1z, with no exclusions:

resource "random_string" "random" {
length = 16

exclusions = [] # none at the moment
}

And then after applying, I run another plan with this:

resource "random_string" "random" {
length = 16

exclusions = ["xbox"]
}

Would you expect the resource to recreate and replace the string now that it contains one of the exclusions retroactively? Wondering if maintaining a master list of exclusions and updating it could cause unwanted recreations

I would argue yes, it should be recreated and replaced, i.e. on the occasion that the exclusion list needs to be updated with an upstream provider adding additional copywrited terms.

Consider the following edge-case:

1. random_string providing names
2. upstream_container named with the name from random_string, which is stable after creation
3. upstream_contained, whose name is based on upstream_container's name
4. Provider exclusion list adds a new forbidden term
5. upstream_container is permitted to keep its name, due to legacy status
6. Failure to create new upstream_contained due to the exclusion list.

Planning automatic recreation and replacement avoids this problem.
Usually, resources that are dangerous to delete and recreate (i.e. database names) will have some kind of deletion protection setting that will interfere and cause Terraform to error. In such edge cases, users would manually intervene and configure the upstream_container with an overridden name conforming to the legacy-status name that had been granted previously.