Skip to content
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

Consul Templates Fail to Render when using KV2 secrets with deletion time #1789

Closed
Jasonrchoi opened this issue Aug 7, 2023 · 0 comments · Fixed by #1879
Closed

Consul Templates Fail to Render when using KV2 secrets with deletion time #1789

Jasonrchoi opened this issue Aug 7, 2023 · 0 comments · Fixed by #1879

Comments

@Jasonrchoi
Copy link

Jasonrchoi commented Aug 7, 2023

Using the Vault Agent Injector in EKS Cluster A addressed to an external vault in EKS Cluster B, I have a test pod with the following annotations. The integration-app-test role was given a policy that grants access to both secret paths.

Command

        vault.hashicorp.com/agent-inject-secret-credentials.txt: secret/staging/app/secure #Generic backend
        vault.hashicorp.com/agent-inject-secret-secure: secretv2/data/application/staging/app #KV2 backend
        vault.hashicorp.com/agent-inject-template-secure: |
          {{ with secret "secretv2/data/application/staging/app" -}}
            {{ range $k, $v := .Data.metadata }}
              export {{ $k | toUpper }}={{ $v }}
            {{ end }}
          {{- end }}
        vault.hashicorp.com/auth-path: auth/kubernetes_integration
        vault.hashicorp.com/log-level: trace
        vault.hashicorp.com/role: integration-app-test

note `secret/` refers to a generic secrets backend, `secretv2/` refers to a 'kv2' backend

Expected behavior

What should have happened?

Secrets from both backends were rendered into the pod.

Actual behavior

We found that the "generic" secrets are rendered correctly, while the "kv2" secrets receive a no secret exists at {PATH} error and then eventually, Permission Denied. Because we were able to access secrets from our generic secret backend, it appeared we could rule out most auth/network issues.

Steps to reproduce

We think we discovered the cause which is:

func deletedKVv2(s *api.Secret) bool {

In the DeleteKV2v2 method, any Deletion_Time associated with the secret, other than null, will cause the method to return true, causing the Read to throw an error that the secret does not exist, even if it clearly does. Once we got rid of deletion time for our secrets, the kv2 secret was rendered correctly by the Vault Agent Injector.

References

It appears this issue was alluded to in vault-k8s but never resolved.

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
1 participant