Skip to content

Commit 23bb13c

Browse files
EdwardAngertEdwardAngert
authored andcommitted
add copy to orgs bp
1 parent 87273ca commit 23bb13c

File tree

1 file changed

+151
-0
lines changed

1 file changed

+151
-0
lines changed
Lines changed: 151 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,151 @@
1+
# Organizations - best practices
2+
3+
December 9, 2024
4+
5+
---
6+
7+
Coder [Organizations](../../admin/users/organizations.md) allow administrators
8+
finer control over groups, templates, and provisioners within their Coder
9+
deployment.
10+
11+
Organizations allow multiple platform teams to offer templates and
12+
infrastructure to their users instead of having them entirely managed in a
13+
centralized fashion.
14+
15+
Each organization can have its own unique admin and users can belong to multiple
16+
organizations, but every organization must have separate templates,
17+
provisioners, groups, and workspaces.
18+
19+
On this best practice page, we cover some of the ways you can use Organizations
20+
to make it easier to manage your groups smoothly.
21+
22+
## How Coder organizations work
23+
24+
Organizations are the hierarchical parent for templates, groups, and
25+
provisioners. Every new organization must have separate templates, provisioners,
26+
and groups.
27+
28+
Users can belong to multiple organizations while templates and provisioners
29+
cannot.
30+
31+
Organizations allow multiple platform teams to offer templates and
32+
infrastructure to their users instead of having them entirely managed in a
33+
centralized fashion.
34+
35+
## When to use organizations
36+
37+
Organizations increase the maintenance overhead of a Coder deployment, so we
38+
recommend that you only use them when necessary.
39+
40+
Use organizations when a separate group of users needs to manage their own
41+
templates and underlying infrastructure. If a group of users already has a
42+
separate, functional platform team willing to write templates or manage
43+
clusters, organizations may be a good fit.
44+
45+
### Organization use case examples
46+
47+
Here are a few examples for a fictional organization called MegaCo. It is
48+
deployed with Coder and has 1000 users in production. Today, MegaCo has a single
49+
(default) organization and a central platform team but is evaluating whether to
50+
use organizations for several use cases.
51+
52+
| **Use Case** | **Description** | **Good fit for organizations?** |
53+
| ------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- |
54+
| Mergers and acquisitions | Raptix, a 180-person startup recently acquired by MegaCo, has an independent cloud account, platform team, and Terraform modules and pipelines for deploying their code. They want to use Coder. | ✅ Organizations |
55+
| Independent cloud-native teams that manage their namespaces, images, and/or clusters | MegaCo has six teams responsible for their own dev, staging, and production Kubernetes clusters and frequently deploy & test their work with `kubectl` and `helm`.</br></br>They wish to hook up Coder to their cluster so they can write and manage IDE templates for connecting to the cluster with their IDE | ✅ Organizations |
56+
| Java monolith | MegaCo has identified that anyone developing the Java monolith is best served with a VM instead of a container/cloud-native environment.</br></br>However, the Java team is supported by MegaCo's central platform team. | ❌ Use instead:</br>A separate template and/or groups |
57+
| Off-shore contractors | MegaCo employs off-shore contractors but has not onboarded them onto Coder due to privacy concerns, data sovereignty rules, and latency considerations.</br></br>They considered a minimal, localized second deployment of Coder, but decided against it due to maintenance overhead. | ✅ Organizations + Workspace Proxies |
58+
| Dev teams | Dev teams often need to bring their requirements for dev environments, such as specific repositories and tools | ❌ Use instead:</br>Parameters, dev containers, and/or groups |
59+
| ML Platform Team & ML Developers | MegaCo's data platform team maintains a homegrown "MLBox" product for data environments with a GPU, Jupyter, etc.</br></br>This team is interested in migrating to Coder for improved cost-saving and auditing of environments, but they need to hook up their own cluster and cloud accounts. They also want their templates only to be accessible to a specific set of users. | ✅ Organizations |
60+
| Supporting developers in various regions | MegaCo's central platform team supports developers connecting from the East Coast, the West Coast, and Australia. These developers are working on the same projects but need low-latency access to their environments. | ❌ Use instead:</br>Provisioners and workspace proxies to support multiple regions on a single template |
61+
62+
## How to migrate to organizations
63+
64+
Since templates and workspaces cannot be moved nor can they belong to multiple
65+
organizations, we recommend that you deprecate your template
66+
[through the API](../../reference/api/templates.md#update-template-metadata-by-id)
67+
or [through the Coder CLI](../../reference/cli/templates_edit.md#--deprecated).
68+
When a template is deprecated, the admin prevents new workspaces from being
69+
created and developers are notified with a deprecation message which can link to
70+
an external wiki page on migration instructions.
71+
72+
Users can use a file transfer tool such as
73+
[rsync](https://linux.die.net/man/1/rsync) to migrate their files from one
74+
workspace to another.
75+
76+
## Provisioner Isolation and Zero Trust
77+
78+
In the organizations model, provisioners run in a separate
79+
cluster/infrastructure and have an isolated key to authenticate back with Coder.
80+
The provisioners have access to separate cloud resources that the control plane
81+
cannot access. Instead, the control plane sends simple "provisioner jobs" to the
82+
provisioner and the provisioner is responsible for executing the Terraform.
83+
84+
There are planned improvements to the troubleshooting provisioners process.
85+
Follow these GitHub issues for more details:
86+
87+
- [coder/coder:15048](https://github.com/coder/coder/issues/15048)
88+
- [coder/coder:15087](https://github.com/coder/coder/issues/15087)
89+
- [coder/coder:15192](https://github.com/coder/coder/issues/15192)
90+
91+
## Identity Provider (SSO) Sync
92+
93+
While the Coder UI or API can be used to assign specific users to organizations,
94+
this is discouraged. Instead, we recommend syncing the state from your identity
95+
provider such as Okta. A single claim from the identity provider (like
96+
`memberOf`) can be used to sync site-wide roles, organizations, groups, and
97+
organization roles.
98+
99+
### Planned enhancements
100+
101+
Organization and site-wide role sync is managed via server flags. We plan on
102+
changing this to runtime configuration so Coder does not need a re-deploy.
103+
104+
- Issue [coder/internal:86](https://github.com/coder/internal/issues/86)
105+
106+
Make all sync configurable via the dashboard UI.
107+
108+
- [coder/coder:15290](https://github.com/coder/coder/issues/15290)
109+
110+
Regex filters and mapping can be configured to ensure the proper resources are
111+
allocated in Coder. Learn more about [IDP sync](../../admin/users/idp-sync.md).
112+
113+
## Custom Roles
114+
115+
Custom roles are organization-scoped and can be used to limit access controls
116+
within an organization. Custom roles can be applied to the default organization.
117+
118+
Some examples of custom roles that can be created:
119+
120+
**Provisioner Admin**
121+
122+
- The user can deploy provisioners but not manage templates. This may be useful
123+
if automation is used to create and update templates in the organization.
124+
125+
**Template Editor**
126+
127+
- Inverse of provisioner admin: User can manage templates but not deploy
128+
provisioners. This may be useful if the provisioner and template are deployed
129+
via automation and users are allowed to edit them.
130+
131+
**Template Pusher**
132+
133+
- A system account that can push new templates from a git repo but cannot manage
134+
users or delete templates.
135+
136+
We’re interested in identifying new use cases for custom roles. Please
137+
[create a GitHub issue](https://github.com/coder/internal/issues/new?title=request%28orgs%29%3A+request+title+here&labels=["customer-feedback"]&body=please+enter+your+request+here)
138+
with your suggestion or request.
139+
140+
## Managing Organizations at Scale
141+
142+
Using ClickOps to onboard new organizations, set quotas, and SSO sync can be
143+
cumbersome, especially if you want to "seed" organizations with provisioners and
144+
starter templates.
145+
146+
Support for managing Organizations via the coderd Terrafom provider is planned
147+
so that this can be done declaratively and bulk updates to things like templates
148+
and quotas can be performed easily.
149+
150+
- Issue
151+
[coder/terraform-provider-coderd:39](https://github.com/coder/terraform-provider-coderd/issues/39)

0 commit comments

Comments
 (0)