013f028e55
* feat: Add app support This adds apps as a property to a workspace agent. The resource is added to the Terraform provider here: https://github.com/coder/terraform-provider-coder/pull/17 Apps will be opened in the dashboard or via the CLI with `coder open <name>`. If `command` is specified, a terminal will appear locally and in the web. If `target` is specified, the browser will open to an exposed instance of that target. * Compare fields in apps test * Update Terraform provider to use relative path * Add some basic structure for routing * chore: Remove interface from coderd and lift API surface Abstracting coderd into an interface added misdirection because the interface was never intended to be fulfilled outside of a single implementation. This lifts the abstraction, and attaches all handlers to a root struct named `*coderd.API`. * Add basic proxy logic * Add proxying based on path * Add app proxying for wildcards * Add wsconncache * fix: Race when writing to a closed pipe This is such an intermittent race it's difficult to track, but regardless this is an improvement to the code. * fix: Race when writing to a closed pipe This is such an intermittent race it's difficult to track, but regardless this is an improvement to the code. * fix: Race when writing to a closed pipe This is such an intermittent race it's difficult to track, but regardless this is an improvement to the code. * fix: Race when writing to a closed pipe This is such an intermittent race it's difficult to track, but regardless this is an improvement to the code. * Add workspace route proxying endpoint - Makes the workspace conn cache concurrency-safe - Reduces unnecessary open checks in `peer.Channel` - Fixes the use of a temporary context when dialing a workspace agent * Add embed errors * chore: Refactor site to improve testing It was difficult to develop this package due to the embed build tag being mandatory on the tests. The logic to test doesn't require any embedded files. * Add test for error handler * Remove unused access url * Add RBAC tests * Fix dial agent syntax * Fix linting errors * Fix gen * Fix icon required * Adjust migration number * Fix proxy error status code * Fix empty db lookup
Authz
Package authz implements AuthoriZation for Coder.
Overview
Authorization defines what permission a subject has to perform actions to objects:
- Permission is binary: yes (allowed) or no (denied).
- Subject in this case is anything that implements interface
authz.Subject. - Action here is an enumerated list of actions, but we stick to
Create,Read,Update, andDeletehere. - Object here is anything that implements
authz.Object.
Permission Structure
A permission is a rule that grants or denies access for a subject to perform an action on a object. A permission is always applied at a given level:
- site level applies to all objects in a given Coder deployment.
- org level applies to all objects that have an organization owner (
org_owner) - user level applies to all objects that have an owner with the same ID as the subject.
Permissions at a higher level always override permissions at a lower level.
The effect of a permission can be:
- positive (allows)
- negative (denies)
- abstain (neither allows or denies, not applicable)
Negative permissions always override positive permissions at the same level. Both negative and positive permissions override abstain at the same level.
This can be represented by the following truth table, where Y represents positive, N represents negative, and _ represents abstain:
| Action | Positive | Negative | Result |
|---|---|---|---|
| read | Y | _ | Y |
| read | Y | N | N |
| read | _ | _ | _ |
| read | _ | N | Y |
Permission Representation
Permissions are represented in string format as <sign>?<level>.<object>.<id>.<action>, where:
negatedcan be either+or-. If it is omitted, sign is assumed to be+.levelis eithersite,org, oruser.objectis any valid resource type.idis any valid UUID v4.actioniscreate,read,modify, ordelete.
Example Permissions
+site.*.*.read: allowed to perform thereadaction against all objects of typeappin a given Coder deployment.-user.workspace.*.create: user is not allowed to create workspaces.
Roles
A role is a set of permissions. When evaluating a role's permission to form an action, all the relevant permissions for the role are combined at each level. Permissions at a higher level override permissions at a lower level.
The following table shows the per-level role evaluation. Y indicates that the role provides positive permissions, N indicates the role provides negative permissions, and _ indicates the role does not provide positive or negative permissions. YN_ indicates that the value in the cell does not matter for the access result.
| Role (example) | Site | Org | User | Result |
|---|---|---|---|---|
| site-admin | Y | YN_ | YN_ | Y |
| no-permission | N | YN_ | YN_ | N |
| org-admin | _ | Y | YN_ | Y |
| non-org-member | _ | N | YN_ | N |
| user | _ | _ | Y | Y |
| _ | _ | N | N | |
| unauthenticated | _ | _ | _ | N |