From 69d7b0e531748b21b29b1adfbf77d8ff848be0f6 Mon Sep 17 00:00:00 2001 From: Abigail McCarthy <20771501+a-mccarthy@users.noreply.github.com> Date: Sun, 25 Aug 2024 23:01:59 -0400 Subject: [PATCH 1/3] Update auth.md update auth.md for IA suggestions --- docs/admin/auth.md | 31 ++++++++++++++++++++++++++++--- 1 file changed, 28 insertions(+), 3 deletions(-) diff --git a/docs/admin/auth.md b/docs/admin/auth.md index 78f46fe2c69f9..2c8edd427580b 100644 --- a/docs/admin/auth.md +++ b/docs/admin/auth.md @@ -1,14 +1,35 @@ # Authentication -. +``` +Insert an overview of authentication, include + +1. Who is authenticating into what +2. Users that are able to set up authentication. +3. Include a link to get more details about User roles, https://coder.com/docs/admin/users. +4. When its important to set up Authentication, right after install? everytime a new user is added? When deploying to a new enviroment (dev, production)? + +``` -By default, Coder is accessible via password authentication. Coder does not +> By default, Coder is accessible via password authentication. Coder does not recommend using password authentication in production, and recommends using an authentication provider with properly configured multi-factor authentication (MFA). It is your responsibility to ensure the auth provider enforces MFA correctly. -The following steps explain how to set up GitHub OAuth or OpenID Connect. +``` +Depending on how long and distinct this information is, I'd recommend breaking the Authentication topic up into different pages to give readers information on how to set up the different Authentication methods. So, break up Password, Github, and OpenID Connect into seprate pages under Authentication heading and list the pages from most to least used or recommend authentication type. + +Other sections to include in an Authentication section: +* Any limitations or precautions to take if you change they Authentication method on a running platform + +``` + +## Password authentication + +``` +Add information about how password authentication works. Its mentioned in the note that recommends not to use password authentication in production, but the concept is never explained. +``` + ## GitHub @@ -508,6 +529,10 @@ Below are some details specific to individual OIDC providers. ### Keycloak +``` +Is there any testing or versioning that important to highlight for this information? Include a link to an related of set up docs for Keycloak. +``` + The access_type parameter has two possible values: "online" and "offline." By default, the value is set to "offline". This means that when a user authenticates using OIDC, the application requests offline access to the user's From 297de762c0e09fbd5e42f06fd0485146d2f7b61b Mon Sep 17 00:00:00 2001 From: Abigail McCarthy <20771501+a-mccarthy@users.noreply.github.com> Date: Sun, 25 Aug 2024 23:04:03 -0400 Subject: [PATCH 2/3] Update secrets.md --- docs/secrets.md | 33 +++++++++++++++------------------ 1 file changed, 15 insertions(+), 18 deletions(-) diff --git a/docs/secrets.md b/docs/secrets.md index c6057f146a190..adadc625574f5 100644 --- a/docs/secrets.md +++ b/docs/secrets.md @@ -1,27 +1,24 @@ -# Secrets +# Secrets in a workspace
This article explains how to use secrets in a workspace. To authenticate the -workspace provisioner, see this. +workspace provisioner, see the article on Authentication.Coder is open-minded about how you get your secrets into your workspaces. +This means you can continue to use the same workflow and tools you already use to manage secrets locally in your Coder workspace. -## 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 may be brought over. - -Often, this workflow is simply: +Usually this workflow looks like, 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/parameters.md) are a dangerous way to accept -secrets. We show parameters in cleartext around the product. Assume anyone with + +
+Its strongly recommended that you do not use template parameters to accept +secrets. Parameters are shown in cleartext in Coder. Assume anyone with view access to a workspace can also see its parameters. +## SSH Keys @@ -30,13 +27,13 @@ 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. +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. + 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. - ## Dynamic Secrets Dynamic secrets are attached to the workspace lifecycle and automatically @@ -47,7 +44,7 @@ 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: +Add dynamic secrets into your template code using the following: ```hcl resource "twilio_iam_api_key" "api_key" { @@ -65,8 +62,8 @@ resource "coder_agent" "main" { ``` 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)) +service account, for example +[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. From 29d8b0f1de069437875cf8e984fac73c16620bee Mon Sep 17 00:00:00 2001 From: Abigail McCarthy <20771501+a-mccarthy@users.noreply.github.com> Date: Mon, 26 Aug 2024 05:47:15 -0400 Subject: [PATCH 3/3] Update secrets.md --- docs/secrets.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/secrets.md b/docs/secrets.md index adadc625574f5..749f5d84f9c23 100644 --- a/docs/secrets.md +++ b/docs/secrets.md @@ -6,7 +6,7 @@ workspace provisioner, see the article on Authentication Coder is open-minded about how you get your secrets into your workspaces. -This means you can continue to use the same workflow and tools you already use to manage secrets locally in your Coder workspace. +This means you can continue to use the same workflow and tools you already use to manage secrets locally can be brought over to your Coder workspace. Usually this workflow looks like,