Infisical’s Attribute-based Access Controls (ABAC) allow for dynamic, attribute-driven permissions for both user and machine identities. ABAC policies use metadata attributes—stored as key-value pairs on identities—to enforce fine-grained permissions that are context aware.

In ABAC, access controls are defined using metadata attributes, such as location or department, which can be set directly on user or machine identities. During policy execution, these attributes are evaluated, and determine whether said actor can access the requested resource or perform the requested operation.

​
Project-level Permissions

Attribute-based access controls are currently available for polices defined on projects. You can set ABAC permissions to control access to environments, folders, secrets, and secret tags.

​
Setting Metadata on Identities

1

Navigate to the Access Control page on the organization sidebar and select an identity (user or machine).

2

On the Identity Page, click the pencil icon to edit the selected identity.

3

Add metadata via key-value pairs and update the identity.

​
Defining ABAC Policies

ABAC policies make use of identity metadata to define dynamic permissions. Each attribute must start and end with double curly-brackets {{ <attribute-name> }}. The following attributes are available within project permissions:

  • User ID: {{ identity.id }}
  • Username: {{ identity.username }}
  • Metadata Attributes: {{ identity.metadata.<metadata-key-name> }}

During policy execution, these placeholders are replaced by their actual values prior to evaluation.

​
Example Use Case

​
Location-based Access Control

Suppose you want to restrict access to secrets within a specific folder based on a user’s geographic region. You could assign a location attribute to each user (e.g., identity.metadata.location). You could then structure your folders to align with this attribute and define permissions accordingly.

For example, a policy might restrict access to folders matching the user’s location attribute in the following pattern:

/appA/{{ identity.metadata.location }}

Using this structure, users can only access folders that correspond to their configured location attribute. Consequently, if a users attribute changes due to relocation, no policies need to be changed to gain access to the folders associated with their new location.

Was this page helpful?

Role-based Access ControlsAdditional Privileges