Can’t write env variable for single secret key, if not also written to file

[jonnylangefeld]

When following the docs to write a single secret it is written to use

VAULT_SECRET_THING=secret/whatever/thing
DAYTONA_SECRET_DESTINATION_THING=/tmp/top-secret
VAULT_VALUE_KEY_THING=api_key

If one would only like to get env variables and not write a secret to a file, one would expect to not set DAYTONA_SECRET_DESTINATION_THING, and set SECRET_ENV='true'.

However, that doesn't work because the condition that wraps the case to write a single secret expects a destination path:

daytona/pkg/secrets/secrets.go

Lines 288 to 290 in f9f7dce

	if !sd.plural && sd.outputDestination != "" {
	singleValueKey := defaultKeyName
	if envKey := os.Getenv(secretValueKeyPrefix + sd.secretID); envKey != "" {

[massenz]

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_SECRET_DESTINATION_PGUSER=/dev/null \
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
DAYTONA_SECRET_DESTINATION_PGUSER=whatever

user=myuser-...-zam.iam

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

[jonnylangefeld]

@massenz it looks like since your comment is a separate issue to the initially described bug in this issue @broamski is suggesting to tackle you comment in a separate issue. So I think it makes sense to file it as new one.

[massenz]

Thanks - turns out this had already been reported in #41 (I have added my comment there) but given that one has been sitting for 3 years, I'm assuming it's not going to happen.