As the duplicate issue was closed, I am adding my suggestion here,

Secrets should be encrypted and can only be accessed by runtime(e.g., coder_agent)

Also, secrets can be set via CLI or UI

coder secrets set SECRET_NAME

A related example: https://fly.io/docs/reference/secrets/

An idea is providing a mechanism via Terraform to declare secrets, e.g.:

resource "coder_user_secret" "twilio" {
   id = "twilio"
}

which could then be consumed by another resource, e.g. the agent environment.

The advantages here are:

1. We can confirm with users which secrets the Template needs before creating a workspace
2. The template admin has a great deal of control over how secrets are used in the workspace

I think we should not brand these as secrets and call them user-level environment variables. This will spare us from hiding them in outputs, encrypting them in database.
For actual secrets we should recommend it using third party secret management solutions like, Hashicorp Vault, HVS (Hashicorp Vault Secrets), AWS Secret Manager etc.

i would help alot if we could configure Hashicorp Vault to store user level secrets.

@michaelbrewer Take a look at the two integrations we have with Hashicorp.

1. https://registry.coder.com/modules/vault-github
2. https://registry.coder.com/modules/hcp-vault-secrets

Using these modules, you should be able to fetch secrets from Hashicorp and use them for other terraform resources. As far as I know, there are still issues with using the fetched secrets in the provider definition.

@bpmct @kylecarbs, We should probably have a native vault integration to fetch and store deployment/user secrets. This has the added benefit of not worrying about the encryption, as we only fetch them when needed and do not store them in db.

As a nice to have, we can provide a UI to add/update/delete vault tokens.

This could be a Coder-Vault Enterprise feature where the user will link a Vault enterprise namespace with their Coder deployment using AppRole authentication or a totally new coder auth method.

They also offer a go-client to integarte.

We should probably have a native vault integration to fetch and store deployment/user secrets

IMHO I don't think this is the real pain here.
Tools like direnv can easily integrate ANY secret store in the workspace, a native Vault integration seems an overkill, and not very extensible as there are many other secret management solutions out there.

Back when Gitpod OSS is still alive I use this technique a lot, in my .envrc I can do:

# /workspace/.envrc

export ONE_SECRET=$(VAULT_TOKEN=<...> vault kv get -address <...> -field=password kv/path/to/my/secret)

export ANOTHER_SECRET=$(call whatever vault API to get my secret)

