opensource/coder
3
0
Fork 0
mirror of https://github.com/coder/coder.git synced 2026-09-24 15:04:27 +08:00
Code Issues Packages Projects Releases Wiki Activity

chore: adopt markdownlint and markdown-table-formatter for *.md (#15831)

Browse Source 
Co-authored-by: Edward Angert <EdwardAngert@users.noreply.github.com>
This commit is contained in:
Muhammad Atif Ali
2025-01-03 13:12:59 +00:00
committed by GitHub
co-authored by Edward Angert
parent 08463c27d8
commit 94f5d52fdc
255 changed files with 18279 additions and 16786 deletions
Download Patch File Download Diff File Expand all files Collapse all files
coderd/rbac/README.md
+4 -4
View File
@@ -36,7 +36,7 @@ Both **negative** and **positive** permissions override **abstain** at the same
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 | \_ | \_ | \_ |
@@ -63,10 +63,10 @@ This can be represented by the following truth table, where Y represents _positi
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.
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 |
@@ -102,7 +102,7 @@ Example of a scope for a workspace agent token, using an `allow_list` containing
}
```
# Testing
## Testing
You can test outside of golang by using the `opa` cli.
coderd/rbac/USAGE.md
+6 -6
View File
@@ -1,6 +1,6 @@
# Using RBAC
# Overview
## Overview
> _NOTE: you should probably read [`README.md`](README.md) beforehand, but it's
> not essential._
@@ -19,7 +19,7 @@ We have a number of roles (some of which have legacy connotations back to v1).
These can be found in `coderd/rbac/roles.go`.
| Role | Description | Example resources (non-exhaustive) |
| -------------------- | ------------------------------------------------------------------- | -------------------------------------------- |
|----------------------|---------------------------------------------------------------------|----------------------------------------------|
| **owner** | Super-user, first user in Coder installation, has all\* permissions | all\* |
| **member** | A regular user | workspaces, own details, provisioner daemons |
| **auditor** | Viewer of audit log events, read-only access to a few resources | audit logs, templates, users, groups |
@@ -43,7 +43,7 @@ Roles are collections of permissions (we call them _actions_).
These can be found in `coderd/rbac/policy/policy.go`.
| Action | Description |
| ----------------------- | --------------------------------------- |
|-------------------------|-----------------------------------------|
| **create** | Create a resource |
| **read** | Read a resource |
| **update** | Update a resource |
@@ -58,7 +58,7 @@ These can be found in `coderd/rbac/policy/policy.go`.
| **stop** | Stop a workspace |
| **assign** | Assign user to role / org |
# Creating a new noun
## Creating a new noun
In the following example, we're going to create a new RBAC noun for a new entity
called a "frobulator" _(just some nonsense word for demonstration purposes)_.
@@ -291,7 +291,7 @@ frobulator, but no test case covered it.
**NOTE: don't just add cases which make the tests pass; consider all the ways in
which your resource must be used, and test all of those scenarios!**
# Database authorization
## Database authorization
Now that we have the RBAC system fully configured, we need to make use of it.
@@ -350,7 +350,7 @@ before we validate (this explains the `fetchWithPostFilter` naming).
All queries are executed through `dbauthz`, and now our little frobulators are
protected!
# API authorization
## API authorization
API authorization is not strictly required because we have database
authorization in place, but it's a good practice to reject requests as soon as