|
| 1 | +# Secrets |
| 2 | + |
| 3 | +<blockquote class="info"> |
| 4 | +This article explains how to use secrets in a workspace. To authenticate the |
| 5 | +workspace provisioner, see <a href="/admin/auth">this</a>. |
| 6 | +</blockquote> |
| 7 | + |
| 8 | +Coder is open-minded about how you get your secrets into your workspaces. |
| 9 | + |
| 10 | +## Wait a minute... |
| 11 | + |
| 12 | +Your first stab at secrets with Coder should be your local method. You can do |
| 13 | +everything you can locally and more with your Coder workspace, so whatever |
| 14 | +workflow and tools you already use to manage secrets may be brought over. |
| 15 | + |
| 16 | +Often, this workflow is simply: |
| 17 | + |
| 18 | +1. Give your users their secrets in advance |
| 19 | +1. Your users write them to a persistent file after they've built their |
| 20 | + workspace |
| 21 | + |
| 22 | +[Template parameters](./templates/parameters.md) are a dangerous way to accept |
| 23 | +secrets. We show parameters in cleartext around the product. Assume anyone with |
| 24 | +view access to a workspace can also see its parameters. |
| 25 | + |
| 26 | +## SSH Keys |
| 27 | + |
| 28 | +Coder generates SSH key pairs for each user. This can be used as an |
| 29 | +authentication mechanism for git providers or other tools. Within workspaces, |
| 30 | +git will attempt to use this key within workspaces via the `$GIT_SSH_COMMAND` |
| 31 | +environment variable. |
| 32 | + |
| 33 | +Users can view their public key in their account settings: |
| 34 | + |
| 35 | + |
| 36 | + |
| 37 | +> Note: SSH keys are never stored in Coder workspaces, and are fetched only when |
| 38 | +> SSH is invoked. The keys are held in-memory and never written to disk. |
| 39 | +
|
| 40 | +## Dynamic Secrets |
| 41 | + |
| 42 | +Dynamic secrets are attached to the workspace lifecycle and automatically |
| 43 | +injected into the workspace. With a little bit of up front template work, they |
| 44 | +make life simpler for both the end user and the security team. |
| 45 | + |
| 46 | +This method is limited to |
| 47 | +[services with Terraform providers](https://registry.terraform.io/browse/providers), |
| 48 | +which excludes obscure API providers. |
| 49 | + |
| 50 | +Dynamic secrets can be implemented in your template code like so: |
| 51 | + |
| 52 | +```hcl |
| 53 | +resource "twilio_iam_api_key" "api_key" { |
| 54 | + account_sid = "ACXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" |
| 55 | + friendly_name = "Test API Key" |
| 56 | +} |
| 57 | +
|
| 58 | +resource "coder_agent" "main" { |
| 59 | + # ... |
| 60 | + env = { |
| 61 | + # Let users access the secret via $TWILIO_API_SECRET |
| 62 | + TWILIO_API_SECRET = "${twilio_iam_api_key.api_key.secret}" |
| 63 | + } |
| 64 | +} |
| 65 | +``` |
| 66 | + |
| 67 | +A catch-all variation of this approach is dynamically provisioning a cloud |
| 68 | +service account (e.g |
| 69 | +[GCP](https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_service_account_key#private_key)) |
| 70 | +for each workspace and then making the relevant secrets available via the |
| 71 | +cloud's secret management system. |
| 72 | + |
| 73 | +## Displaying Secrets |
| 74 | + |
| 75 | +While you can inject secrets into the workspace via environment variables, you |
| 76 | +can also show them in the Workspace UI with |
| 77 | +[`coder_metadata`](https://registry.terraform.io/providers/coder/coder/latest/docs/resources/metadata). |
| 78 | + |
| 79 | + |
| 80 | + |
| 81 | +Can be produced with |
| 82 | + |
| 83 | +```hcl |
| 84 | +resource "twilio_iam_api_key" "api_key" { |
| 85 | + account_sid = "ACXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" |
| 86 | + friendly_name = "Test API Key" |
| 87 | +} |
| 88 | +
|
| 89 | +
|
| 90 | +resource "coder_metadata" "twilio_key" { |
| 91 | + resource_id = twilio_iam_api_key.api_key.id |
| 92 | + item { |
| 93 | + key = "secret" |
| 94 | + value = twilio_iam_api_key.api_key.secret |
| 95 | + sensitive = true |
| 96 | + } |
| 97 | +} |
| 98 | +``` |
0 commit comments