allow to map a vault secret to an environment variable with a different name

[geekflyer]

Currently when using daytona as entrypoint via --secret-env it injects secrets as environment variables with the same name as the secret in vault. This forces the user to name vault secrets exactly as the application expects them, which is impractical for applications or services which expect very generic environment variable names like CLIENT_ID CLIENT_SECRET and whose source is not in control of the user. Writing secrets with the same generic name to vault makes it hard for developers to understand what a particular secret actually refers and where it is coming from (i.e. by which IDP a secret is issues).

For example let's say you have an app which expects an OIDC_SECRET. In your particular setup this secret may be issued by Auth0, and as such I'd prefer to write this secret as AUTH0_OIDC_SECRET to vault which makes it much clearer where this came from.

So what I'm proposing is to decouple the vault secret name from the environment name and introduce something like DAYTONA_SECRET_ENV_<suffix> to set the environment variable name.

For example:

VAULT_SECRET_AUTH0_OIDC_SECRET=/vault/path/to/secret/AUTH0_OIDC_SECRET
DAYTONA_SECRET_ENV_AUTH0_OIDC_SECRET=OIDC_SECRET

[broamski]

@geekflyer I think this can be trivially accomplished by referencing the original environment variable key and re-declaring to the variable of your choice:

- env:
  - name: OIDC_SECRET
    value: $(AUTH0_OIDC_SECRET)

[massenz]

while the above may work (I haven't tried it) it really makes the whole enterprise unnecessarily verbose (and confusing for anyone eventually having to make changes to the config, and not familiar with Daytona limitation).

It would really be great to have the SUFFIX to be used as the env var name, without having to resort to a workaround.

This is what I had originally reported in another issue (#99):

---

Furthermore, it seems that it is not possible to store the secret in an "arbitrarily" named env var, the secret key is always used. In the example above, we cannot store api_key in a TOKEN_API env var.

This is probably "expected behavior" (if one reads the README 3 or 4 times, while experimenting) but it's somewhat limiting:

└─( TOKEN_PATH=~/.vault-token \
VAULT_AUTH_ROLE=... \
VAULT_SECRET_PGUSER=secret/whatever/thing \
VAULT_VALUE_KEY_PGUSER=user \
daytona -k8s-auth -k8s-auth-mount="..." \
-address https://vault:8200 \
-secret-env -entrypoint -- env | grep -i user

....
{"level":"info","applicationName":"daytona","key":"VAULT_VALUE_KEY_PGUSER","value":"value","time":"2023-03-31T10:53:22-07:00","message":"Found an explicit vault value key, will read this value key instead of using the default"}

{"level":"info","applicationName":"daytona","var":"USER","time":"2023-03-31T10:53:22-07:00","message":"Set env var"}

VAULT_SECRET_PGUSER=secret/whatever/thing
VAULT_VALUE_KEY_PGUSER=user

user=myuser-...-zam.iam

while one would wish to have instead a PGUSER env var to be set.