From 1986fe96176d9adbcaad73aa548602819e2092f3 Mon Sep 17 00:00:00 2001 From: Scott Wilson Date: Tue, 29 Oct 2024 14:45:38 -0700 Subject: [PATCH] improvement: minor doc adjustment and add new page to sidebar --- .../attribute-based-access-controls.mdx | 38 +++++++++---------- docs/mint.json | 2 +- 2 files changed, 20 insertions(+), 20 deletions(-) diff --git a/docs/documentation/platform/access-controls/attribute-based-access-controls.mdx b/docs/documentation/platform/access-controls/attribute-based-access-controls.mdx index b4d7be9334..37d873a430 100644 --- a/docs/documentation/platform/access-controls/attribute-based-access-controls.mdx +++ b/docs/documentation/platform/access-controls/attribute-based-access-controls.mdx @@ -7,30 +7,30 @@ Infisical's Attribute-based Access Controls (ABAC) allow for dynamic, attribute- 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 gain access to requested resource. +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 control is currently available for polices defined on projects. You can set ABAC permissions to control access to environments, folders, secrets, and secret tags. +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 - + - + - + - + - - For organizations using SAML for login, Infisical automatically maps metadata attributes from SAML assertions. + + For organizations using SAML for login, Infisical automatically maps metadata attributes from SAML assertions to user identities. This makes it easy to create policies that dynamically adapt based on the SAML user’s attributes. @@ -40,26 +40,26 @@ Attribute based access control is currently available for polices defined on pro -ABAC policies make use of identity metadata to define dynamic permissions. -The following attributes are available within project permissions. Each attribute much begin `{{` and end with `}}`. +ABAC policies make use of identity metadata to define dynamic permissions. Each attribute must start and end with double curly-brackets `{{ }}`. +The following attributes are available within project permissions: - **User ID**: `{{ identity.id }}` - **Username**: `{{ identity.username }}` - **Metadata Attributes**: `{{ identity.metadata. }}` -During policy execution, these placeholders are first replaced by their actual values then the policy is executed. +During policy execution these placeholders are replaced by their actual values prior to evaluation. ### Example Use Case -#### Geography-based Access Control +#### Location-based Access Control -Suppose you want to restrict access to secrets within a folder access based on user geography. -You could assign a `geography` attribute to each user (e.g., `identity.metadata.geography`). -Then, you can structure your folders to align with this attribute and define permissions accordingly. +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 allow access only to folders matching the user's geographic attribute: +For example, a policy might restrict access to folders matching the user's location attribute in the following pattern: ``` -/appA/{{ identity.metadata.geography }} +/appA/{{ identity.metadata.location }} ``` -With this structure, users can only access folders that correspond to their own geography attribute. -This means that if the users attribute changes due to relocation, no policy needs to be changed to gain access to the new folders. +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. diff --git a/docs/mint.json b/docs/mint.json index 33e5f5c9f1..92827d8af3 100644 --- a/docs/mint.json +++ b/docs/mint.json @@ -135,11 +135,11 @@ "pages": [ "documentation/platform/access-controls/overview", "documentation/platform/access-controls/role-based-access-controls", + "documentation/platform/access-controls/attribute-based-access-controls", "documentation/platform/access-controls/additional-privileges", "documentation/platform/access-controls/temporary-access", "documentation/platform/access-controls/access-requests", "documentation/platform/pr-workflows", - "documentation/platform/audit-log-streams", "documentation/platform/groups" ] },