The credhub cli version is currently vendored and I could not easily spot which version it was (as it it rebased, and not using a submodule). A package management such as go dep might help.

The credhub cli calls to fetch credentials have evolved to use the current=true option instead of the versions=1 in the get-by-name credhub api call, see orange-cloudfoundry/paas-templates#53 (comment)

Sensitive fields might benefit from being marked as sensitive would redact them in logs/outputs

Seems that the credhub terraform plugin does not retrieve value version from credhub (ie: value has been updated with credhub cli, the plugin seem to retrieve a previous version)

config:

data "credhub_value" "intranet_interco_ips_net_id" {
  name = "/secrets/intranet_interco_ips_net_id"
}

credhub cli value

$ credhub get --name="/secrets/intranet_interco_ips_net_id"
id: b798d461-8907-4f84-b0c2-386cef9a5fb0
name: /secrets/intranet_interco_ips_net_id
type: value
value: 0130df67-7374-458a-b9c1-265892e7190d
version_created_at: 2018-02-26T09:44:39Z

terraform log

+ terraform version
Terraform v0.11.2
+ provider.credhub v0.10.0

Your version of Terraform is out of date! The latest version
is 0.11.3. You can update by downloading from www.terraform.io/downloads.html
+ pwd
+ CURRENT_DIR=/tmp/build/6d6ccb0c
+ find secret-state-resource/master-depls/terraform-config -type f -exec cp {} generated-files/ ;
+ find terraform-tfvars -type f -exec cp {} generated-files/ ;
+ find spec-resource/master-depls/terraform-config/spec -mindepth 1 -maxdepth 1 -exec cp --verbose -r {} spec-applied/ ;
'spec-resource/master-depls/terraform-config/spec/intranet-interco-vrrp-ports.tf' -> 'spec-applied/intranet-interco-vrrp-ports.tf'
PROVIDER_CREDHUB_VERSION=0.10.0
TERRAFORM_ZIP=terraform_0.11.2_linux_amd64.zip
SPEC_PATH=master-depls/terraform-config/spec
....
21172	/.terraform/plugins/linux_amd64/terraform-provider-credhub_v0.10.0
...
288548	/.terraform/plugins/linux_amd64
288552	/.terraform/plugins
288556	/.terraform
+ terraform init -input=false -upgrade -get-plugins=false -plugin-dir=/.terraform/plugins/linux_amd64 ../spec-applied/

Initializing provider plugins...

The following providers do not have any version constraints in configuration,
so the latest version was installed.

To prevent automatic upgrades to new major versions that may contain breaking
changes, it is recommended to add version = "..." constraints to the
corresponding provider blocks in configuration, with the constraint strings
suggested below.

* provider.credhub: version = "~> 0.10"

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
+ terraform plan -input=false ../spec-applied/
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

data.credhub_value.intranet_interco_ips_net_id: Refreshing state...
------------------------------------------------------------------------

No changes. Infrastructure is up-to-date.

This means that Terraform did not detect any differences between your
configuration and real physical resources that exist. As a result, no
actions need to be performed.

terraform state

