-
Notifications
You must be signed in to change notification settings - Fork 192
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
panic with Vault kv-v2 secret engine #175
Milestone
Comments
philpennock
added a commit
to PennockTech/consul-template
that referenced
this issue
Jun 29, 2018
K/V version 2 mounts change the URL path to read and how data is returned. Within consul-template, it's just harder to get values, but in envconsul it manifests as panics; see hashicorp/envconsul#175 Because I suspect that a dominant use for consul-template and envconsul is reading from secrets mounts, the "correct" behavior seems to be to try to abstract away the presence of version 2 mounts, mutating both the query and how data is returned. Until now, the Secret object has been strictly agnostic as to the backend, but we got away with that because assuming that `map[string]interface{} == map[string]string` worked for existing backends. This doesn't hold when K/V v2 puts the data key=value items as keys in a sub-dict of the response. End-users reading data from Vault shouldn't need to know or care if the mount-point is V1 or V2. Handling this is complicated by: 1. The `/sys/internal/ui/mounts` being marked internal-only; well, it's the only source of data and is used by the Vault CLI tool. Unless and until something better comes along, it's our only choice. Vault was released with v2 mounts by default, forcing the issue for us. 2. consul-template's vendored vault server is old, so doesn't have the sys/internal mount needed, so tests won't pass. Trying to update the vendored copy leads to a slew of complications. This commit skips the update of the vendored library, so tests are broken. Fixing that too was too much yak-shaving for this external contributor when unbreaking the tools. This commit does not change the vault write logic, only the vault read logic. That's TBD.
Is there an update on this? |
I've opened #186 that should address this and support both kv versions |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When attempting to read a key from Vault using the kv-v2 secret engine, envconsul panics with
map[string]interface {}, not string
Envconsul version
Configuration
Command
Debug output
Expected behavior
Should set environment data.
Actual behavior
Panic
envconsul -config config.hcl -log-level debug -secret secrets/test env
results in "no secret exists at secrets/test"Data can be read using curl.
curl --header "X-Vault-Token: <redacted>" --request GET --data @payload.json --insecure https://vault.local.domain/v1/secrets/data/test
Steps to reproduce
The text was updated successfully, but these errors were encountered: