Terraform: Vault provider

[nevir]

A Vault provider would be handy :)

Places where I'd like to use one:

• RDS root user passwords
• Initial Host/container (or app) token distribution

[ojongerius]

:+1:

[EvanKrall]

+1

[rubbish]

Has anyone started on any work for this? If not, we might get started on one.

[tony612]

:+1: I want this!

[BSick7]

:+1: @rubbish have you started working on this?

[rubbish]

@BSick7 I haven't yet. I ended up going down another long yak shaving. If someone was to start one, I'm sure I'd be able to help.

[mtekel]

+1

[netik]

We have a need for this as well and I'm in for helping out, might start in on it today.

[steve-jansen]

:pray:

[redredgroovy]

I have a demonstration Terraform Vault provider with one major caveat: resources are stored as plaintext in the .tfstate file. Architecturally, there's no way to avoid this until #516 is addressed. We account for this locally by encrypting our state files between runs.

https://github.com/redredgroovy/terraform-provider-vault

[apparentlymart]

Effective use of a Vault provider might end up benefiting from something like what I prototyped in #3060, so that Vault secrets can be used to initialize credential arguments on providers themselves. In the current Terraform architecture that would be bothersome because on the first run the vault resource state would not yet be populated, and so provider initialization would fail. (More details on the problem in #2976)

...which is not to say that implementing a Vault provider should block on this other requirement, but that a Vault provider makes a good additional use-case for that sort of architectural change.

[nickithewatt]

@apparentlymart I agree and think that such an approach would indeed be beneficial for a Vault provider. Is there any movement on this issue? I would think that some kind of official Vault integration would be on the cards from HashiCorp? question to @phinze @jefferai ?

[phinze]

I would think that some kind of official Vault integration would be on the cards from HashiCorp?

Yep! We're currently in the process of modeling the integration internally. Stay tuned. :grinning:

[tony612]

@phinze Cool! :cool:

[meylor]

:+1:

[jcderose]

:+1:

[panda87]

:+1:

[ptierno]

:+1:

[ckelner]

:+1:

[nicolai86]

@phinze Are there any updates to be shared with us eagerly waiting?

[akazakov]

👍

[ptierno]

any updates on this?

[phinze]

Hey folks, I'm actively working on this - if you'd like you can track my work-in-progress on this branch:

https://github.com/hashicorp/terraform/compare/f-vault

Vault integration is a planned feature for Terraform 0.7. :+1:

[coen-hyde]

@phinze this looks fantastic. I'd like to describe a use case that I think would be hard to implement but very powerful.

Imagine i'm deploying an RDS instance that requires a username and password (secrets). The first time I run try to deploy this resource Terraform would require the username and password to be provided as variables. However the username and password would be saved into vault. Subsequent updates to the RDS resource would pull the username and password from vault. This sounds like it could be a hard integration as the core of Terraform would have to be modified. Maybe the vault path could be specified in the variable declaration?

variable "password" {
  vault_path = "/path/in/vault/to/save/data"
}

[ptierno]

@coen-hyde that would be great except for when you store your tf in git and don't want the password stored in plaintext. In my case we use a CI/CD platform to actually run the tf plans and apply's. Wouldnt make sense for me to store a variable with a plaintext password for a first run deployment.

[coen-hyde]

@ptierno Yeah I gave up trying to keep secrets out of the statefile. Life was too difficult. I don't store the statefile in git. Ideally variables that are stored/retrieved from vault would marked as secrets and not stored in the statefile. Anytime that are required they would be pulled from vault.

[BSick7]

@coen-hyde I think this could be done without affecting terraform core. It would be neat if the vault provider could generate usernames/passwords based on a set of rules you define. The vault provider for that resource would look for an existing value. If it did not exist, generate one and place into vault. Otherwise, read existing value. Thoughts @phinze?

[coen-hyde]

@BSick7 I love the idea of generated usernames / passwords. This sounds like it is out of scope of the Vault provider though. Maybe another resource or Terraform function?

[BSick7]

I agree @coen-hyde; out of scope, but very valuable.

[jaymecd]

:+1:

[niquola]

:+1: why it does not exists?

[u2mejc]

Hey @phinze, looks like development on this slowed a month ago? Since 0.7 is staged as the next release, anything I can do to help you to move your branch to a PR? I'm sure you don't need any help, but I'm happy to rebase it, open the PR and squash any bugs if you like.

[devth]

Is this still on track for 0.7 or did it get cut? @phinze

[iroller]

Looks like it didn't make it to 0.7.0?
https://github.com/hashicorp/terraform/blob/master/CHANGELOG.md#070-august-2-2016

[coen-hyde]

Any updates on the Vault provider? I'm super excited for this to land.

[kieferrj]

big +1 here - we literally do not use TF to describe things like RDS because integrations like this do not exist and we refuse to put plaintext pw's in source control

[donaldguy]

It should be stated explicitly that because terraform cannot query for
passwords, in most cases it doesn't know or care if you change them out of
band after the fact. My terraform module and state both think my rds admin
password is xxxxxxxxx

But of course the major exception is credentials needed by terraform itself
to do things (e.g. with the postgresql provider)

On Fri, Aug 26, 2016 at 6:37 PM kieferrj [email protected] wrote:

big +1 here - we literally do not use TF to describe things like RDS
because integrations like this do not exist and we refuse to put plaintext
pw's in source control

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/hashicorp/terraform/issues/2221#issuecomment-242867425,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AACogP5fmElg7U_cQ0aasTPnBDdteo9jks5qj2ktgaJpZM4E3Yw7
.

[omarabid]

Any updates/documentation on this?

[onetwopunch]

Is this a valid replacement? Anyone use this for their infrastructure? https://github.com/redredgroovy/terraform-provider-vault

[mtougeron]

I've used it and it worked pretty well. However, it is not compatible with terraform v0.7+

[onetwopunch]

@mtougeron Thanks for the input, we are using v0.7 sadly so I guess thats a no 😞

[larstobi]

@phinze It's a long time since your last commit to the f-vault branch (Mar 3 2016). Are there any plans to pick it up again?

[Bhuwan]

FYI to all.. seems that PR #9158 at least partially covers this, which is in master as beta1 0.8

[apparentlymart]

The work in #9158 made a start here. There are several other resources and data sources we could implement, but since the basic framework is merged to master I'm going to close this and we can discuss further iterative enhancements in separate issues/PRs. Thanks for the discussion here, everyone!

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.