Support to Read Base64 format and Decode it in Secret - for storing Certificates

[adit0012m]

@jkayani I should Thank everyone for the wonderful work.

We are expecting something similar. Describing few challenges as per my understanding and testing.

Tested the for both use cases,

          THING: <mykey>

The plugin does replace data key from Vault as-is ( but, Ref: then the plugin will base64 the Vault data before replacing the placeholder..). In our case, not the correct behaviour then.
and

          THING: <mykey>

Expected stringData inside the key should replace value from Vault as-is which is not working.

Configured yaml file looks as below:

apiVersion: v1
kind: Secret
metadata:
  name: example-secret
  annotations:
    avp_path: <kv/data/secret-folder>
type: Opaque
data:
  MyKey: <MyKey>

Thoughts on this.

Expecting a new Feature or an Existing Options are not Aware
The plugin works perfectly fine with the plain text stored in Vault get's the value back in to the secret. Is there a way we can decode values present in a Vault secret path are encoded in the base64 format at the secret end. This helps us to store certificate formats such as .crt, .pem etc...

• Store certificates in base64 encoded format in Vault secret path and values are decoded when retrieves it from Vault server. Just to give an example. Same is achieved using Consul Template to render the Vault secret with side car container Vault k8s auth method.

Ex: ```{{with secret "secret/example"}} MyKey = {{.Data.data.MyKeyCerts | base64Decode}}{{end}}

So, is there any way we can decode base64 format data before it replaces the placeholder with the actual value --> something like "<base64decode MyKey>".

Originally posted by @adit0012m in #92 (comment)

[werne2j]

@adit0012m This is an interesting thought, we will look into if adding transformer helpers such as base64decode and base64encode make sense for the plugin. Thank you for your feature request!

[anzxcolinlcc]

+1 we also have requirements to use vault to manage tls.crt and tls.key and would need the plugin to work with the above use case

[werne2j]

Once #96 gets merged, you will be able to load in a base64 encoded cert to vault and then use the data field to put into your cluster.

For example:
In Github..

apiVersion: v1
kind: Secret
metadata:
  annotations:
    avp_path: kv/data/test
  name: sample-cert
data:
  sample-cert: <sample-cert>
type: Opaque

In Vault..

In Kubernetes..

Does that work for your use case?

[anzxcolinlcc]

in the data field, is there going to be option to configure whether is base64 decode or raw?

e.g.

data:
   decoded:
     path: secret/data/pathtosecret1
     encoding: base64
     key: value
   raw:
     path: secret/data/pathtosecret1
     key: value

[werne2j]

@clcchai Not at this time. If you want to store a base64 encoded value in vault and have it be decoded in Kubernetes you would use the data field. If you want that base64 encoded value to still be base64 encoded in kubernetes, you could use stringData.

https://github.com/werne2j/argocd-example/blob/master/kubernetes/cert-sample.yaml

Encoded:

Decoded:

And you can use data and stringData in the same secret if needed.

[adit0012m]

Once #96 gets merged, you will be able to load in a base64 encoded cert to vault and then use the data field to put into your cluster.

For example:
In Github..

apiVersion: v1
kind: Secret
metadata:
  annotations:
    avp_path: kv/data/test
  name: sample-cert
data:
  sample-cert: <sample-cert>
type: Opaque

In Vault..

In Kubernetes..

Does that work for your use case?

@werne2j this would be fine for now to make basic functionalities work. sounds good.

[werne2j]

Changes are now available in https://github.com/IBM/argocd-vault-plugin/releases/tag/v0.6.0