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

Allow a seed option for random_string #49

Open
deadwards90 opened this issue Oct 10, 2018 · 5 comments
Open

Allow a seed option for random_string #49

deadwards90 opened this issue Oct 10, 2018 · 5 comments

Comments

@deadwards90
Copy link

deadwards90 commented Oct 10, 2018

Terraform Version

v0.11.8

Affected Resource(s)

random_string

Terraform Configuration Files

Current

resource "random_string" "rg_name" {
  length = 13
  upper = false
  special = false
}

Proposed

resource "random_string" "rg_name" {
  length = 13
  upper = false
  special = false
  seed = "${var.myseed}"
}

Important Factoids

Mainly thinking about Azure here (not too familiar with AWS), but in Azure they have a function in their ARM scripts called uniqueString which generates a 13 character "unique" string based off other strings as seeds.

This is quite useful when you want to tear down an environment and rebuild it as the names will all stay the same.

There might be a way of doing this in Terraform that I missed but thought this could do it

@remilapeyre
Copy link

Hi @dantheman999301, radom_string uses crypto/rand under the hood and rand.Reader to give cryptographically secure strings and I'm not sure it will be possible to add a seed parameter.

@deadwards90
Copy link
Author

Yes, I did notice that when I was having a poke around (but I don't know Go or it's libraries that well).

I ended up somewhat hacking around it using a random id and then converting that to hex so it was uri friendly which did the job but was not that nice.

I could even create a random int (with a seed), then hash it and then strip it to X characters but it just seems a bit of a hack. But if it can't be done, it can't be done!

@tomasaschan
Copy link

I'd like to be able to do this as well!

Basic use case:
I handle an application with multiple environments and tenants. so for each env/tenant combo, there are

  • some shared resources (the same in all env/tenants)
  • some environment resources (the same for all tenants in an environment)
  • some tenant resources (unique per tenant)
    To switch between them, I have an init script which reconfigures terraform for the target env/tenant combo, and imports any resources missing from the state.

Now, I have environment resources based on random_string, e.g. database credentials for server instances shared within the environment. I can import the database server itself OK, but because the random_string resources are different in the new env/tenant, terraform wants to destroy and recreate it with the new credentials (which will break the existing tenants in that environment). Ideally i'd like to seed the random_string resources based on the environment name, but that doesn't seem to be what keepers do (setting a keeper to the env name and reconfiguring yields different random_string results, even though the keeper value has not changed).

I could probably work around it with a random int, seeded with something derived from the environment name, then hash that int, but it would be much nicer to work with if I didn't have to.

Maybe random_string can switch to a different RNG if a seed is provided? (If the user is providing a seed, cryptographic security is probably not a concern).

@remilapeyre
Copy link

@tomasaschan Is it not possible to import the random_string resource as well?

@tomasaschan
Copy link

@remilapeyre Maybe; I haven't been able to figure out how to export/import them. (The other resources I import based on their actual state in Azure, but the random_string resources naturally don't exist there, and the properties they write to in the configuration are write-only.)

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

4 participants