cat <<EOF > .env
YET_ANOTHER_SECRET=$(curl https://api.my-secret-store.com/v1/path/to/my/secret -H ...)
EOF

Simple, convenient, and elegant.

But the real pain here is I still need to manually transfer and setup my VAULT_TOKEN or some "root" access token to my online secret store, to fetch all my other "child" secrets, each time when I updated my workspace or created new workspace.

I believe the same pain also exists if user is using AWS/GCP online secret stores or using blackbox/sops/git-crypt to store secrets in the git repo, the user's access token or GPG key still needs to be transfered (or gpg-agent be forwarded), none of this is a joy.

The essence here is no matter what secret store you use, there must be at least one "root" secret needs to be inplace.

Also I don't think it is a good idea to put the secret fetching logic in Terraform templates, this would hugely prevent the re-use of templates, it not only force me to create a customized template for each of my project, it also does not help with the real pain here, where should the "root" secret go? How should I pass it in?

The best solution I can think of is just let Coder manage the secrets for user, then expose the secrets in workspace as env vars through Terraform tricks, or through CLI coder secrets get ..., let user decide
whatever they want with these secrets, either use them directly in the app, or use them to fetch more other secrets from another store (maybe with the help of direnv).

This might be the most flexible and simple solution.

Just my two cents, hope I didn't misunderstand the situation here.

Thank you, @ccll, for your input.

But the real pain here is I still need to manually transfer and setup my VAULT_TOKEN or some "root" access token to my online secret store, to fetch all my other "child" secrets, each time when I updated my workspace or created new workspace.

There is a module https://registry.coder.com/modules/vault-github, which can use the existing GitHub external auth to authenticate with the Vault and fetch secrets on the user's behalf.

The best solution I can think of is just let Coder manage the secrets for user, then expose the secrets in workspace as env vars through Terraform tricks, or through CLI coder secrets get ..., let user decide
whatever they want with these secrets, either use them directly in the app, or use them to fetch more other secrets from another store (maybe with the help of direnv).

The problem is that Coder has to implement a method to encrypt/decrypt secrets in the DB. That is why it was suggested that a third-party secret manager be used. Even if the coder manages the secrets, it's best to do that by talking to a 3rd party secret management solution. Secret management could be offloaded to the Coder to create/update/delete secrets on the user's behalf. Still, the secrets are never stored in the coder database but in the secret management solution.

If I may be so bold as to add my 2 pennies; while integrations with external secret stores would probably be a boon to Coder, storing and retrieving secrets from a database is not a novel problem. There are plenty of libraries out there that'd handle this very easily, and requiring users to use an external store is, as previously stated, overkill. We don't want to have developers need to go somewhere else to define a password before creating their workspace. Hell, we can already do that if we want, but it's not a great user experience.

We should also consider administrator access. If it's stored in Vault (or other secret store), the likelihood is admins will be able to retrieve those credentials. If they were properly hashed and stored in your database, it would be impossible to admins to get those secrets. Given users will likely use their own cloud / API credentials within their workspace, the possibility of abuse should also be considered.

We will almost certainly release Secrets w/o any hard requirement to use an external KMS or Vault but instead allow that as an option for increased security. It's hard to do security well w/o an external KMS because we'd either have to store the secrets plaintext in the DB (exposed to DB admins and backups) or accept an encryption key via configuration (tedious UX around rotation).

We don't want to have developers need to go somewhere else to define a password before creating their workspace. Hell, we can already do that if we want, but it's not a great user experience.

Passwords and API keys are indeed a solved problem but a bit different because the server never needs to provide the user with the plaintext representation of either. Instead, we just need to check that $$H(c)=H(c_1)$$ where $$H(c)$$ is stored on the server, never $$c$$.

"Native" Secrets will be sufficient for small teams and trial deployments. We'll push serious deployments towards a secure backend.

It would be nice to take the devcontainer spec into account.

Gitpod just dropped devcontainer support 2 weeks ago.
IMO coder lack way behind gitpod and daytona when it comes to devcontainer.

This issue would be a good excuse catch up...
First to fill the feature parity gap with daytona, gitpod, and hopefully codespaces.
If the devcontainer experience is improved my company may choose coder over other solutions.

We really like coder's flexibility, but the devcontainer UX is not fun at all.

User story - devcontainer secrets

// devcontainer.json
// [...]
"secrets": {
  "JF_TOKEN": {
    "description": "Jfrog artifactory token used by the post-start script.",
    "documentationUrl": "..."
  },
    "FOO_API_SECRET": {
    "description": "The required api key to target service foo..." 
    "documentationUrl": "..."
  }
}

Implementation ?

data "coder_parameter" "repository_url" {
  name          = "repository_url"
  order         = 1
  display_name  = "Repository URL"
  default       = "https://hostname/.../repo.git"
  description   = "The repository to use"
  mutable       = true
  # The server would use this field to know it's the repository url.
  # It could also guess the coder_external_auth using the hostname in the url 
  kind             = repository_url
  # Not a great UX, no drop down list of projects and repositories...
  # Maybe use separate fields instead...
}
data "coder_parameter" "target_branch" {
  name          = "target_branch"
  order         = 2
  display_name  = "Branch"
  description   = "This branch will be checked out on creation"
  mutable       = true
  kind = target_branch # point to some server side code that will query the git provider
}
data "coder_parameter" "devcontainer_config" {
  order         = 3
  name          = "devcontainer_config"
  display_name  = "Dev container configuration"
  description   = "Your workspace will use this configuration"
  default       = ".devcontainer/devcontainer.json"
  mutable       = true
  type          = "string"
  kind = devcontainer_config # Server will fetch the file right away to parse the secrets object. 
}
# we could add other `kinds` for validating `hostRequirements` ... ram, cpu, storage...
# eg: devcontainer_ram, devcontainer_cpu, devcontainer_storage...

// devcontainer.json
// [...]
"secrets": {
  "NAME_OF_SECRET_1": {
    "description": "This is the description of the secret.",
    "documentationUrl": "https://example.com/link/to/info"
  },
  "NAME_OF_SECRET_2": { }
}

  --secrets-file                    Path to a json file containing secret environment variables as key-value pairs.  [string]

// file /path/to/secrets.json
{
  "NAME_OF_SECRET_1": "secret-value1",
  "NAME_OF_SECRET_2": "secret-value2"
}

Happy to help if needed.

@ammario @matifali is there any plan to work on devcontainer support ?
(not talking about envbuilder but the server, agent, frontend and IDEs )

I haven't seen such a thing so far on github issues.

Thank you @ggjulio for the detailed user story. We will consider your input when designing this feature. This is definitely on our roadmap and we will keep trying to improve devcontainer compatibility.

Proposed an RFC at #17965