{
    "version": 3,
    "terraform_version": "0.11.2",
    "serial": 1,
    "lineage": "a7040192-db17-42d7-a37c-337f1393fb09",
    "modules": [
        {
            "path": [
                "root"
            ],
            "outputs": {},
            "resources": {
...
 
                "data.credhub_value.intranet_interco_ips_net_id": {
                    "type": "credhub_value",
                    "depends_on": [],
                    "primary": {
                        "id": "bc987039-2276-43df-b333-5b5e3ce1266b",
                        "attributes": {
                            "id": "bc987039-2276-43df-b333-5b5e3ce1266b",
                            "name": "/secrets/intranet_interco_ips_net_id",
                            "type": "value",
                            "value": "43acffd0-a978-4ad5-a1a9-f9b70365bb72"
                        },
                        "meta": {},
                        "tainted": false
                    },
                    "deposed": [],
                    "provider": "provider.credhub"
                },

By the way, the value seem to be stored in terraform tfstate. Is it required ? (as credhub offers update timestamp, guess the plugin could check freshness without storing the credhub values).

Due to breaking change the resource reference and data source references. The current version of credhub provider for terraform is got broken.

To fix the issue, need to bump-up the terraform version and as well as need to recompile the credhub provider to check the syntax is inline with current version of terraform.

New breaking changes in terraform 0.12.14 onwords: https://github.com/hashicorp/terraform/blob/master/CHANGELOG.md#01214-november-13-2019 The current workaround is to pin-down the terraform version and as well as credhub provider for terraform version.

As a credhub provider user

• in order to assign metadata to credhub entries
• I need the provider to provide a metadata_json attribute

See cloudfoundry/credhub#45 for the associated metadata request and https://docs.cloudfoundry.org/api/credhub/version/2.9/#_set_a_value_credential for specs about metadata

$ curl 'https://example.com/api/v1/data' -i -X PUT
-H 'Content-Type: application/json'
-H 'Authorization: Bearer [some-token]'
-d '{
"name": "/some-value-name",
"type": "value",
"metadata": { "description": "example metadata"},
"value": "some-value"
}'

With adoption of credhub, the need to provision permissions to read/write to credhub is increasing.

Being able to manage this into terraform would be useful both for static permissions, and dynamic permissions, such as in orange-cloudfoundry/sec-group-broker-filter#50

Related endpoints:
https://credhub-api.cfapps.io/#add-permissions
https://credhub-api.cfapps.io/#get-permissions
https://credhub-api.cfapps.io/#delete-permissions

Suggesting to expose permissions[n].actor as plain strings such as mtls-app:fdbeb2d4-b601-4a0d-91e8-7e38dde426f7 that terraform configurations can construct from other resources, such as $datasource.cloudfoundry.application.id or future UAA support in terraform cloudfoundry.

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 orange-cloudfoundry/paas-templates#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.

👋 Hi there! We noticed this provider is on our list of community providers, however it has not yet been published to the newly-released Terraform Registry for Providers (registry.terraform.io). We'd like to invite you to get it published, since it makes using and installing it much easier for anyone using Terraform 0.13! Instructions for doing so are available here. If you need some help producing documentation, take a look at this project which may come in handy!

Please note that we will soon be redirecting the community listing page to registry.terraform.io.

Thanks for your contributions and we look forward to seeing this provider listed soon!

Thanks,
Team Terraform @ HashiCorp

Trying to use terraform credhub provider.
I have below for my provider.tf

terraform {
  required_providers {
    credhub = {
      source = "orange-cloudfoundry/credhub"
      version = "0.15.6"
    }
  }
}


provider "credhub" {
  credhub_server      = "https://example.com/"
  username            = ""
  password            = ""
  skip_ssl_validation = true
  client_id           = xxxxx
  client_secret       = xxxxxx
  ca_cert             = ""
}

next is my main.tf

data "credhub_password" "my_data" {
  name = "/concourse/sbx/password"
  // or you can use credential id:
  // cred_id = "mydata-id"
}

resource "kubernetes_secret" "example" {
  metadata {
    name = "basic-auth"
  }

  data = {
    username = "admin"
    password = data.credhub_password.my_data.name
  }
}

When I look up the secret created the data for password is blank. Terraform is not able to pick up the password I have set in the credhub server. Infact the key for passowrd is not in the secret at all

Likely including acceptance tests using the TF acceptance testing framework documented at https://github.com/hashicorp/terraform/blob/master/.github/CONTRIBUTING.md#writing-acceptance-tests, until this appears explictly into https://www.terraform.io/docs/extend/index.html

The CI environment might need to leverage BBL to span an up to date credhub server and access it see related doc

Alternatively, the CI environment could be shared with the one from https://github.com/mevansam/terraform-provider-cf. @mevansam would you be ok with this ?