Skip to content

chore: add shared security responsibility doc #597

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.

Sign up for GitHub

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
Oct 14, 2021
Merged

chore: add shared security responsibility doc #597

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
bbb1791
chore: add shared security responsibility doc
Sep 13, 2021
0659039
fix URL
Sep 14, 2021
01bed04
apply changes due to review
Oct 13, 2021
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
87 changes: 87 additions & 0 deletions guides/admin/shared-security.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,87 @@
---
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.)

## 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
3 changes: 3 additions & 0 deletions manifest.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -326,6 +326,9 @@
{
"path": "./guides/admin/oidc-okta.md"
},
{
"path": "./guides/admin/shared-security.md"
},
{
"path": "./guides/admin/usage-monitoring.md"
}
Expand Down