vault_generic_secret fails to read secrets (unexpected EOF)

[EugeneK6S]

Terraform Version

Terraform v0.8.2

Affected Resource(s)

Please list the resources as a list, for example:

• vault_generic_secret

Terraform Configuration Files

provider "vault" {
  address = "http://vault_server:8200"
  skip_tls_verify = true
}

data "vault_generic_secret" "docker" {
  path = "secret/docker"
}

output "secret" {
	value = "${data.vault_generic_secret.docker.data["docker_registry_pwd"]}"
}

Debug Output

https://gist.github.com/IevgenKabanets/c16d2e5ef4520921ba05e5a79ee11079

Panic Output

https://gist.github.com/IevgenKabanets/c16d2e5ef4520921ba05e5a79ee11079

Expected Behavior

The secret should be read, as it's present in Vault and accessible with curl.

Actual Behavior

Crashed with * data.vault_generic_secret.docker: unexpected EOF

Steps to Reproduce

1. export VAULT_TOKEN=<root_token or any token>
2. terraform plan or terraform apply

Important Factoids

This works fine

curl -X GET -H "X-Vault-Token:$VAULT_TOKEN" http://vault_server:8200/v1/secret/docker/docker_registry_pwd

Also, the error is gone once I read full path to entry (secret/docker/docker_registry_pwd)

data "vault_generic_secret" "docker" {
  path = "secret/docker/docker_registry_pwd"
}

which seems to be wrong, as vault_generic_secret should return a map with possible keys/values.

References

Are there any other GitHub issues (open or closed) or Pull Requests that should be linked here? For example:

• raised as a separate issue, from Crash when using plan with vault provider #10505 and by the advice of @apparentlymart

[EugeneK6S]

After reading this piece of code, it seems that the correct way (it works) to request the value will be

data "vault_generic_secret" "docker" {
  path = "secret/docker/docker_registry_pwd"
}

output "secret" {
	value = "${data.vault_generic_secret.docker.data["value"]}"
}

Which is not something I understood from docs here.
From it I had a feeling, that auth_token is a value at secret/rundeck_auth (reading value of secret/rundeck_auth/auth_token

Anyway, maybe someone can clarify it in the docs or for me.

[mperriere]

Hello,
same issue here.

[EugeneK6S]

@mperriere can you use the workaround I've put in a post above? Works fine for now.

[mperriere]

Hello,
still have the same error.

Here is the crash.log when executing "terraform plan":
https://gist.github.com/mperriere/87204952a2170bb4f38bee3bb08dbe98

terraform version: 0.8.4 (but same issue with older 0.8.* versions)

the tf file:
provider "vault" {
address = "http://10.196.14.160:8081/"
token = "e1703672-7c1d-97c2-6dee-b3dc0fc8714c"
ca_cert_file = "wildcard.zzz-2016-11-14.crt"
ca_cert_dir = ".."
skip_tls_verify = true
}
data "vault_generic_secret" "mypass" {
path = "secret/neo/rds-passwd"
}
output "my password" {
value = "${data.vault_generic_secret.mypass.data["value"]}"
}

The stored passwd is readable:
VAULT_ADDR=http://10.196.14.160:8200 vault read secret/neo/rds-passwd
Key Value
refresh_interval 768h0m0s
passwd ilovevault

Another issue is that even with "skip_tls_verify" the ca_cert_dir and ca_cert_file are mandatory (or documentation is not up to date).
Also tried with address http://10.196.14.160:8200 with no success.

[mperriere]

ok, i got it:
tf plan -input=false
Errors:

• provider.vault: "ca_cert_file": conflicts with ca_cert_dir ("..")
• provider.vault: "ca_cert_dir": conflicts with ca_cert_file ("wildcard.mediametrie.fr-2016-11-14.crt")

-> those 2 options are mutually exclusives, but mandatory.

new terraform file with ca* removed:

provider "vault" {
address = "http://10.196.14.160:8200"
skip_tls_verify = true
}
data "vault_generic_secret" "mypass" {
path = "secret/neo/rds-passwd"
}
output "my password" {
value = "${data.vault_generic_secret.mypass.data["Value"]}"
}

tf plan -input=false
tf apply -input=false
-> no crash and passwd found in the terraform.tfstate file.

[eraserhd]

I think this was resolved in 0.8.5. Want to check?

[mperriere]

checked with 0.8.5, it works now, thanks.

[plukevdh]

Can the docs be updated before this gets closed?

[ghost]

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.