mirror of
https://github.com/coder/coder.git
synced 2026-11-01 21:13:14 +08:00
J. Scott Miller
76962273d8
`default_org_member_roles` was only settable through Terraform or a raw
`PATCH /api/v2/organizations/{organization}`. This adds a CLI
equivalent.
```console
coder organizations edit --org acme --default-org-member-roles organization-workspace-access,organization-template-admin
coder organizations edit --org acme --default-org-member-roles "" # grant no roles
```
- The flag replaces the organization's current list rather than adding
to it. It accepts a comma-separated list, may be repeated, and
de-duplicates. An empty value removes every role.
- Removing a role prompts for confirmation, listing the roles being
removed, unless `-y` is passed. Adding roles applies without a prompt.
- The resulting set is printed, so no follow-up command is needed to
confirm what was applied.
- The organization is chosen with `-O/--org` or `$CODER_ORGANIZATION`,
and is implicit when the caller belongs to exactly one organization.
The org update endpoint is behind `FeatureMultipleOrganizations`, so the
command is enterprise/premium only. Non-built-in roles are rejected by
the server, and `dbauthz` already prevents a caller from setting a
default they could not assign to a member individually.
<details>
<summary>Implementation notes</summary>
## Shape
`codersdk.UpdateOrganizationRequest.DefaultOrgMemberRoles *[]string` and
the enterprise `patchOrganization` handler already existed; only the CLI
was missing, and nothing in `cli/` called `UpdateOrganization` at all.
No server or SDK changes are needed.
`organizations edit` follows the partial-update pattern of `coder groups
edit`: check `ParsedFlags().Changed(...)`, populate only the fields the
user set, and leave the rest nil so the handler preserves them. Passing
no flags is an error.
Two earlier shapes were tried and dropped:
- **A `default-org-member-roles` entry in the `organizations settings`
registry.** Every sibling entry unmarshals an SDK type that maps 1:1 to
a dedicated endpoint; this field has no such endpoint. Reusing
`UpdateOrganizationRequest` for the piped JSON meant a stray `name`
field could rename the org, and the documented `show > file`, edit, `set
< file` workflow failed on the default organization, whose name is
reserved.
- **A `--default-org-member-roles` flag on `organizations create`.**
`create` cannot set display name, description, or icon either, so a
roles-only flag there is asymmetric. It would also require
`CreateOrganizationRequest` to grow the field plus server-side
validation.
## Known sharp edge
`serpent.StringArray` resets its slice when any flag value is empty, so
`--default-org-member-roles a --default-org-member-roles ""` clears the
list rather than keeping `a`. This is pinned by a test and called out in
a code comment. The confirmation prompt catches it interactively; a
script passing `-y` would not. A custom flag value that ignores empty
occurrences was prototyped and reverted as more machinery than the
behavior warranted.
## Validation
Manually verified against a local dev deployment with a premium license:
setting, adding, clearing, prompt accepted and declined, duplicate and
whitespace handling, invalid role rejection, and a plain member being
denied. Confirmed with `/authcheck` that a member loses workspace-create
access when the roles are cleared and regains it when restored, and that
the change is recorded in the audit log.
## Follow-ups worth considering
- `--name`, `--display-name`, `--description`, and `--icon` on
`organizations edit`; all already exist on `UpdateOrganizationRequest`.
Rename deserves its own discussion.
- Setting the defaults to `organization-admin` makes every member an org
admin, including the ability to edit the org further, and those users
still render as plain members in member listings. Reachable today via
the API, UI, and Terraform; a warning on privileged roles would help.
- `dbauthz.InsertOrganization` has no `canAssignRoles` check, unlike
`UpdateOrganization`. Harmless while the only caller passes the
deployment default constant.
- `docs/admin/users/organizations.md` still points users at the
dashboard or a raw `PATCH`.
</details>
---
Created by Coder Agents on behalf of @jscottmiller.
171 lines
6.5 KiB
Markdown
171 lines
6.5 KiB
Markdown
# Organizations (Premium)
|
|
|
|
> [!NOTE]
|
|
> Organizations requires a
|
|
> [Premium license](https://coder.com/pricing#compare-plans). For more details,
|
|
> [contact your account team](https://coder.com/contact).
|
|
|
|
Organizations can be used to segment and isolate resources inside a Coder
|
|
deployment for different user groups or projects.
|
|
|
|
## Example
|
|
|
|
Here is an example of how one could use organizations to run a Coder deployment
|
|
with multiple platform teams, all with unique resources:
|
|
|
|
|
|
|
|
For more information about how to use organizations, visit the
|
|
[organizations best practices](../../tutorials/best-practices/organizations.md)
|
|
guide.
|
|
|
|
## The default organization
|
|
|
|
All Coder deployments start with one organization called `coder`. All new users
|
|
are added to this organization by default.
|
|
|
|
To edit the organization details, select **Admin settings** from the top bar, then
|
|
**Organizations**:
|
|
|
|
<img height="255px" src="../../images/admin/users/organizations/admin-settings-orgs.png" alt="Organizations Menu" align="center" />
|
|
|
|
From there, you can manage the name, icon, description, users, and groups:
|
|
|
|
|
|
|
|
## Additional organizations
|
|
|
|
Any additional organizations have unique admins, users, templates, provisioners,
|
|
groups, and workspaces. Each organization must have at least one dedicated
|
|
[provisioner](../provisioners/index.md) since the built-in provisioners only apply to
|
|
the default organization.
|
|
|
|
You can configure [organization/role/group sync](./idp-sync.md) from your
|
|
identity provider to avoid manually assigning users to organizations.
|
|
|
|
## How to create an organization
|
|
|
|
### Prerequisites
|
|
|
|
- Coder v2.16+ deployment with Premium license and Organizations enabled
|
|
([contact your account team](https://coder.com/contact)) for more details.
|
|
- User with `Owner` role
|
|
|
|
### 1. Create the organization
|
|
|
|
To create a new organization:
|
|
|
|
1. Select **Admin settings** from the top bar, then **Organizations**.
|
|
|
|
1. Select the current organization to expand the organizations dropdown, then select **Create Organization**:
|
|
|
|
<img height="212px" src="../../images/admin/users/organizations/org-dropdown-create.png" alt="Organizations dropdown and Create Organization" align="center" />
|
|
|
|
1. Enter the details and select **Save** to continue:
|
|
|
|
<img height="579px" src="../../images/admin/users/organizations/new-organization.png" alt="New Organization" align="center" />
|
|
|
|
In this example, we'll create the `data-platform` org.
|
|
|
|
Next deploy a provisioner and template for this organization.
|
|
|
|
### 2. Deploy a provisioner
|
|
|
|
[Provisioners](../provisioners/index.md) are organization-scoped and are responsible
|
|
for executing Terraform/OpenTofu to provision the infrastructure for workspaces
|
|
and testing templates. Before creating templates, we must deploy at least one
|
|
provisioner as the built-in provisioners are scoped to the default organization.
|
|
|
|
1. Using Coder CLI, run the following command to create a key that will be used
|
|
to authenticate the provisioner:
|
|
|
|
```sh
|
|
coder provisioner keys create data-cluster-key --org data-platform
|
|
Successfully created provisioner key data-cluster! Save this authentication token, it will not be shown again.
|
|
|
|
< key omitted >
|
|
```
|
|
|
|
1. Start the provisioner with the key on your desired platform.
|
|
|
|
In this example, start the provisioner using the Coder CLI on a host with
|
|
Docker. For instructions on using other platforms like Kubernetes, see our
|
|
[provisioner documentation](../provisioners/index.md).
|
|
|
|
```sh
|
|
export CODER_URL=https://<your-coder-url>
|
|
export CODER_PROVISIONER_DAEMON_KEY=<key>
|
|
coder provisionerd start --org <org-name>
|
|
```
|
|
|
|
### 3. Create a template
|
|
|
|
Once you've started a provisioner, you can create a template. You'll notice the
|
|
**Create Template** screen now has an organization dropdown:
|
|
|
|
|
|
|
|
### 4. Add members
|
|
|
|
From **Admin settings**, select **Organizations**, then **Members** to add members to
|
|
your organization. Once added, members will be able to see the
|
|
organization-specific templates.
|
|
|
|
<img height="365px" src="../../images/admin/users/organizations/organization-members.png" alt="Add members" align="center" />
|
|
|
|
### 5. Create a workspace
|
|
|
|
Now, users in the data platform organization will see the templates related to
|
|
their organization. Users can be in multiple organizations.
|
|
|
|
|
|
|
|
## Default member roles
|
|
|
|
> [!NOTE]
|
|
> Editing default member roles requires a Premium license.
|
|
> ([learn more](https://coder.com/pricing#compare-plans)).
|
|
|
|
Each organization carries a `default_org_member_roles` list of built-in role
|
|
names. Coder unions this list into every member's effective roles at request
|
|
time, so changes propagate to all current and future members on their next
|
|
request without re-issuing tokens or editing per-user role assignments.
|
|
|
|
The default value is `["organization-workspace-access"]`. With that default,
|
|
every organization member can read, build, ssh into, and execute commands in
|
|
workspaces they own. Removing `organization-workspace-access` from the list
|
|
creates organization members that cannot create or use workspaces unless the
|
|
role is assigned to them directly, which is useful for restricted accounts
|
|
that should only hold the minimal member permissions.
|
|
|
|
To edit the default roles in the dashboard, go to
|
|
**Admin settings** > **Organizations** > **Roles** > **Default Roles**.
|
|
|
|
From the CLI, use `coder organizations edit`:
|
|
|
|
```shell
|
|
coder organizations edit --org <organization> \
|
|
--default-org-member-roles organization-workspace-access,organization-template-admin
|
|
```
|
|
|
|
The flag replaces the current list rather than adding to it, and accepts a
|
|
comma-separated list of built-in role names. Pass an empty value to remove
|
|
every role. Removing a role prompts for confirmation unless you pass
|
|
`--yes`.
|
|
|
|
You can also set `default_org_member_roles` via
|
|
`PATCH /organizations/{organization}`.
|
|
|
|
### Limitations
|
|
|
|
- `default_org_member_roles` accepts built-in role names only. Custom
|
|
organization roles are rejected; assign them directly to members instead.
|
|
- Removing a role from the list removes it from every member that does not
|
|
hold the role through a direct assignment, including existing members.
|
|
Review the per-organization [audit log](../security/audit-logs.md) if you
|
|
need to trace who changed the defaults.
|
|
|
|
## Next steps
|
|
|
|
- [Organizations - best practices](../../tutorials/best-practices/organizations.md)
|