Skip to main content

Overview

Infisical’s project permissions system follows a role-based access control (RBAC) model built on a subject-action-object framework. At the project level, these permissions determine what actions users/machines can perform on various resources within a specific project. Each permission consists of:
  • Subject: The resource the permission applies to (e.g., secrets, members, settings)
  • Action: The operation that can be performed (e.g., read, create, edit, delete)
Some project-level resources—specifically secrets, secret-folders, secret-imports, dynamic-secrets, secret-syncs, secret-rotation, honey-tokens, identity, app-connections, and pam-accounts—support conditional permissions and permission inversion for more granular access control. Conditions allow you to specify criteria (like environment, secret path, tags, app connection ID, identity ID, resource name, or endpoint name) that must be met for the permission to apply.

Available project permissions

Below is a comprehensive list of all available project-level subjects and their supported actions.

Core platform & access control

Subject: role

Subject: member

Supports conditions for privilege delegation actions.

Subject: groups

Supports conditions for privilege delegation actions.

Subject: identity

Supports conditions and permission inversion.

Subject: settings

Subject: environments

Subject: tags

Subject: project

Subject: ip-allowlist

Subject: audit-logs

Subject: integrations

Subject: webhooks

Subject: service-tokens

Subject: app-connections

Supports conditions and permission inversion.

Secrets management

Subject: secrets

Supports conditions and permission inversion.

Subject: secret-folders

Supports conditions and permission inversion.

Subject: secret-imports

Supports conditions and permission inversion.

Subject: secret-event-subscriptions

Subject: secret-rollback

Subject: commits

Subject: secret-approval

Subject: secret-approval-request

Project admins and users with Secret Approval Requests (secret-approval-request) Read can view all approval requests; others only see requests where they’re committer or approver. Secret values in requests follow secrets.readValue for the secret’s environment/path, or reviewer access.

Subject: secret-rotation

Supports conditions and permission inversion.

Subject: honey-tokens

Supports conditions and permission inversion.

Subject: secret-syncs

Supports conditions and permission inversion.

Subject: dynamic-secrets

Supports conditions and permission inversion.

Subject: insights

Key management service (KMS)

Subject: kms

Subject: cmek

Public key infrastructure (PKI)

Subject: certificate-authorities

Subject: certificates

Subject: certificate-profiles

Subject: certificate-policies

Subject: pki-alerts

Subject: pki-collections

Subject: pki-discovery

Subject: pki-certificate-installations

Secret scanning

Subject: secret-scanning-data-sources

Subject: secret-scanning-findings

Subject: secret-scanning-configs

Privileged access management (PAM)

Subject: pam-resources

Supports conditions and permission inversion.

Subject: pam-accounts

Supports conditions and permission inversion.

Subject: pam-insights

Condition operators

When defining conditions for permissions, you can use the following operators to match values:
When using $glob, note that * doesn’t match across / boundaries. Use ** to match across multiple path segments.A trailing /* also doesn’t match the folder itself: /app/* matches secrets in /app/config but not secrets directly in /app. To grant access to a folder and everything under it, use a trailing /**.

Condition keys reference

The following condition keys can be used to restrict permissions. Each key is available only for specific subjects as indicated in the tables above.

Usage examples

These permission objects are used when creating or updating custom project roles via the API. Each permission in the permissions array defines what actions a role can perform on which resources.

Creating a role with production-only secret access

Create a custom role that can only read secrets in the production environment:

Creating a role with path-scoped access

Create a role that can only manage secrets under /app/config/:

Creating a role for PAM access to specific resources

Create a role that grants PAM access only to specific database resources:

Auditing a user’s effective permissions

A member can hold a direct role, a group-inherited role, and additional privileges at the same time, so what they can actually do isn’t always obvious. The Permission Audit view resolves every source into one effective answer per subject and action. Open Access Control, select the Users tab, select the member, then select Permission Audit in the page header.

Permission Audit for a project member, grouped by resource.

Each action reads as Allow, Conditional, or Forbid. Hover over a conditional action to see the conditions that have to match. A red icon means an explicit forbid, and a muted dash means nothing grants the action at all. The Granted by column names every source that contributes: the direct role, the group-inherited role, or the additional privilege. Use the search box to filter by resource, action, or source, and the All dropdown to show only allowed, conditional, or forbidden actions. Select the Export CSV icon next to the search box to download the full list.