From b0031b71e003ea99bb36ac44562566e7cfae27ed Mon Sep 17 00:00:00 2001 From: Sheen Capadngan Date: Tue, 5 Nov 2024 01:21:35 +0800 Subject: [PATCH] doc: updated internal permission docs --- docs/internals/permissions.mdx | 173 ++++++++++++++++++++++----------- 1 file changed, 116 insertions(+), 57 deletions(-) diff --git a/docs/internals/permissions.mdx b/docs/internals/permissions.mdx index 3eb7059d2..691e739ef 100644 --- a/docs/internals/permissions.mdx +++ b/docs/internals/permissions.mdx @@ -7,77 +7,136 @@ description: "Infisical's permissions system provides granular access control." The Infisical permissions system is based on a role-based access control (RBAC) model. The system allows you to define roles and assign them to users and machines. Each role has a set of permissions that define what actions a user can perform. -Permissions are built on a subject-action-object model. The subject is the resource permission is being applied to, the action is what the permission allows. +Permissions are built on a subject-action-object model. The subject is the resource the permission is being applied to, the action is what the permission allows. An example of a subject/action combination would be `secrets/read`. This permission allows the subject to read secrets. -Currently Infisical supports 4 actions: -1. `read`, allows the subject to read the object. -2. `create`, allows the subject to create the object. -3. `edit`, allows the subject to edit the object. -4. `delete`, allows the subject to delete the object. - -Most subjects support all 4 actions, but some subjects only support a subset of actions. Please view the table below for a list of subjects and the actions they support. - +Refer to the table below for a list of subjects and the actions they support. ## Subjects and Actions + - Not all actions are applicable to all subjects. As an example, the `secrets-rollback` subject only supports `read`, and `create` as actions. While `secrets` support `read`, `create`, `edit`, `delete`. + Not all actions are applicable to all subjects. As an example, the + `secrets-rollback` subject only supports `read`, and `create` as actions. + While `secrets` support `read`, `create`, `edit`, `delete`. - | Subject | Actions | - |-----------------------------|---------| - | `secrets` | `read`, `create`, `edit`, `delete` | - | `secret-approval` | `read`, `create`, `edit`, `delete` | - | `secret-rotation` | `read`, `create`, `edit`, `delete` | - | `secret-rollback` | `read`, `create` | - | `member` | `read`, `create`, `edit`, `delete` | - | `groups` | `read`, `create`, `edit`, `delete` | - | `role` | `read`, `create`, `edit`, `delete` | - | `integrations` | `read`, `create`, `edit`, `delete` | - | `webhooks` | `read`, `create`, `edit`, `delete` | - | `identity` | `read`, `create`, `edit`, `delete` | - | `service-tokens` | `read`, `create`, `edit`, `delete` | - | `settings` | `read`, `create`, `edit`, `delete` | - | `environments` | `read`, `create`, `edit`, `delete` | - | `tags` | `read`, `create`, `edit`, `delete` | - | `audit-logs` | `read`, `create`, `edit`, `delete` | - | `ip-allowlist` | `read`, `create`, `edit`, `delete` | - | `certificate-authorities` | `read`, `create`, `edit`, `delete` | - | `certificates` | `read`, `create`, `edit`, `delete` | - | `certificate-templates` | `read`, `create`, `edit`, `delete` | - | `pki-alerts` | `read`, `create`, `edit`, `delete` | - | `pki-collections` | `read`, `create`, `edit`, `delete` | - | `workspace` | `edit`, `delete` | - | `kms` | `edit` | +| Subject | Actions | +| ------------------------- | ----------------------------------------------------------------------------------------------------------- | +| `role` | `read`, `create`, `edit`, `delete` | +| `member` | `read`, `create`, `edit`, `delete` | +| `groups` | `read`, `create`, `edit`, `delete` | +| `settings` | `read`, `create`, `edit`, `delete` | +| `integrations` | `read`, `create`, `edit`, `delete` | +| `webhooks` | `read`, `create`, `edit`, `delete` | +| `service-tokens` | `read`, `create`, `edit`, `delete` | +| `environments` | `read`, `create`, `edit`, `delete` | +| `tags` | `read`, `create`, `edit`, `delete` | +| `audit-logs` | `read`, `create`, `edit`, `delete` | +| `ip-allowlist` | `read`, `create`, `edit`, `delete` | +| `workspace` | `edit`, `delete` | +| `secrets` | `read`, `create`, `edit`, `delete` | +| `secret-folders` | `read`, `create`, `edit`, `delete` | +| `secret-imports` | `read`, `create`, `edit`, `delete` | +| `dynamic-secrets` | `read-root-credential`, `create-root-credential`, `edit-root-credential`, `delete-root-credential`, `lease` | +| `secret-rollback` | `read`, `create` | +| `secret-approval` | `read`, `create`, `edit`, `delete` | +| `secret-rotation` | `read`, `create`, `edit`, `delete` | +| `identity` | `read`, `create`, `edit`, `delete` | +| `certificate-authorities` | `read`, `create`, `edit`, `delete` | +| `certificates` | `read`, `create`, `edit`, `delete` | +| `certificate-templates` | `read`, `create`, `edit`, `delete` | +| `pki-alerts` | `read`, `create`, `edit`, `delete` | +| `pki-collections` | `read`, `create`, `edit`, `delete` | +| `kms` | `edit` | +| `cmek` | `read`, `create`, `edit`, `delete`, `encrypt`, `decrypt` | - These details are especially useful if you're using the API to [create new project roles](../api-reference/endpoints/project-roles/create). - The rules outlined on this page, also apply when using our Terraform Provider to manage your Infisical project roles, or any other of our clients that manage project roles. - - - Not all actions are applicable to all subjects. As an example, the `workspace` subject only supports `read`, and `create` as actions. While `member` support `read`, `create`, `edit`, `delete`. - + + Not all actions are applicable to all subjects. As an example, the `workspace` + subject only supports `read`, and `create` as actions. While `member` support + `read`, `create`, `edit`, `delete`. + + +| Subject | Actions | +| ------------------ | ---------------------------------- | +| `workspace` | `read`, `create` | +| `role` | `read`, `create`, `edit`, `delete` | +| `member` | `read`, `create`, `edit`, `delete` | +| `secret-scanning` | `read`, `create`, `edit`, `delete` | +| `settings` | `read`, `create`, `edit`, `delete` | +| `incident-account` | `read`, `create`, `edit`, `delete` | +| `sso` | `read`, `create`, `edit`, `delete` | +| `scim` | `read`, `create`, `edit`, `delete` | +| `ldap` | `read`, `create`, `edit`, `delete` | +| `groups` | `read`, `create`, `edit`, `delete` | +| `billing` | `read`, `create`, `edit`, `delete` | +| `identity` | `read`, `create`, `edit`, `delete` | +| `kms` | `read` | - | Subject | Actions | - |-----------------------------|------------------------------------| - | `workspace` | `read`, `create` | - | `role` | `read`, `create`, `edit`, `delete` | - | `member` | `read`, `create`, `edit`, `delete` | - | `secret-scanning` | `read`, `create`, `edit`, `delete` | - | `settings` | `read`, `create`, `edit`, `delete` | - | `incident-account` | `read`, `create`, `edit`, `delete` | - | `sso` | `read`, `create`, `edit`, `delete` | - | `scim` | `read`, `create`, `edit`, `delete` | - | `ldap` | `read`, `create`, `edit`, `delete` | - | `groups` | `read`, `create`, `edit`, `delete` | - | `billing` | `read`, `create`, `edit`, `delete` | - | `identity` | `read`, `create`, `edit`, `delete` | - | `kms` | `read` | - \ No newline at end of file + + +## Inversion + +Permission inversion allows you to explicitly deny actions instead of allowing them. This is supported for the following subjects: + +- secrets +- secret-folders +- secret-imports +- dynamic-secrets +- cmek + +When a permission is inverted, it changes from an "allow" rule to a "deny" rule. For example: + +```typescript +// Regular permission - allows reading secrets +{ + subject: "secrets", + action: ["read"] +} + +// Inverted permission - denies reading secrets +{ + subject: "secrets", + action: ["read"], + inverted: true +} +``` + +## Conditions + +Certain subjects support conditional permissions that allow for more granular access control. These subjects are: + +- secrets +- secret-folders +- secret-imports +- dynamic-secrets + +### Properties + +Conditions can be applied to the following properties: + +- `environment`: Control access based on environment slugs +- `secretPath`: Control access based on secret paths +- `secretName`: Control access based on secret names +- `secretTags`: Control access based on tags (only supports $in operator) + +### Operators + +The following operators are available for conditions: + +| Operator | Description | Example | +| -------- | ---------------------------------- | ----------------------------------------------------- | +| `$eq` | Equal | `{ environment: { $eq: "production" } }` | +| `$ne` | Not equal | `{ environment: { $ne: "development" } }` | +| `$in` | Matches any value in array | `{ environment: { $in: ["staging", "production"] } }` | +| `$glob` | Pattern matching using glob syntax | `{ secretPath: { $glob: "/app/\*" } }` | + +These details are especially useful if you're using the API to [create new project roles](../api-reference/endpoints/project-roles/create). +The rules outlined on this page, also apply when using our Terraform Provider to manage your Infisical project roles, or any other of our clients that manage project roles.