mirror of
https://github.com/coder/coder.git
synced 2026-09-24 15:04:27 +08:00
Zach
85984ff142
Users can now disable a secret to stop it from being injected into workspaces without deleting it, and re-enable it later. Disabled secrets stay visible and editable everywhere they already appear. An enabled secret must have at least one injection target; a secret with no target can be stored only while disabled. Existing target-less secrets are migrated to disabled to preserve current behavior. Support spans the REST API, SDK, CLI, dashboard, and audit log.
134 lines
4.6 KiB
Markdown
134 lines
4.6 KiB
Markdown
# Secrets
|
|
|
|
Coder is open-minded about how you get your secrets into your workspaces. For
|
|
more information about how to use secrets and other security tips, visit our
|
|
guide to
|
|
[security best practices](../../tutorials/best-practices/security-best-practices.md#secrets).
|
|
|
|
Use this guide to configure how templates make secrets available to Coder
|
|
workspaces. To authenticate workspace provisioners with Coder, see the
|
|
<a href="../provisioners/index.md#authentication">provisioners documentation</a>.
|
|
For secret values that developers manage themselves, see
|
|
[User secrets](../../user-guides/user-secrets.md).
|
|
|
|
## Before you begin
|
|
|
|
Your first attempt to use secrets with Coder should be your local method. You
|
|
can do everything you can locally and more with your Coder workspace, so
|
|
whatever workflow and tools you already use to manage secrets may be brought
|
|
over.
|
|
|
|
Often, this workflow is simply:
|
|
|
|
1. Give your users their secrets in advance
|
|
1. Your users write them to a persistent file after they've built their
|
|
workspace
|
|
|
|
[Template parameters](../templates/extending-templates/parameters.md) are a
|
|
dangerous way to accept secrets. We show parameters in cleartext around the
|
|
product. Assume anyone with view access to a workspace can also see its
|
|
parameters.
|
|
|
|
## SSH Keys
|
|
|
|
Coder generates SSH key pairs for each user. This can be used as an
|
|
authentication mechanism for git providers or other tools. Within workspaces,
|
|
git will attempt to use this key within workspaces via the `$GIT_SSH_COMMAND`
|
|
environment variable.
|
|
|
|
Users can view their public key in their account settings:
|
|
|
|
|
|
|
|
> [!NOTE]
|
|
> SSH keys are never stored in Coder workspaces, and are fetched only when
|
|
> SSH is invoked. The keys are held in-memory and never written to disk.
|
|
|
|
## User secrets
|
|
|
|
User secrets are developer-managed values that Coder injects at workspace start.
|
|
If a user secret targets the same environment variable name or file path as a
|
|
template-provided variable or file, Coder injects the user secret into that
|
|
workspace. A secret can be disabled, in which case it is stored but not injected
|
|
until it is re-enabled. User secret values are covered by
|
|
[Database Encryption](./database-encryption.md) when it is enabled. See the
|
|
[User secrets guide](../../user-guides/user-secrets.md).
|
|
|
|
## Dynamic Secrets
|
|
|
|
Dynamic secrets are attached to the workspace lifecycle and automatically
|
|
injected into the workspace. With a little bit of up front template work, they
|
|
make life simpler for both the end user and the security team.
|
|
|
|
This method is limited to
|
|
[services with Terraform providers](https://registry.terraform.io/browse/providers),
|
|
which excludes obscure API providers.
|
|
|
|
Dynamic secrets can be implemented in your template code like so:
|
|
|
|
```tf
|
|
resource "twilio_iam_api_key" "api_key" {
|
|
account_sid = "ACXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
|
|
friendly_name = "Test API Key"
|
|
}
|
|
|
|
resource "coder_agent" "main" {
|
|
# ...
|
|
env = {
|
|
# Let users access the secret via $TWILIO_API_SECRET
|
|
TWILIO_API_SECRET = "${twilio_iam_api_key.api_key.secret}"
|
|
}
|
|
}
|
|
```
|
|
|
|
A catch-all variation of this approach is dynamically provisioning a cloud
|
|
service account (e.g
|
|
[GCP](https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_service_account_key#private_key))
|
|
for each workspace and then making the relevant secrets available via the
|
|
cloud's secret management system.
|
|
|
|
## Displaying Secrets
|
|
|
|
While you can inject secrets into the workspace via environment variables, you
|
|
can also show them in the Workspace UI with
|
|
[`coder_metadata`](https://registry.terraform.io/providers/coder/coder/latest/docs/resources/metadata).
|
|
|
|
|
|
|
|
Can be produced with
|
|
|
|
```tf
|
|
resource "twilio_iam_api_key" "api_key" {
|
|
account_sid = "ACXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
|
|
friendly_name = "Test API Key"
|
|
}
|
|
|
|
|
|
resource "coder_metadata" "twilio_key" {
|
|
resource_id = twilio_iam_api_key.api_key.id
|
|
item {
|
|
key = "Username"
|
|
value = "Administrator"
|
|
}
|
|
item {
|
|
key = "Password"
|
|
value = twilio_iam_api_key.api_key.secret
|
|
sensitive = true
|
|
}
|
|
}
|
|
```
|
|
|
|
## Secrets Management
|
|
|
|
For more advanced secrets management, you can use a secrets management tool to
|
|
store and retrieve secrets in your workspace. For example, you can use
|
|
[HashiCorp Vault](https://www.vaultproject.io/) to inject secrets into your
|
|
workspace.
|
|
|
|
Refer to our [HashiCorp Vault Integration](../integrations/vault.md) guide for
|
|
more information on how to integrate HashiCorp Vault with Coder.
|
|
|
|
## Next steps
|
|
|
|
- [Security - best practices](../../tutorials/best-practices/security-best-practices.md)
|