mirror of
https://github.com/awatertrevi/infisical.git
synced 2026-09-22 13:39:35 +00:00
214 lines
10 KiB
Plaintext
214 lines
10 KiB
Plaintext
---
|
|
title: "Permissions"
|
|
description: "Infisical's permissions system provides granular access control."
|
|
---
|
|
|
|
## Overview
|
|
|
|
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 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.
|
|
|
|
Refer to the table below for a list of subjects and the actions they support.
|
|
|
|
## Subjects and Actions
|
|
|
|
<Tabs>
|
|
<Tab title="Project Permissions">
|
|
|
|
<Note>
|
|
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`.
|
|
</Note>
|
|
|
|
| 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` |
|
|
| `secret-syncs` | `read`, `create`, `edit`, `delete`, `sync-secrets`, `import-secrets`, `remove-secrets` |
|
|
|
|
</Tab>
|
|
|
|
<Tab title="Organization Permissions">
|
|
|
|
<Note>
|
|
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`.
|
|
</Note>
|
|
|
|
| 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` |
|
|
| `project-templates` | `read`, `create`, `edit`, `delete` |
|
|
| `app-connections` | `read`, `create`, `edit`, `delete`, `connect` |
|
|
| `kms` | `read` |
|
|
|
|
</Tab>
|
|
</Tabs>
|
|
|
|
## 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
|
|
|
|
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
|
|
|
|
Conditions allow you to create more granular permissions by specifying criteria that must be met for the permission to apply. This is supported for the following subjects:
|
|
|
|
- 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.
|
|
|
|
## Migrating from permission V1 to permission V2
|
|
|
|
When upgrading to V2 permissions (i.e. when moving from using the `permissions` to `permissions_v2` field in your Terraform configurations, or upgrading to the V2 permission API), you'll need to update your permission structure as follows:
|
|
|
|
Any permissions for `secrets` should be expanded to include equivalent permissions for:
|
|
|
|
- `secret-imports`
|
|
- `secret-folders` (except for read permissions)
|
|
- `dynamic-secrets`
|
|
|
|
For dynamic secrets, the actions need to be mapped differently:
|
|
|
|
- `read` → `read-root-credential`
|
|
- `create` → `create-root-credential`
|
|
- `edit` → `edit-root-credential` (also adds `lease` permission)
|
|
- `delete` → `delete-root-credential`
|
|
|
|
Example:
|
|
|
|
```hcl
|
|
# Old V1 configuration
|
|
resource "infisical_project_role" "example" {
|
|
name = "example"
|
|
permissions = [
|
|
{
|
|
subject = "secrets"
|
|
action = "read"
|
|
},
|
|
{
|
|
subject = "secrets"
|
|
action = "edit"
|
|
}
|
|
]
|
|
}
|
|
|
|
# New V2 configuration
|
|
resource "infisical_project_role" "example" {
|
|
name = "example"
|
|
permissions_v2 = [
|
|
# Original secrets permission
|
|
{
|
|
subject = "secrets"
|
|
action = ["read", "edit"]
|
|
inverted = false
|
|
},
|
|
# Add equivalent secret-imports permission
|
|
{
|
|
subject = "secret-imports"
|
|
action = ["read", "edit"]
|
|
inverted = false
|
|
},
|
|
# Add secret-folders permission (without read)
|
|
{
|
|
subject = "secret-folders"
|
|
action = ["edit"]
|
|
inverted = false
|
|
},
|
|
# Add dynamic-secrets permission with mapped actions
|
|
{
|
|
subject = "dynamic-secrets"
|
|
action = ["read-root-credential", "edit-root-credential", "lease"]
|
|
inverted = false
|
|
}
|
|
]
|
|
}
|
|
```
|
|
|
|
Note: When moving to V2 permissions, make sure to include all the necessary expanded permissions based on your original `secrets` permissions.
|