title: Shared security responsibility

description:

Learn how Coder and its users carry security-related responsibilities.

To guarantee the security of the Coder workspace, which includes the entire

ecosystem of components needed to support the developer's user experience,

several parties must carry different responsibilities. While this is not an

exhaustive list, this article lists the security responsibilities for both Coder

and its users (specifically the site admin/site managers).

There are two categories of integration points for a Coder workspace:

1. Kubernetes and networking

1. External tie-ins (authentication, container registries, Git providers, etc.)

Like most software, Coder depends on the system on which it is installed to

provide some security boundaries. Coder is installed onto Kubernetes clusters

and includes expectations of how to cluster is configured. As such, changes to

the following aspects of your cluster may impact Coder's security and

performance:

- Storage

- Quotas

- Encryption

- Cloud access to volumes

- Depletion as denial of service

- PVC

- Ephemeral

- Networking

- Encryption (mTLS)

- Certificates

- TLS certificates presented by `coderd`

- TLS certificats presented by the applications with which Coder

interacts

- Boundaries (e.g., network policies)

- External interactions (ingress and egress)

- IP address depletion as denial of service

- Each workspace gets an IP address in the `pod` subset

- Each dev URL gets an IP address in the `services` subnet

- Kubernetes roles

- Service accounts for Coder to create pods

- Cluster admins (use of cluster admins can pose a security risk)

- Cloud access to the control plane

- Node security

- Upgrades to keep up with Kubernetes

- Access to node user accounts

- Cloud access to nodes

We recommend that you **deploy Coder to its own cluster**. With this option, the

security boundary is around the cluster, so things like PVC access, password

resets, and database access are clearly actions taken against Coder. Cluster

admins can perform any necessary action, while all others are constrained by

their Coder role.

Though you can deploy Coder to a shared cluster, the security boundary is

threaded through the components mentioned in the section above due to the

multiple applications present in the cluster.

Coder makes assumptions about how the following tie-ins are configured when

deploying security controls:

- Authentication provider

- Changing the authentication provider settings can render Coder insecure

- Site admins could convert a user authenticating via OIDC to built-in,

allowing the admin to impersonate the user

- Container registry

- The registry account used to access images should be a specific

Coder-only account so that Coder users can only pull approved images

- CVMs can only pull unauthenticated containers, which means that any user can

reference any container within the registry

- Git provider

- OAuth linkage allows Coder admins to perform actions as the linked Git user

- SSH keys generated by Coder and added to workspaces can be used to

circumvent 2FA to GitLab via Coder

- Git integration request both SSH and HTTPS access to function

- Access to all user repos must be added to a Coder workspace to clone private

dotfiles repos

- Coder doesn't allow the linking of multiple Git providers of the same type

- Disabling the OAuth linking account may cause a denial of service

{

"path": "./guides/admin/shared-security.md"

},