Skip to content

docs: add secrets #3057

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Jul 20, 2022
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
improve english moar
  • Loading branch information
ammario committed Jul 20, 2022
commit d5090293377141262bd6e6d69686fcd8135844eb
21 changes: 12 additions & 9 deletions docs/secrets.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,31 +5,36 @@ This article explains how to use secrets in a workspace. To authenticate the
workspace provisioner, see <a href="./templates/authentication">this</a>.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
workspace provisioner, see <a href="./templates/authentication">this</a>.
workspace provisioner, see <a href="./templates/authentication">Provider Authentication</a>.

</blockquote>

Coder takes an unopinionated stance to workspace secrets.
Coder is open-minded about how you get your secrets into your workspaces.

## Wait a minute...

Your first stab at 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 can be brought
whatever workflow and tools you already use to manage secrets may be brought
over.

For most, this workflow is simply:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
For most, this workflow is simply:
Often times, this workflow is simply:


1. Give your users their secrets in advance
1. They write them to a persistent file after
they've built a workspace
1. Your users write them to a persistent file after
they've built their workspace

<a href="./templates#parameters">Template parameters</a> 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.

## Dynamic Secrets

Dynamic secrets are attached to the workspace lifecycle and require no setup by
the end user.
Dynamic secrets are attached to the workspace lifecycle and automatically
injected into the workspace. For a little bit of up front template work,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
injected into the workspace. For a little bit of up front template work,
injected into the workspace. With a little bit of upfront template work,

they make life simpler for both the end user and the security team.

They can be implemented in your template code like so:
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:

```hcl
resource "twilio_iam_api_key" "api_key" {
Expand All @@ -46,8 +51,6 @@ resource "coder_agent" "dev" {
}
```

This method is limited to [services with Terraform providers](https://registry.terraform.io/browse/providers).

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.
Expand Down