Simplify provider w.r.t. fingerprints to avoid storing sensitive data in tf state

[gberche-orange]

The terraform-provider-credhub provider attempts to reduce the amount of sensitive data written in tf state, i.e. some resources creation instead store credentials signatures, see Readme

I wonder whether this added complexity is worth the effort given that:

• other TF providers may imply sensitive data in the TF state, leading operator to apply best practices Terraform recommends that TF state be safely stored in remote backend that can support encryptions documented in https://www.terraform.io/docs/state/sensitive-data.html E;G. this translates to https://github.com/orange-cloudfoundry/paas-templates/issues/62

  Terraform state can contain sensitive data [...] Recommendations: Storing state remotely may provide you encryption at rest depending on the backend you choose. [...] Long term, the Terraform project wants to further improve the ability to secure sensitive data. There are plans to provide a generic mechanism for specific state attributes to be encrypted or even completely omitted from the state. These do not exist yet except on a resource-by-resource basis if documented.

• TF documents that there is no way for datasource sensitive data to not be in TF state in hashicorp vault provider, see

  Important Interacting with Vault from Terraform causes any secrets that you read and write to be persisted in both Terraform's state file and in any generated plan files. [...] Currently Terraform has no mechanism to redact or protect secrets that are returned via data sources, so secrets read via this provider will be persisted into the Terraform state, into any plan files, and in some cases in the console output produced while planning and applying. These artifacts must therefore all be protected accordingly.

[ArthurHlt]

Fingerprint is here to detect a change instead of using value generated, for yes security reasons.

There is actually no terraform backend with encryption except https://github.com/orange-cloudfoundry/terraform-secure-backend .

My feelings about this one was that:

• using the same credhub to store state and request secret is bad idea in case of corruption (but maybe I was going to far)
• In case of user who just wanted to provision creds and consume them elsewhere was annoyed by storing the state
• Adding data source was to consume creds directly in terraform but is trickier for normal user as he should first provision with a resource and after call value from data source.

I'm totally opened to reconsidered this, this part was not explained and this can be put in the balance.

Vault has only generic resource for creating credentials on its provider. Comparing this provider with vault provider on generic is more accurate, and they both work the same on this one.

[gberche-orange]

Fingerprint is here to detect a change instead of using value generated, for yes security reasons.

The credhub api get-by-name can return all historical data for a given path, each version being identified by their id and date.

Could the provider simply load the history for a given path to determine whether a rotation is required or not ?