hashicorp / hashicorp/vault-secrets-operator

Retain the secret's key from KV backend When using transformation API to decode secret values.

Open
#676 2 comments 5 reactions 0 assignees View on GitHub
enhancement
Dominant language
Go
Stars
600
Forks
146
Avg merge
3d 8h
Merged PRs (30d)
6

Description

**Is your feature request related to a problem? Please describe.**
When using transformation API with VSS or SecretTransformation, we are not able to retain the secret's key from KV backend of Vault.
Transformation API forces to use template name as the Secret's Key instead of using the key from Vault.

**Describe the solution you'd like**
I should be able to range though the KV pairs from Vault and perform any manipulations in the templates. In the example below, the template name can be made optional to retrieve KV pairs from Vault.
```
transformation:
excludeRaw: true
templates:
text: |-
{{- range $key, $value := .Secrets }}
{{- printf "%s=%s\n" $key ( $value | b64dec ) -}}
{{- end }}
```

**Describe alternatives you've considered**
A clear and concise description of any alternative solutions or features you've considered.
With the existing transformation API, I am forced to provide a `templates.key` in VSS yaml and it discards the Key from Vault KV backend. In the example below, I have to explicitly pass the Keys - constants.pwd & somexml.xml
```
transformation:
excludes:
- .*
excludeRaw: true
templates:
constants.pwd:
text: |-
{{- $value := get .Secrets "constants.pwd" }}
{{- printf "%s" ( $value | b64dec ) -}}
somexml.xml:
text: |-
{{- $value := get .Secrets "somexml.xml" }}
{{- printf "%s" ( $value | b64dec ) -}}
```

**Current Experience**
Our TIBCO application has 300+ microservices with 300+ Secrets. Providing and maintaining 300+ VSS with unique transformation template will be tedious.
With the proposed feature, we can use a standard transformation template across all the VSS yamls.

**Expectations**
With the proposed solution, we should be able to convert Vault KV secrets into K8s Secrets as indicated below:
Secrets in Vault KV-v2 backend (encoded values)
```
vault kv get -format=json ngil/tibcobwce/performance/test-uploaddocuments | jq -r '.data.data'
{
"constants.pwd": "c29tZVBhc3N3b3JkCg==",
"somexml.xml": "VGhlIHZhbHVlIGlzIGI2NCBlbmNvZGluZyBvZiBYTUwK"
}
```
to
```
oc get secrets test-uploaddocuments -o json | jq -r '.data'
{
"constants.pwd": "c29tZVBhc3N3b3JkCg==",
"somexml.xml": "VGhlIHZhbHVlIGlzIGI2NCBlbmNvZGluZyBvZiBYTUwK"
}
```

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by tracing the transformation API and how the templates map is built from the issue's VSS examples. Compare the current template-key behavior with the requested range over Vault KV pairs. Done means a standard optional-template transformation can preserve the original secret keys, with coverage for the shown multi-key case.

Written by the indexing model from the issue text.

Assessment

Tech stack
go, kubernetes
Domain
devops, infrastructure
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.