Shared security responsibility

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
2. External tie-ins (authentication, container registries, Git providers, etc.)

Kubernetes and networking

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

Recommendations

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.

External tie-ins

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