mirror of
https://github.com/coder/coder.git
synced 2026-09-24 15:04:27 +08:00
docs: restructure docs (#14421)
Closes #13434 Supersedes #14182 --------- Co-authored-by: Ethan <39577870+ethanndickson@users.noreply.github.com> Co-authored-by: Ethan Dickson <ethan@coder.com> Co-authored-by: Ben Potter <ben@coder.com> Co-authored-by: Stephen Kirby <58410745+stirby@users.noreply.github.com> Co-authored-by: Stephen Kirby <me@skirby.dev> Co-authored-by: EdwardAngert <17991901+EdwardAngert@users.noreply.github.com> Co-authored-by: Edward Angert <EdwardAngert@users.noreply.github.com>
This commit is contained in:
Muhammad Atif Ali
co-authored by
Ethan
Ethan Dickson
Ben Potter
Stephen Kirby
Stephen Kirby
EdwardAngert
Edward Angert
Ethan
Ethan Dickson
Ben Potter
Stephen Kirby
Stephen Kirby
EdwardAngert
Edward Angert
parent
288df75686
commit
419eba5fb6
@@ -0,0 +1,18 @@
|
||||
# Integrations
|
||||
|
||||
Coder is highly extensible and is not limited to the platforms outlined in these
|
||||
docs. The control plane can be provisioned on any VM or container compute, and
|
||||
workspaces can include any Terraform resource. See our
|
||||
[architecture diagram](../infrastructure/architecture.md) for more details.
|
||||
|
||||
You can host your deployment on almost any infrastructure. To learn how, read
|
||||
our [installation guides](../../install/index.md).
|
||||
|
||||
<children></children>
|
||||
|
||||
The following resources may help as you're deploying Coder.
|
||||
|
||||
- [Coder packages: one-click install on cloud providers](https://github.com/coder/packages)
|
||||
- [Deploy Coder offline](../../install/offline.md)
|
||||
- [Supported resources (Terraform registry)](https://registry.terraform.io)
|
||||
- [Writing custom templates](../templates/index.md)
|
||||
@@ -0,0 +1,163 @@
|
||||
# Island Browser Integration
|
||||
|
||||
<div>
|
||||
<a href="https://github.com/ericpaulsen" style="text-decoration: none; color: inherit;">
|
||||
<span style="vertical-align:middle;">Eric Paulsen</span>
|
||||
<img src="https://github.com/ericpaulsen.png" width="24px" height="24px" style="vertical-align:middle; margin: 0px;"/>
|
||||
</a>
|
||||
</div>
|
||||
April 24, 2024
|
||||
|
||||
---
|
||||
|
||||
[Island](https://www.island.io/) is an enterprise-grade browser, offering a
|
||||
Chromium-based experience similar to popular web browsers like Chrome and Edge.
|
||||
It includes built-in security features for corporate applications and data,
|
||||
aiming to bridge the gap between consumer-focused browsers and the security
|
||||
needs of the enterprise.
|
||||
|
||||
Coder natively integrates with Island's feature set, which include data loss
|
||||
protection (DLP), application awareness, browser session recording, and single
|
||||
sign-on (SSO). This guide intends to document these feature categories and how
|
||||
they apply to your Coder deployment.
|
||||
|
||||
## General Configuration
|
||||
|
||||
### Create an Application Group for Coder
|
||||
|
||||
We recommend creating an Application Group specific to Coder in the Island
|
||||
Management console. This Application Group object will be referenced when
|
||||
creating browser policies.
|
||||
|
||||
[See the Island documentation for creating an Application Group](https://documentation.island.io/docs/create-and-configure-an-application-group-object).
|
||||
|
||||
## Advanced Data Loss Protection
|
||||
|
||||
Integrate Island's advanced data loss prevention (DLP) capabilities with Coder's
|
||||
cloud development environment (CDE), enabling you to control the “last mile”
|
||||
between developers’ CDE and their local devices, ensuring that sensitive IP
|
||||
remains in your centralized environment.
|
||||
|
||||
### Block cut, copy, paste, printing, screen share
|
||||
|
||||
1. [Create a Data Sandbox Profile](https://documentation.island.io/docs/create-and-configure-a-data-sandbox-profile)
|
||||
|
||||
1. Configure the following actions to allow/block (based on your security
|
||||
requirements):
|
||||
|
||||
- Screenshot and Screen Share
|
||||
- Printing
|
||||
- Save Page
|
||||
- Clipboard Limitations
|
||||
|
||||
1. [Create a Policy Rule](https://documentation.island.io/docs/create-and-configure-a-policy-rule-general)
|
||||
to apply the Data Sandbox Profile
|
||||
|
||||
1. Define the Coder Application group as the Destination Object
|
||||
|
||||
1. Define the Data Sandbox Profile as the Action in the Last Mile Protection
|
||||
section
|
||||
|
||||
### Conditionally allow copy on Coder's CLI authentication page
|
||||
|
||||
1. [Create a URL Object](https://documentation.island.io/docs/create-and-configure-a-policy-rule-general)
|
||||
with the following configuration:
|
||||
|
||||
- **Include**
|
||||
- **URL type**: Wildcard
|
||||
- **URL address**: `coder.example.com/cli-auth`
|
||||
- **Casing**: Insensitive
|
||||
|
||||
1. [Create a Data Sandbox Profile](https://documentation.island.io/docs/create-and-configure-a-data-sandbox-profile)
|
||||
|
||||
1. Configure action to allow copy/paste
|
||||
|
||||
1. [Create a Policy Rule](https://documentation.island.io/docs/create-and-configure-a-policy-rule-general)
|
||||
to apply the Data Sandbox Profile
|
||||
|
||||
1. Define the URL Object you created as the Destination Object
|
||||
|
||||
1. Define the Data Sandbox Profile as the Action in the Last Mile Protection
|
||||
section
|
||||
|
||||
### Prevent file upload/download from the browser
|
||||
|
||||
1. Create a Protection Profiles for both upload/download
|
||||
|
||||
- [Upload documentation](https://documentation.island.io/docs/create-and-configure-an-upload-protection-profile)
|
||||
- [Download documentation](https://documentation.island.io/v1/docs/en/create-and-configure-a-download-protection-profile)
|
||||
|
||||
1. [Create a Policy Rule](https://documentation.island.io/docs/create-and-configure-a-policy-rule-general)
|
||||
to apply the Protection Profiles
|
||||
|
||||
1. Define the Coder Application group as the Destination Object
|
||||
|
||||
1. Define the applicable Protection Profile as the Action in the Data Protection
|
||||
section
|
||||
|
||||
### Scan files for sensitive data
|
||||
|
||||
1. [Create a Data Loss Prevention scanner](https://documentation.island.io/docs/create-a-data-loss-prevention-scanner)
|
||||
|
||||
1. [Create a Policy Rule](https://documentation.island.io/docs/create-and-configure-a-policy-rule-general)
|
||||
to apply the DLP Scanner
|
||||
|
||||
1. Define the Coder Application group as the Destination Object
|
||||
|
||||
1. Define the DLP Scanner as the Action in the Data Protection section
|
||||
|
||||
## Application Awareness and Boundaries
|
||||
|
||||
Ensure that Coder is only accessed through the Island browser, guaranteeing that
|
||||
your browser-level DLP policies are always enforced, and developers can’t
|
||||
sidestep such policies simply by using another browser.
|
||||
|
||||
### Configure browser enforcement, conditional access policies
|
||||
|
||||
1. Create a conditional access policy for your configured identity provider.
|
||||
|
||||
> Note: the configured IdP must be the same for both Coder and Island
|
||||
|
||||
- [Azure Active Directory/Entra ID](https://documentation.island.io/docs/configure-browser-enforcement-for-island-with-azure-ad#create-and-apply-a-conditional-access-policy)
|
||||
- [Okta](https://documentation.island.io/docs/configure-browser-enforcement-for-island-with-okta)
|
||||
- [Google](https://documentation.island.io/docs/configure-browser-enforcement-for-island-with-google-enterprise)
|
||||
|
||||
## Browser Activity Logging
|
||||
|
||||
Govern and audit in-browser terminal and IDE sessions using Island, such as
|
||||
screenshots, mouse clicks, and keystrokes.
|
||||
|
||||
### Activity Logging Module
|
||||
|
||||
1. [Create an Activity Logging Profile](https://documentation.island.io/docs/create-and-configure-an-activity-logging-profile)
|
||||
|
||||
Supported browser events include:
|
||||
|
||||
- Web Navigation
|
||||
- File Download
|
||||
- File Upload
|
||||
- Clipboard/Drag & Drop
|
||||
- Print
|
||||
- Save As
|
||||
- Screenshots
|
||||
- Mouse Clicks
|
||||
- Keystrokes
|
||||
|
||||
1. [Create a Policy Rule](https://documentation.island.io/docs/create-and-configure-a-policy-rule-general)
|
||||
to apply the Activity Logging Profile
|
||||
|
||||
1. Define the Coder Application group as the Destination Object
|
||||
|
||||
1. Define the Activity Logging Profile as the Action in the Security &
|
||||
Visibility section
|
||||
|
||||
## Identity-aware logins (SSO)
|
||||
|
||||
Integrate Island's identity management system with Coder's authentication
|
||||
mechanisms to enable identity-aware logins.
|
||||
|
||||
### Configure single sign-on (SSO) seamless authentication between Coder and Island
|
||||
|
||||
Configure the same identity provider (IdP) for both your Island and Coder
|
||||
deployment. Upon initial login to the Island browser, the user's session token
|
||||
will automatically be passed to Coder and authenticate their Coder session.
|
||||
@@ -0,0 +1,175 @@
|
||||
# JFrog Artifactory Integration
|
||||
|
||||
<div>
|
||||
<a href="https://github.com/matifali" style="text-decoration: none; color: inherit;">
|
||||
<span style="vertical-align:middle;">M Atif Ali</span>
|
||||
<img src="https://github.com/matifali.png" width="24px" height="24px" style="vertical-align:middle; margin: 0px;"/>
|
||||
</a>
|
||||
</div>
|
||||
January 24, 2024
|
||||
|
||||
---
|
||||
|
||||
Use Coder and JFrog Artifactory together to secure your development environments
|
||||
without disturbing your developers' existing workflows.
|
||||
|
||||
This guide will demonstrate how to use JFrog Artifactory as a package registry
|
||||
within a workspace.
|
||||
|
||||
## Requirements
|
||||
|
||||
- A JFrog Artifactory instance
|
||||
- 1:1 mapping of users in Coder to users in Artifactory by email address or
|
||||
username
|
||||
- Repositories configured in Artifactory for each package manager you want to
|
||||
use
|
||||
|
||||
## Provisioner Authentication
|
||||
|
||||
The most straight-forward way to authenticate your template with Artifactory is
|
||||
by using our official Coder [modules](https://registry.coder.com). We publish
|
||||
two type of modules that automate the JFrog Artifactory and Coder integration.
|
||||
|
||||
1. [JFrog-OAuth](https://registry.coder.com/modules/jfrog-oauth)
|
||||
2. [JFrog-Token](https://registry.coder.com/modules/jfrog-token)
|
||||
|
||||
### JFrog-OAuth
|
||||
|
||||
This module is usable by JFrog self-hosted (on-premises) Artifactory as it
|
||||
requires configuring a custom integration. This integration benefits from
|
||||
Coder's [external-auth](https://coder.com/docs/admin/external-auth) feature and
|
||||
allows each user to authenticate with Artifactory using an OAuth flow and issues
|
||||
user-scoped tokens to each user.
|
||||
|
||||
To set this up, follow these steps:
|
||||
|
||||
1. Modify your Helm chart `values.yaml` for JFrog Artifactory to add,
|
||||
|
||||
```yaml
|
||||
artifactory:
|
||||
enabled: true
|
||||
frontend:
|
||||
extraEnvironmentVariables:
|
||||
- name: JF_FRONTEND_FEATURETOGGLER_ACCESSINTEGRATION
|
||||
value: "true"
|
||||
access:
|
||||
accessConfig:
|
||||
integrations-enabled: true
|
||||
integration-templates:
|
||||
- id: "1"
|
||||
name: "CODER"
|
||||
redirect-uri: "https://CODER_URL/external-auth/jfrog/callback"
|
||||
scope: "applied-permissions/user"
|
||||
```
|
||||
|
||||
> Note Replace `CODER_URL` with your Coder deployment URL, e.g.,
|
||||
> <coder.example.com>
|
||||
|
||||
2. Create a new Application Integration by going to
|
||||
<https://JFROG_URL/ui/admin/configuration/integrations/new> and select the
|
||||
Application Type as the integration you created in step 1.
|
||||
|
||||
|
||||
|
||||
3. Add a new
|
||||
[external authentication](https://coder.com/docs/admin/external-auth) to
|
||||
Coder by setting these env variables,
|
||||
|
||||
```env
|
||||
# JFrog Artifactory External Auth
|
||||
CODER_EXTERNAL_AUTH_1_ID="jfrog"
|
||||
CODER_EXTERNAL_AUTH_1_TYPE="jfrog"
|
||||
CODER_EXTERNAL_AUTH_1_CLIENT_ID="YYYYYYYYYYYYYYY"
|
||||
CODER_EXTERNAL_AUTH_1_CLIENT_SECRET="XXXXXXXXXXXXXXXXXXX"
|
||||
CODER_EXTERNAL_AUTH_1_DISPLAY_NAME="JFrog Artifactory"
|
||||
CODER_EXTERNAL_AUTH_1_DISPLAY_ICON="/icon/jfrog.svg"
|
||||
CODER_EXTERNAL_AUTH_1_AUTH_URL="https://JFROG_URL/ui/authorization"
|
||||
CODER_EXTERNAL_AUTH_1_SCOPES="applied-permissions/user"
|
||||
```
|
||||
|
||||
> Note Replace `JFROG_URL` with your JFrog Artifactory base URL, e.g.,
|
||||
> <example.jfrog.io>
|
||||
|
||||
4. Create or edit a Coder template and use the
|
||||
[JFrog-OAuth](https://registry.coder.com/modules/jfrog-oauth) module to
|
||||
configure the integration.
|
||||
|
||||
```tf
|
||||
module "jfrog" {
|
||||
source = "registry.coder.com/modules/jfrog-oauth/coder"
|
||||
version = "1.0.0"
|
||||
agent_id = coder_agent.example.id
|
||||
jfrog_url = "https://jfrog.example.com"
|
||||
configure_code_server = true # this depends on the code-server
|
||||
username_field = "username" # If you are using GitHub to login to both Coder and Artifactory, use username_field = "username"
|
||||
package_managers = {
|
||||
"npm": "npm",
|
||||
"go": "go",
|
||||
"pypi": "pypi"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### JFrog-Token
|
||||
|
||||
This module makes use of the
|
||||
[Artifactory terraform provider](https://registry.terraform.io/providers/jfrog/artifactory/latest/docs)
|
||||
and an admin-scoped token to create user-scoped tokens for each user by matching
|
||||
their Coder email or username with Artifactory. This can be used for both SaaS
|
||||
and self-hosted(on-premises) Artifactory instances.
|
||||
|
||||
To set this up, follow these steps:
|
||||
|
||||
1. Get a JFrog access token from your Artifactory instance. The token must be an
|
||||
[admin token](https://registry.terraform.io/providers/jfrog/artifactory/latest/docs#access-token)
|
||||
with scope `applied-permissions/admin`.
|
||||
2. Create or edit a Coder template and use the
|
||||
[JFrog-Token](https://registry.coder.com/modules/jfrog-token) module to
|
||||
configure the integration and pass the admin token. It is recommended to
|
||||
store the token in a sensitive terraform variable to prevent it from being
|
||||
displayed in plain text in the terraform state.
|
||||
|
||||
```tf
|
||||
variable "artifactory_access_token" {
|
||||
type = string
|
||||
sensitive = true
|
||||
}
|
||||
|
||||
module "jfrog" {
|
||||
source = "registry.coder.com/modules/jfrog-token/coder"
|
||||
version = "1.0.0"
|
||||
agent_id = coder_agent.example.id
|
||||
jfrog_url = "https://example.jfrog.io"
|
||||
configure_code_server = true # this depends on the code-server
|
||||
artifactory_access_token = var.artifactory_access_token
|
||||
package_managers = {
|
||||
"npm": "npm",
|
||||
"go": "go",
|
||||
"pypi": "pypi"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<blockquote class="info">
|
||||
The admin-level access token is used to provision user tokens and is never exposed to
|
||||
developers or stored in workspaces.
|
||||
</blockquote>
|
||||
|
||||
If you do not want to use the official modules, you can check example template
|
||||
that uses Docker as the underlying compute
|
||||
[here](https://github.com/coder/coder/tree/main/examples/jfrog/docker). The same
|
||||
concepts apply to all compute types.
|
||||
|
||||
## Offline Deployments
|
||||
|
||||
See the
|
||||
[offline deployments](../templates/extending-templates/modules.md#offline-installations)
|
||||
section for instructions on how to use coder-modules in an offline environment
|
||||
with Artifactory.
|
||||
|
||||
## More reading
|
||||
|
||||
- See the full example template
|
||||
[here](https://github.com/coder/coder/tree/main/examples/jfrog/docker).
|
||||
- To serve extensions from your own VS Code Marketplace, check out
|
||||
[code-marketplace](https://github.com/coder/code-marketplace#artifactory-storage).
|
||||
@@ -0,0 +1,70 @@
|
||||
# Integrating JFrog Xray with Coder Kubernetes Workspaces
|
||||
|
||||
<div>
|
||||
<a href="https://github.com/matifali" style="text-decoration: none; color: inherit;">
|
||||
<span style="vertical-align:middle;">Muhammad Atif Ali</span>
|
||||
<img src="https://github.com/matifali.png" width="24px" height="24px" style="vertical-align:middle; margin: 0px;"/>
|
||||
</a>
|
||||
</div>
|
||||
March 17, 2024
|
||||
|
||||
---
|
||||
|
||||
This guide will walk you through the process of adding
|
||||
[JFrog Xray](https://jfrog.com/xray/) integration to Coder Kubernetes workspaces
|
||||
using Coder's [JFrog Xray Integration](https://github.com/coder/coder-xray).
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- A self-hosted JFrog Platform instance.
|
||||
- Kubernetes workspaces running on Coder.
|
||||
|
||||
## Deploying the Coder - JFrog Xray Integration
|
||||
|
||||
1. Create a JFrog Platform
|
||||
[Access Token](https://jfrog.com/help/r/jfrog-platform-administration-documentation/access-tokens)
|
||||
with a user that has the read
|
||||
[permission](https://jfrog.com/help/r/jfrog-platform-administration-documentation/permissions)
|
||||
for the repositories you want to scan.
|
||||
1. Create a Coder [token](../../reference/cli/tokens_create.md#tokens-create)
|
||||
with a user that has the [`owner`](../users#roles) role.
|
||||
1. Create Kubernetes secrets for the JFrog Xray and Coder tokens.
|
||||
|
||||
```bash
|
||||
kubectl create secret generic coder-token --from-literal=coder-token='<token>'
|
||||
kubectl create secret generic jfrog-token --from-literal=user='<user>' --from-literal=token='<token>'
|
||||
```
|
||||
|
||||
1. Deploy the Coder - JFrog Xray integration.
|
||||
|
||||
```bash
|
||||
helm repo add coder-xray https://helm.coder.com/coder-xray
|
||||
|
||||
helm upgrade --install coder-xray coder-xray/coder-xray \
|
||||
--namespace coder-xray \
|
||||
--create-namespace \
|
||||
--set namespace="<CODER_WORKSPACES_NAMESPACE>" \ # Replace with your Coder workspaces namespace
|
||||
--set coder.url="https://<your-coder-url>" \
|
||||
--set coder.secretName="coder-token" \
|
||||
--set artifactory.url="https://<your-artifactory-url>" \
|
||||
--set artifactory.secretName="jfrog-token"
|
||||
```
|
||||
|
||||
### Updating the Coder template
|
||||
|
||||
[`coder-xray`](https://github.com/coder/coder-xray) will scan all kubernetes
|
||||
workspaces in the specified namespace. It depends on the `image` available in
|
||||
Artifactory and indexed by Xray. To ensure that the images are available in
|
||||
Artifactory, update the Coder template to use the Artifactory registry.
|
||||
|
||||
```tf
|
||||
image = "<ARTIFACTORY_URL>/<REPO>/<IMAGE>:<TAG>"
|
||||
```
|
||||
|
||||
> **Note**: To authenticate with the Artifactory registry, you may need to
|
||||
> create a
|
||||
> [Docker config](https://jfrog.com/help/r/jfrog-artifactory-documentation/docker-advanced-topics)
|
||||
> and use it in the `imagePullSecrets` field of the kubernetes pod. See this
|
||||
> [guide](../../tutorials/image-pull-secret.md) for more information.
|
||||
|
||||
|
||||
@@ -0,0 +1,78 @@
|
||||
# Kubernetes event logs
|
||||
|
||||
To stream Kubernetes events into your workspace startup logs, you can use
|
||||
Coder's [`coder-logstream-kube`](https://github.com/coder/coder-logstream-kube)
|
||||
tool. `coder-logstream-kube` provides useful information about the workspace pod
|
||||
or deployment, such as:
|
||||
|
||||
- Causes of pod provisioning failures, or why a pod is stuck in a pending state.
|
||||
- Visibility into when pods are OOMKilled, or when they are evicted.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
`coder-logstream-kube` works best with the
|
||||
[`kubernetes_deployment`](https://registry.terraform.io/providers/hashicorp/kubernetes/latest/docs/resources/deployment)
|
||||
Terraform resource, which requires the `coder` service account to have
|
||||
permission to create deployments. For example, if you use
|
||||
[Helm](../../install/kubernetes.md#install-coder-with-helm) to install Coder,
|
||||
you should set `coder.serviceAccount.enableDeployments=true` in your
|
||||
`values.yaml`
|
||||
|
||||
```diff
|
||||
coder:
|
||||
serviceAccount:
|
||||
workspacePerms: true
|
||||
- enableDeployments: false
|
||||
+ enableDeployments: true
|
||||
annotations: {}
|
||||
name: coder
|
||||
```
|
||||
|
||||
> Note: This is only required for Coder versions < 0.28.0, as this will be the
|
||||
> default value for Coder versions >= 0.28.0
|
||||
|
||||
## Installation
|
||||
|
||||
Install the `coder-logstream-kube` helm chart on the cluster where the
|
||||
deployment is running.
|
||||
|
||||
```shell
|
||||
helm repo add coder-logstream-kube https://helm.coder.com/logstream-kube
|
||||
helm install coder-logstream-kube coder-logstream-kube/coder-logstream-kube \
|
||||
--namespace coder \
|
||||
--set url=<your-coder-url-including-http-or-https>
|
||||
```
|
||||
|
||||
## Example logs
|
||||
|
||||
Here is an example of the logs you can expect to see in the workspace startup
|
||||
logs:
|
||||
|
||||
### Normal pod deployment
|
||||
|
||||
|
||||
|
||||
### Wrong image
|
||||
|
||||
|
||||
|
||||
### Kubernetes quota exceeded
|
||||
|
||||
|
||||
|
||||
### Pod crash loop
|
||||
|
||||
|
||||
|
||||
## How it works
|
||||
|
||||
Kubernetes provides an
|
||||
[informers](https://pkg.go.dev/k8s.io/client-go/informers) API that streams pod
|
||||
and event data from the API server.
|
||||
|
||||
coder-logstream-kube listens for pod creation events with containers that have
|
||||
the CODER_AGENT_TOKEN environment variable set. All pod events are streamed as
|
||||
logs to the Coder API using the agent token for authentication. For more
|
||||
details, see the
|
||||
[coder-logstream-kube](https://github.com/coder/coder-logstream-kube)
|
||||
repository.
|
||||
@@ -0,0 +1,237 @@
|
||||
# Additional clusters
|
||||
|
||||
With Coder, you can deploy workspaces in additional Kubernetes clusters using
|
||||
different
|
||||
[authentication methods](https://registry.terraform.io/providers/hashicorp/kubernetes/latest/docs#authentication)
|
||||
in the Terraform provider.
|
||||
|
||||
|
||||
|
||||
## Option 1) Kubernetes contexts and kubeconfig
|
||||
|
||||
First, create a kubeconfig file with
|
||||
[multiple contexts](https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/).
|
||||
|
||||
```shell
|
||||
kubectl config get-contexts
|
||||
|
||||
CURRENT NAME CLUSTER
|
||||
workspaces-europe-west2-c workspaces-europe-west2-c
|
||||
* workspaces-us-central1-a workspaces-us-central1-a
|
||||
```
|
||||
|
||||
### Kubernetes control plane
|
||||
|
||||
If you deployed Coder on Kubernetes, you can attach a kubeconfig as a secret.
|
||||
|
||||
This assumes Coder is deployed on the `coder` namespace and your kubeconfig file
|
||||
is in ~/.kube/config.
|
||||
|
||||
```shell
|
||||
kubectl create secret generic kubeconfig-secret -n coder --from-file=~/.kube/config
|
||||
```
|
||||
|
||||
Modify your helm values to mount the secret:
|
||||
|
||||
```yaml
|
||||
coder:
|
||||
# ...
|
||||
volumes:
|
||||
- name: "kubeconfig-mount"
|
||||
secret:
|
||||
secretName: "kubeconfig-secret"
|
||||
volumeMounts:
|
||||
- name: "kubeconfig-mount"
|
||||
mountPath: "/mnt/secrets/kube"
|
||||
readOnly: true
|
||||
```
|
||||
|
||||
[Upgrade Coder](../../install/kubernetes.md#upgrading-coder-via-helm) with these
|
||||
new values.
|
||||
|
||||
### VM control plane
|
||||
|
||||
If you deployed Coder on a VM, copy the kubeconfig file to
|
||||
`/home/coder/.kube/config`.
|
||||
|
||||
### Create a Coder template
|
||||
|
||||
You can start from our
|
||||
[example template](https://github.com/coder/coder/tree/main/examples/templates/kubernetes).
|
||||
From there, add
|
||||
[template parameters](../templates/extending-templates/parameters.md) to allow
|
||||
developers to pick their desired cluster.
|
||||
|
||||
```tf
|
||||
# main.tf
|
||||
|
||||
data "coder_parameter" "kube_context" {
|
||||
name = "kube_context"
|
||||
display_name = "Cluster"
|
||||
default = "workspaces-us-central1-a"
|
||||
mutable = false
|
||||
option {
|
||||
name = "US Central"
|
||||
icon = "/emojis/1f33d.png"
|
||||
value = "workspaces-us-central1-a"
|
||||
}
|
||||
option {
|
||||
name = "Europe West"
|
||||
icon = "/emojis/1f482.png"
|
||||
value = "workspaces-europe-west2-c"
|
||||
}
|
||||
}
|
||||
|
||||
provider "kubernetes" {
|
||||
config_path = "~/.kube/config" # or /mnt/secrets/kube/config for Kubernetes
|
||||
config_context = data.coder_parameter.kube_context.value
|
||||
}
|
||||
```
|
||||
|
||||
## Option 2) Kubernetes ServiceAccounts
|
||||
|
||||
Alternatively, you can authenticate with remote clusters with ServiceAccount
|
||||
tokens. Coder can store these secrets on your behalf with
|
||||
[managed Terraform variables](../templates/extending-templates/variables.md).
|
||||
|
||||
Alternatively, these could also be fetched from Kubernetes secrets or even
|
||||
[Hashicorp Vault](https://registry.terraform.io/providers/hashicorp/vault/latest/docs/data-sources/generic_secret).
|
||||
|
||||
This guide assumes you have a `coder-workspaces` namespace on your remote
|
||||
cluster. Change the namespace accordingly.
|
||||
|
||||
### Create a ServiceAccount
|
||||
|
||||
Run this command against your remote cluster to create a ServiceAccount, Role,
|
||||
RoleBinding, and token:
|
||||
|
||||
```shell
|
||||
kubectl apply -n coder-workspaces -f - <<EOF
|
||||
apiVersion: v1
|
||||
kind: ServiceAccount
|
||||
metadata:
|
||||
name: coder-v2
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: coder-v2
|
||||
annotations:
|
||||
kubernetes.io/service-account.name: coder-v2
|
||||
type: kubernetes.io/service-account-token
|
||||
---
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: Role
|
||||
metadata:
|
||||
name: coder-v2
|
||||
rules:
|
||||
- apiGroups: ["", "apps", "networking.k8s.io"]
|
||||
resources: ["persistentvolumeclaims", "pods", "deployments", "services", "secrets", "pods/exec","pods/log", "events", "networkpolicies", "serviceaccounts"]
|
||||
verbs: ["create", "get", "list", "watch", "update", "patch", "delete", "deletecollection"]
|
||||
- apiGroups: ["metrics.k8s.io", "storage.k8s.io"]
|
||||
resources: ["pods", "storageclasses"]
|
||||
verbs: ["get", "list", "watch"]
|
||||
---
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: RoleBinding
|
||||
metadata:
|
||||
name: coder-v2
|
||||
subjects:
|
||||
- kind: ServiceAccount
|
||||
name: coder-v2
|
||||
roleRef:
|
||||
kind: Role
|
||||
name: coder-v2
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
EOF
|
||||
```
|
||||
|
||||
The output should be similar to:
|
||||
|
||||
```text
|
||||
serviceaccount/coder-v2 created
|
||||
secret/coder-v2 created
|
||||
role.rbac.authorization.k8s.io/coder-v2 created
|
||||
rolebinding.rbac.authorization.k8s.io/coder-v2 created
|
||||
```
|
||||
|
||||
### 2. Modify the Kubernetes template
|
||||
|
||||
You can start from our
|
||||
[example template](https://github.com/coder/coder/tree/main/examples/templates/kubernetes).
|
||||
|
||||
```tf
|
||||
variable "host" {
|
||||
description = "Cluster host address"
|
||||
sensitive = true
|
||||
}
|
||||
|
||||
variable "cluster_ca_certificate" {
|
||||
description = "Cluster CA certificate (base64 encoded)"
|
||||
sensitive = true
|
||||
}
|
||||
|
||||
variable "token" {
|
||||
description = "Cluster CA token (base64 encoded)"
|
||||
sensitive = true
|
||||
}
|
||||
|
||||
variable "namespace" {
|
||||
description = "Namespace"
|
||||
}
|
||||
|
||||
provider "kubernetes" {
|
||||
host = var.host
|
||||
cluster_ca_certificate = base64decode(var.cluster_ca_certificate)
|
||||
token = base64decode(var.token)
|
||||
}
|
||||
```
|
||||
|
||||
### Create Coder template with managed variables
|
||||
|
||||
Fetch the values from the secret and pass them to Coder. This should work on
|
||||
macOS and Linux.
|
||||
|
||||
To get the cluster address:
|
||||
|
||||
```shell
|
||||
kubectl cluster-info
|
||||
Kubernetes control plane is running at https://example.domain:6443
|
||||
|
||||
export CLUSTER_ADDRESS=https://example.domain:6443
|
||||
```
|
||||
|
||||
To fetch the CA certificate and token:
|
||||
|
||||
```shell
|
||||
export CLUSTER_CA_CERTIFICATE=$(kubectl get secrets coder-v2 -n coder-workspaces -o jsonpath="{.data.ca\.crt}")
|
||||
|
||||
export CLUSTER_SERVICEACCOUNT_TOKEN=$(kubectl get secrets coder-v2 -n coder-workspaces -o jsonpath="{.data.token}")
|
||||
```
|
||||
|
||||
Create the template with these values:
|
||||
|
||||
```shell
|
||||
coder templates push \
|
||||
--variable host=$CLUSTER_ADDRESS \
|
||||
--variable cluster_ca_certificate=$CLUSTER_CA_CERTIFICATE \
|
||||
--variable token=$CLUSTER_SERVICEACCOUNT_TOKEN \
|
||||
--variable namespace=coder-workspaces
|
||||
```
|
||||
|
||||
If you're on a Windows machine (or if one of the commands fail), try grabbing
|
||||
the values manually:
|
||||
|
||||
```shell
|
||||
# Get cluster API address
|
||||
kubectl cluster-info
|
||||
|
||||
# Get cluster CA and token (base64 encoded)
|
||||
kubectl get secrets coder-service-account-token -n coder-workspaces -o jsonpath="{.data}"
|
||||
|
||||
coder templates push \
|
||||
--variable host=API_ADDRESS \
|
||||
--variable cluster_ca_certificate=CLUSTER_CA_CERTIFICATE \
|
||||
--variable token=CLUSTER_SERVICEACCOUNT_TOKEN \
|
||||
--variable namespace=coder-workspaces
|
||||
```
|
||||
@@ -0,0 +1,23 @@
|
||||
# Provisioning with OpenTofu
|
||||
|
||||
<!-- Keeping this in as a placeholder for supporting OpenTofu. We should fix support for custom terraform binaries ASAP. -->
|
||||
|
||||
> ⚠️ This guide is a work in progress. We do not officially support using custom
|
||||
> Terraform binaries in your Coder deployment. To track progress on the work,
|
||||
> see this related [Github Issue](https://github.com/coder/coder/issues/12009).
|
||||
|
||||
Coder deployments support any custom Terraform binary, including
|
||||
[OpenTofu](https://opentofu.org/docs/) - an open source alternative to
|
||||
Terraform.
|
||||
|
||||
> You can read more about OpenTofu and Hashicorp's licensing in our
|
||||
> [blog post](https://coder.com/blog/hashicorp-license) on the Terraform
|
||||
> licensing changes.
|
||||
|
||||
## Using a custom Terraform binary
|
||||
|
||||
You can change your deployment custom Terraform binary as long as it is in
|
||||
`PATH` and is within the
|
||||
[supported versions](https://github.com/coder/coder/blob/f57ce97b5aadd825ddb9a9a129bb823a3725252b/provisioner/terraform/install.go#L22-L25).
|
||||
The hardcoded version check ensures compatibility with our
|
||||
[example templates](https://github.com/coder/coder/tree/main/examples/templates).
|
||||
@@ -0,0 +1,186 @@
|
||||
# Prometheus
|
||||
|
||||
Coder exposes many metrics which can be consumed by a Prometheus server, and
|
||||
give insight into the current state of a live Coder deployment.
|
||||
|
||||
If you don't have an Prometheus server installed, you can follow the Prometheus
|
||||
[Getting started](https://prometheus.io/docs/prometheus/latest/getting_started/)
|
||||
guide.
|
||||
|
||||
## Enable Prometheus metrics
|
||||
|
||||
Coder server exports metrics via the HTTP endpoint, which can be enabled using
|
||||
either the environment variable `CODER_PROMETHEUS_ENABLE` or the flag
|
||||
`--prometheus-enable`.
|
||||
|
||||
The Prometheus endpoint address is `http://localhost:2112/` by default. You can
|
||||
use either the environment variable `CODER_PROMETHEUS_ADDRESS` or the flag
|
||||
`--prometheus-address <network-interface>:<port>` to select a different listen
|
||||
address.
|
||||
|
||||
If `coder server --prometheus-enable` is started locally, you can preview the
|
||||
metrics endpoint in your browser or by using curl:
|
||||
|
||||
```console
|
||||
$ curl http://localhost:2112/
|
||||
# HELP coderd_api_active_users_duration_hour The number of users that have been active within the last hour.
|
||||
# TYPE coderd_api_active_users_duration_hour gauge
|
||||
coderd_api_active_users_duration_hour 0
|
||||
...
|
||||
```
|
||||
|
||||
### Kubernetes deployment
|
||||
|
||||
The Prometheus endpoint can be enabled in the
|
||||
[Helm chart's](https://github.com/coder/coder/tree/main/helm) `values.yml` by
|
||||
setting the environment variable `CODER_PROMETHEUS_ADDRESS` to `0.0.0.0:2112`.
|
||||
The environment variable `CODER_PROMETHEUS_ENABLE` will be enabled
|
||||
automatically. A Service Endpoint will not be exposed; if you need to expose the
|
||||
Prometheus port on a Service, (for example, to use a `ServiceMonitor`), create a
|
||||
separate headless service instead:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: coder-prom
|
||||
namespace: coder
|
||||
spec:
|
||||
clusterIP: None
|
||||
ports:
|
||||
- name: prom-http
|
||||
port: 2112
|
||||
protocol: TCP
|
||||
targetPort: 2112
|
||||
selector:
|
||||
app.kubernetes.io/instance: coder
|
||||
app.kubernetes.io/name: coder
|
||||
type: ClusterIP
|
||||
```
|
||||
|
||||
### Prometheus configuration
|
||||
|
||||
To allow Prometheus to scrape the Coder metrics, you will need to create a
|
||||
`scape_config` in your `prometheus.yml` file, or in the Prometheus Helm chart
|
||||
values. Below is an example `scrape_config`:
|
||||
|
||||
```yaml
|
||||
scrape_configs:
|
||||
- job_name: "coder"
|
||||
scheme: "http"
|
||||
static_configs:
|
||||
- targets: ["<ip>:2112"] # replace with the the IP address of the Coder pod or server
|
||||
labels:
|
||||
apps: "coder"
|
||||
```
|
||||
|
||||
To use the Kubernetes Prometheus operator to scrape metrics, you will need to
|
||||
create a `ServiceMonitor` in your Coder deployment namespace. Below is an
|
||||
example `ServiceMonitor`:
|
||||
|
||||
```yaml
|
||||
apiVersion: monitoring.coreos.com/v1
|
||||
kind: ServiceMonitor
|
||||
metadata:
|
||||
name: coder-service-monitor
|
||||
namespace: coder
|
||||
spec:
|
||||
endpoints:
|
||||
- port: prometheus-http
|
||||
interval: 10s
|
||||
scrapeTimeout: 10s
|
||||
selector:
|
||||
matchLabels:
|
||||
app.kubernetes.io/name: coder
|
||||
```
|
||||
|
||||
## Available metrics
|
||||
|
||||
`coderd_agentstats_*` metrics must first be enabled with the flag
|
||||
`--prometheus-collect-agent-stats`, or the environment variable
|
||||
`CODER_PROMETHEUS_COLLECT_AGENT_STATS` before they can be retrieved from the
|
||||
deployment. They will always be available from the agent.
|
||||
|
||||
<!-- Code generated by 'make docs/admin/integrations/prometheus.md'. DO NOT EDIT -->
|
||||
|
||||
| Name | Type | Description | Labels |
|
||||
| ------------------------------------------------------------- | --------- | -------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ |
|
||||
| `agent_scripts_executed_total` | counter | Total number of scripts executed by the Coder agent. Includes cron scheduled scripts. | `agent_name` `success` `template_name` `username` `workspace_name` |
|
||||
| `coderd_agents_apps` | gauge | Agent applications with statuses. | `agent_name` `app_name` `health` `username` `workspace_name` |
|
||||
| `coderd_agents_connection_latencies_seconds` | gauge | Agent connection latencies in seconds. | `agent_name` `derp_region` `preferred` `username` `workspace_name` |
|
||||
| `coderd_agents_connections` | gauge | Agent connections with statuses. | `agent_name` `lifecycle_state` `status` `tailnet_node` `username` `workspace_name` |
|
||||
| `coderd_agents_up` | gauge | The number of active agents per workspace. | `template_name` `username` `workspace_name` |
|
||||
| `coderd_agentstats_connection_count` | gauge | The number of established connections by agent | `agent_name` `username` `workspace_name` |
|
||||
| `coderd_agentstats_connection_median_latency_seconds` | gauge | The median agent connection latency | `agent_name` `username` `workspace_name` |
|
||||
| `coderd_agentstats_currently_reachable_peers` | gauge | The number of peers (e.g. clients) that are currently reachable over the encrypted network. | `agent_name` `connection_type` `template_name` `username` `workspace_name` |
|
||||
| `coderd_agentstats_rx_bytes` | gauge | Agent Rx bytes | `agent_name` `username` `workspace_name` |
|
||||
| `coderd_agentstats_session_count_jetbrains` | gauge | The number of session established by JetBrains | `agent_name` `username` `workspace_name` |
|
||||
| `coderd_agentstats_session_count_reconnecting_pty` | gauge | The number of session established by reconnecting PTY | `agent_name` `username` `workspace_name` |
|
||||
| `coderd_agentstats_session_count_ssh` | gauge | The number of session established by SSH | `agent_name` `username` `workspace_name` |
|
||||
| `coderd_agentstats_session_count_vscode` | gauge | The number of session established by VSCode | `agent_name` `username` `workspace_name` |
|
||||
| `coderd_agentstats_startup_script_seconds` | gauge | The number of seconds the startup script took to execute. | `agent_name` `success` `template_name` `username` `workspace_name` |
|
||||
| `coderd_agentstats_tx_bytes` | gauge | Agent Tx bytes | `agent_name` `username` `workspace_name` |
|
||||
| `coderd_api_active_users_duration_hour` | gauge | The number of users that have been active within the last hour. | |
|
||||
| `coderd_api_concurrent_requests` | gauge | The number of concurrent API requests. | |
|
||||
| `coderd_api_concurrent_websockets` | gauge | The total number of concurrent API websockets. | |
|
||||
| `coderd_api_request_latencies_seconds` | histogram | Latency distribution of requests in seconds. | `method` `path` |
|
||||
| `coderd_api_requests_processed_total` | counter | The total number of processed API requests | `code` `method` `path` |
|
||||
| `coderd_api_websocket_durations_seconds` | histogram | Websocket duration distribution of requests in seconds. | `path` |
|
||||
| `coderd_api_workspace_latest_build` | gauge | The latest workspace builds with a status. | `status` |
|
||||
| `coderd_api_workspace_latest_build_total` | gauge | DEPRECATED: use coderd_api_workspace_latest_build instead | `status` |
|
||||
| `coderd_insights_applications_usage_seconds` | gauge | The application usage per template. | `application_name` `slug` `template_name` |
|
||||
| `coderd_insights_parameters` | gauge | The parameter usage per template. | `parameter_name` `parameter_type` `parameter_value` `template_name` |
|
||||
| `coderd_insights_templates_active_users` | gauge | The number of active users of the template. | `template_name` |
|
||||
| `coderd_license_active_users` | gauge | The number of active users. | |
|
||||
| `coderd_license_limit_users` | gauge | The user seats limit based on the active Coder license. | |
|
||||
| `coderd_license_user_limit_enabled` | gauge | Returns 1 if the current license enforces the user limit. | |
|
||||
| `coderd_metrics_collector_agents_execution_seconds` | histogram | Histogram for duration of agents metrics collection in seconds. | |
|
||||
| `coderd_oauth2_external_requests_rate_limit` | gauge | The total number of allowed requests per interval. | `name` `resource` |
|
||||
| `coderd_oauth2_external_requests_rate_limit_next_reset_unix` | gauge | Unix timestamp of the next interval | `name` `resource` |
|
||||
| `coderd_oauth2_external_requests_rate_limit_remaining` | gauge | The remaining number of allowed requests in this interval. | `name` `resource` |
|
||||
| `coderd_oauth2_external_requests_rate_limit_reset_in_seconds` | gauge | Seconds until the next interval | `name` `resource` |
|
||||
| `coderd_oauth2_external_requests_rate_limit_total` | gauge | DEPRECATED: use coderd_oauth2_external_requests_rate_limit instead | `name` `resource` |
|
||||
| `coderd_oauth2_external_requests_rate_limit_used` | gauge | The number of requests made in this interval. | `name` `resource` |
|
||||
| `coderd_oauth2_external_requests_total` | counter | The total number of api calls made to external oauth2 providers. 'status_code' will be 0 if the request failed with no response. | `name` `source` `status_code` |
|
||||
| `coderd_provisionerd_job_timings_seconds` | histogram | The provisioner job time duration in seconds. | `provisioner` `status` |
|
||||
| `coderd_provisionerd_jobs_current` | gauge | The number of currently running provisioner jobs. | `provisioner` |
|
||||
| `coderd_workspace_builds_total` | counter | The number of workspaces started, updated, or deleted. | `action` `owner_email` `status` `template_name` `template_version` `workspace_name` |
|
||||
| `coderd_workspace_latest_build_status` | gauge | The current workspace statuses by template, transition, and owner. | `status` `template_name` `template_version` `workspace_owner` `workspace_transition` |
|
||||
| `go_gc_duration_seconds` | summary | A summary of the pause duration of garbage collection cycles. | |
|
||||
| `go_goroutines` | gauge | Number of goroutines that currently exist. | |
|
||||
| `go_info` | gauge | Information about the Go environment. | `version` |
|
||||
| `go_memstats_alloc_bytes` | gauge | Number of bytes allocated and still in use. | |
|
||||
| `go_memstats_alloc_bytes_total` | counter | Total number of bytes allocated, even if freed. | |
|
||||
| `go_memstats_buck_hash_sys_bytes` | gauge | Number of bytes used by the profiling bucket hash table. | |
|
||||
| `go_memstats_frees_total` | counter | Total number of frees. | |
|
||||
| `go_memstats_gc_sys_bytes` | gauge | Number of bytes used for garbage collection system metadata. | |
|
||||
| `go_memstats_heap_alloc_bytes` | gauge | Number of heap bytes allocated and still in use. | |
|
||||
| `go_memstats_heap_idle_bytes` | gauge | Number of heap bytes waiting to be used. | |
|
||||
| `go_memstats_heap_inuse_bytes` | gauge | Number of heap bytes that are in use. | |
|
||||
| `go_memstats_heap_objects` | gauge | Number of allocated objects. | |
|
||||
| `go_memstats_heap_released_bytes` | gauge | Number of heap bytes released to OS. | |
|
||||
| `go_memstats_heap_sys_bytes` | gauge | Number of heap bytes obtained from system. | |
|
||||
| `go_memstats_last_gc_time_seconds` | gauge | Number of seconds since 1970 of last garbage collection. | |
|
||||
| `go_memstats_lookups_total` | counter | Total number of pointer lookups. | |
|
||||
| `go_memstats_mallocs_total` | counter | Total number of mallocs. | |
|
||||
| `go_memstats_mcache_inuse_bytes` | gauge | Number of bytes in use by mcache structures. | |
|
||||
| `go_memstats_mcache_sys_bytes` | gauge | Number of bytes used for mcache structures obtained from system. | |
|
||||
| `go_memstats_mspan_inuse_bytes` | gauge | Number of bytes in use by mspan structures. | |
|
||||
| `go_memstats_mspan_sys_bytes` | gauge | Number of bytes used for mspan structures obtained from system. | |
|
||||
| `go_memstats_next_gc_bytes` | gauge | Number of heap bytes when next garbage collection will take place. | |
|
||||
| `go_memstats_other_sys_bytes` | gauge | Number of bytes used for other system allocations. | |
|
||||
| `go_memstats_stack_inuse_bytes` | gauge | Number of bytes in use by the stack allocator. | |
|
||||
| `go_memstats_stack_sys_bytes` | gauge | Number of bytes obtained from system for stack allocator. | |
|
||||
| `go_memstats_sys_bytes` | gauge | Number of bytes obtained from system. | |
|
||||
| `go_threads` | gauge | Number of OS threads created. | |
|
||||
| `process_cpu_seconds_total` | counter | Total user and system CPU time spent in seconds. | |
|
||||
| `process_max_fds` | gauge | Maximum number of open file descriptors. | |
|
||||
| `process_open_fds` | gauge | Number of open file descriptors. | |
|
||||
| `process_resident_memory_bytes` | gauge | Resident memory size in bytes. | |
|
||||
| `process_start_time_seconds` | gauge | Start time of the process since unix epoch in seconds. | |
|
||||
| `process_virtual_memory_bytes` | gauge | Virtual memory size in bytes. | |
|
||||
| `process_virtual_memory_max_bytes` | gauge | Maximum amount of virtual memory available in bytes. | |
|
||||
| `promhttp_metric_handler_requests_in_flight` | gauge | Current number of scrapes being served. | |
|
||||
| `promhttp_metric_handler_requests_total` | counter | Total number of scrapes by HTTP status code. | `code` |
|
||||
|
||||
<!-- End generated by 'make docs/admin/integrations/prometheus.md'. -->
|
||||
@@ -0,0 +1,48 @@
|
||||
# Integrating HashiCorp Vault with Coder
|
||||
|
||||
<div>
|
||||
<a href="https://github.com/matifali" style="text-decoration: none; color: inherit;">
|
||||
<span style="vertical-align:middle;">Muhammad Atif Ali</span>
|
||||
<img src="https://github.com/matifali.png" width="24px" height="24px" style="vertical-align:middle; margin: 0px;"/>
|
||||
</a>
|
||||
</div>
|
||||
August 05, 2024
|
||||
|
||||
---
|
||||
|
||||
This guide will walk you through the process of adding
|
||||
[HashiCorp Vault](https://www.vaultproject.io/) integration to Coder workspaces.
|
||||
|
||||
Coder makes it easy to integrate HashiCorp Vault with your workspaces by
|
||||
providing official terraform modules to integrate Vault with Coder. This guide
|
||||
will show you how to use these modules to integrate HashiCorp Vault with Coder.
|
||||
|
||||
## `vault-github`
|
||||
|
||||
[`vault-github`](https://registry.coder.com/modules/vault-github) is a terraform
|
||||
module that allows you to authenticate with Vault using a GitHub token. This
|
||||
modules uses the existing GitHub [external authentication](../external-auth.md)
|
||||
to get the token and authenticate with Vault.
|
||||
|
||||
To use this module, you need to add the following code to your terraform
|
||||
configuration:
|
||||
|
||||
```tf
|
||||
module "vault" {
|
||||
source = "registry.coder.com/modules/vault-github/coder"
|
||||
version = "1.0.7"
|
||||
agent_id = coder_agent.example.id
|
||||
vault_addr = "https://vault.example.com"
|
||||
coder_github_auth_id = "my-github-auth-id"
|
||||
}
|
||||
```
|
||||
|
||||
This module will install and authenticate the `vault` CLI in your Coder
|
||||
workspace.
|
||||
|
||||
Users then can use the `vault` CLI to interact with the vault, e.g., to het a kv
|
||||
secret,
|
||||
|
||||
```shell
|
||||
vault kv get -namespace=YOUR_NAMESPACE -mount=MOUNT_NAME SECRET_NAME
|
||||
```
|
||||
Reference in New Issue
Block a user