# Daytona

Creating this PR as a set of notes for myself, even if it'd be nice to put this upstream.

## Background

Storing multiple keys in a single Vault path is a common use case. e.g. the following JSON can be stored in `secrets/myapp/dev/creds`:

{
  "DB_USER": "postgresuser",
  "DB_PASSWORD": "databasep@ssw0rdSuperSecret"
}

vault write secrets/myapp/dev/creds @example-secrets.json

This results in a single secret witih multiple keys (fields) under `secrets/myapp/dev/creds`.

vault read secrets/myapp/dev/creds

## Current Behavior: Singular mode

For a secret at Vault path `project/someapp/dev/creds`, which contains:

{
  "DB_USER": "postgresuser",
  "DB_PASSWORD": "databasep@ssw0rdSuperSecret"
}

| Daytona Env Var | Mode | Value | Resulting Key Name (Prefix) |
| --------------- | --------------- | -------------- | --- |
| `VAULT_SECRET_APP` | Singular | `project/someapp/dev/creds` | `creds_` (e.g. `creds_DB_USER`, `creds_DB_PASSWORD`) |
| `VAULT_SECRET_APP` | Singular | `project/someapp/dev/creds/` | Prefixed with `_` (e.g. `_DB_USER`, `_DB_PASSWORD`) |

**Resulting Key Name**: The string that will be used as the key when Daytona either loads your secrets as env vars or into a file. Daytona creats a prefix using the end of the path and an underscore. **IMPORTANT: If the path you pass to Daytona ends in `/`, then the end of the path is parsed as an empty string, leading to a prefix of `_`.**

### Example resulting key names:

#### `creds_`

e.g. as env variables (`-secret-env`)

creds_DB_USER=postgresuser
creds_DB_PASSWORD=databasep@ssw0rdSuperSecret

e.g. JSON file:

{
  "creds_DB_USER": "postgresuser"
  "creds_DB_PASSWORD": "databasep@ssw0rdSuperSecret"
}

#### `_`

**Daytona will always append an underscore, even to an empty string.**

e.g. as env variables (`-secret-env`)

_DB_USER=postgresuser
creds_DB_PASSWORD=databasep@ssw0rdSuperSecret

e.g. JSON file:

{
  "_DB_USER": "postgresuser"
  "_DB_PASSWORD": "databasep@ssw0rdSuperSecret"
}

## Practical Implication

This means that having a single secret with many keys (such as JSON) will:
* prefix your secrets in Daytona with AT LEAST an underscore, meaning that you would need to remap your env var names to the env var names that your application expects

---

## Inconsistency w/ terminology: Vault fields, names, keys

[JSON](https://www.json.org/json-en.html) officially calls the key name in the object k/v as "names", but in conversation "JSON keys" is widely used over "JSON name".

In the official Vault UI (1.7.1), you can toggle between the JSON representation of a single secret and a UI with input text forms for key and value.