Reveal functionality for vaultkv refs

[nikkomega]

Describe the feature To use refs in k8s Secrets, the value currently has to be pre-base64ed. This is fine for the local-encrypted types like gkms, since the value is only being consume by Kapitan. For vaultkv, and presumably future remote types, the value (a db password, etc) might be shared with other systems which don't want the base64 version. Per discussion on the slack channel (https://kubernetes.slack.com/archives/C981W2HD3/p1570466155095800) there are already reveal filters like ?{gkms:foo_base64||reveal:path/to/foo|base64}. These don't work with the current vaultkv impl since it doesn't support writes yet, but it's also not clear whether this pattern is desirable for these remote types (presumably pushing a base64 version under a different key with _b64 or similar). I'm opening this just to initiate some discussion about options.

One suggestion: now that || is the separator for the "generate-if-not-extant" part of a ref, one possibility would be to support on-reveal functions like so:

?{vaultkv:path\to\foo|base64||randomstr}

In this case the fetched-from-Vault plaintext value would be base64ed as it's injected into the output.

[srueg]

+1 for this request. It would be nice to be able to apply the functions "on-reveal" as suggested.

In the mean time, we use the secrets stringData feature to work around this:

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
data: {}
type: Opaque
stringData:
  token: ?{vaultkv:path/to/secret/token:4c0765c1}

[pvanderlinden]

Something to think about, currently you have to know if the inventory item is a secret or not (in jinja2 at least):

  username: "{{ inventory.parameters.mail.username | b64encode }}"
  password: "{{ inventory.parameters.mail.password }}"

[MatteoVoges]

Hey @nikkomega and @srueg , I see some benefits of your ideas. Do you have any updates, more context or explicit usecases for me, so that I can understand your situation a bit better?

Otherwise I will close this issue as not planned

[nikkomega]

I haven't been neck-deep in kapitan for a while, but I think the stringData that srueg mentioned would have solved my particular problem; either that hadn't been added to the k8s version we were using at the time or I just didn't notice it.