Proposal: ENV builder from multiple secrets

[prochac]

Something I missed in Teller was a templating system.

My usecase:

• Having username, password, hostname and database in a vault.
• But the app uses DSN type of config.

It would be nice to be able to somehow compose the DSN from the secrets.
The PG_DSN could be defined as Go text/template: postgres://{{ .Env.PG_USER}}...
And the PG_USER could have a flag that it shouldn't be outputted.

I don't urge this feature. It may be just me who potentially needs this.
But I think it helps with adoption to already existing projects.

[dirathea]

That would be great! I agree this could be beneficial

[dirathea]

@prochac I guess we need to discuss about the proposal first before jumping to the implementation. As we have some kind of confusion here, we need to define the behavior with the templating.

Consider the following examples:

providers:
  - kind: 1password # Contains PG_USER, PG_PASS, PG_HOST, PG_DATABASE
    id: onepassword-prod
    ref: op://Production/MyApp/API_KEY
  - kind: dotenv # Contains PG_USER, PG_PASS, NODE_ENV
    path: .env.templates
    keys:
      PG_DSN: postgresql://{{ .PG_USER }}:{{ .PG_PASS }}@{{ .PG_HOST }}:5432/{{ .PG_DATABASE }}

There are several ambiguities need to be defined:

keys attribute behavior

Originally the keys meant to be a way for user to remap the secret, as well as selectively choose the secret to load. With this definition, the example above resulting the NODE_ENV from dotenv not loaded.

Keys override

What happened when there's another provider that also has PG_DSN ? Does this going to be overriden ? What about keys from previous providers? does it available on templating ?

To avoid the confusion, I think I would propose new providers called template where it basically do the templating

providers:
  - kind: 1password # Contains PG_USER, PG_PASS, PG_HOST, PG_DATABASE
    id: onepassword-prod
    ref: op://Production/MyApp/API_KEY
  - kind: dotenv # Contains PG_USER, PG_PASS, NODE_ENV
    path: .env.templates
  - kind: template # templates usually on the very last to ensure it can use all the variables from the previous one.
     keys:
      PG_DSN: postgresql://{{ .PG_USER }}:{{ .PG_PASS }}@{{ .PG_HOST }}:5432/{{ .PG_DATABASE }}

The template provider basically a simple go templating engine, that has the values from all the previous providers, and combine it. This way, we can simplify the implementation, does not break the previous behavior on the keys and providers order.

[prochac]

I love the idea of a separate provide 👍

I had a free weekend, so I was bored and wanted to try how hard it would be. And it was a good excuse to check the code. And I already had it open because of the CGO issue 😄

At this moment, I put the {{ .Env ... }} prefix there, so we could eventually add the cross-provider support later. But you have a point, the secrets (after using keys) should be unique, so the templating can be more straight forward.

Maybe it could even be a next step, outside the providers block. 🤔

---

I also checked my IDE, and this was actually the reason we didn't use Teller. Because with EnvFile it is possible to source the process environment. But It can't be chained. The env scripts don't see each other outputs. So, I wasn't successful with adding a middle step between Teller and my Go bin, to format secret envs to our config requirements.

[dirathea]

I would say let's stick to the template as provider for now. I am planning to have something else on the Top level definition like maybe talking about SSO or other behavioral like inherit.