Add support to encode file as base64 string

[skokhanovskiy]

File provider should support encoding files as base64 string.

In our project we use vals with helm and helm-secrets plugin. Sometime it's needed to delivery a binary file to a Kubernetes cluster as-is. For example, Java keystore (.jks) files.

Because of limitations in Helm (see helm/helm#3276) we deliver binary files by passing their contents as base64 string directly in Helm values as YAML.

data:
  keystore.jks: |-
    SGVsbG8gd29ybGQhCg==

These base64 lines can be very long, which turns the contents of YAML files into a mass of boilerplate text.

To deal with that we use vals with the file provider. But we couldn't just read binary file and paste its contents to values because that will break YAML completely:

data:
  keystore.jks: ref+file://helm/data/keystore.jks

Before it we run a script that converts all binary files to base64 and saves results. After that we load this files by vals.

base64 <helm/data/keystore.jks >helm/data/keystore.jks.base64

data:
  keystore.jks: ref+file://helm/data/keystore.jks.base64

It would be nice if vals can be able to encode binary files to base64 string by itself. For example, by using parameter in the reference string:

data:
  keystore.jks: ref+file://helm/data/keystore.jks?encode=base64

[lucasfcnunes]

@mumoshu already proposed this on roboll/helmfile#929 (comment)

[yxxhero]

@mumoshu already proposed this on roboll/helmfile#929 (comment)

@skokhanovskiy WDYT?

[skokhanovskiy]

@yxxhero Sorry, but I didn't get.

In the issue that @lucasfcnunes mentioned, only sops provider is discussed. But here we are talking about file.

Could you explain? What do I should think about what?)

[lucasfcnunes]

It's true ref+sops://...?encode=base64 was mentioned specifically. I really think ref+<whatever>://...?encode=base64 was implied there. Maybe not...

[skokhanovskiy]

As I understand vals architecture doesn't provide any way to add "query params" globally for all providers. Each provider independently decides how to process this parameters.

In #167 not so many "useful" code was added) I think this could be a good example and a source for inspiration how to implement the same logic in other providers if it's needed.

[lucasfcnunes]

You're right. Reading your #167 made it clear to me.