diff --git a/docs/documentation/platform/access-controls/access-requests.mdx b/docs/documentation/platform/access-controls/access-requests.mdx index 45c155ab4..fe8dfb06b 100644 --- a/docs/documentation/platform/access-controls/access-requests.mdx +++ b/docs/documentation/platform/access-controls/access-requests.mdx @@ -6,7 +6,7 @@ description: "Learn how to request access to sensitive resources in Infisical." In certain situations, developers need to expand their access to a certain new project or a sensitive environment. For those use cases, it is helpful to utilize Infisical's **Access Requests** functionality. This functionality works in the following way: -1. A project administrator sets up a policy that assigns access managers (also known as eligible approvers) to a certain sensitive folder or environment. +1. A project administrator sets up an access policy that assigns access managers (also known as eligible approvers) to a certain sensitive folder or environment. ![Create Access Request Policy Modal](/images/platform/access-controls/create-access-request-policy.png) ![Access Request Policies](/images/platform/access-controls/access-request-policies.png) @@ -14,7 +14,10 @@ This functionality works in the following way: ![Access Request Create](/images/platform/access-controls/request-access.png) ![Access Request Dashboard](/images/platform/access-controls/access-requests-pending.png) -3. An eligible approver can approve or reject the access request. +3. If the access request matches woth a policy that has a **Soft** enforcement level, the requester could bypass the policy and get access to the resource without approval. +![Access Request Bypass](/images/platform/access-controls/access-request-bypass.png) + +4. An eligible approver can approve or reject the access request. ![Access Request Review](/images/platform/access-controls/review-access-request.png) 4. As soon as the request is approved, developer is able to access the sought resources. diff --git a/docs/documentation/platform/pr-workflows.mdx b/docs/documentation/platform/pr-workflows.mdx index 9df123612..af764d876 100644 --- a/docs/documentation/platform/pr-workflows.mdx +++ b/docs/documentation/platform/pr-workflows.mdx @@ -18,10 +18,22 @@ In a similar way, to solve the above-mentioned issues, Infisical provides a feat ### Setting a policy -First, you would need to create a set of policies for a certain environment. In the example below, a generic policy for a production environment is shown. In this case, any user who submits a change to `prod` would first have to get an approval by a predefined approver (or multiple approvers). +First, you would need to create a set of policies for a certain environment. In the example below, a generic change policy for a production environment is shown. In this case, any user who submits a change to `prod` would first have to get an approval by a predefined approver (or multiple approvers). ![create secret update policy](../../images/platform/pr-workflows/secret-update-policy.png) +### Defining enforcement level + +The enforcement level determines how strict the policy is. A **Hard** enforcement level means that any change that matches the policy will need approval prior merging. A **Soft** enforcement level means that a change requests that matches the policy could be bypassed if the requester provides a reason for the bypass. If a change request is bypassed, the approvers will be notified via email. + +Take into account that a **Soft** enforcement level is more flexible and allows for more flexibility in the approval process but it's more prone to human error. + +### Example of creating a change policy + +When creating a policy, you can choce the type of policy you want to create. In this case, we will be creating a `Change Policy`. Other types of policies include `Access Policy` that creates policies for **[Access Requests](/documentation/platform/access-controls/access-requests)**. + +![create panel secret update policy](../../images/platform/pr-workflows/create-change-policy.png) + ### Example of updating secrets with Approval workflows When a user submits a change to an enviropnment that is under a particular policy, a corresponsing change request will go to a predefined approver (or multiple approvers). diff --git a/docs/images/platform/access-controls/access-request-bypass.png b/docs/images/platform/access-controls/access-request-bypass.png new file mode 100644 index 000000000..248150574 Binary files /dev/null and b/docs/images/platform/access-controls/access-request-bypass.png differ diff --git a/docs/images/platform/access-controls/access-request-policies.png b/docs/images/platform/access-controls/access-request-policies.png index d7ea4829c..a0eca9dfd 100644 Binary files a/docs/images/platform/access-controls/access-request-policies.png and b/docs/images/platform/access-controls/access-request-policies.png differ diff --git a/docs/images/platform/access-controls/create-access-request-policy.png b/docs/images/platform/access-controls/create-access-request-policy.png index 6593fd733..56f9840cf 100644 Binary files a/docs/images/platform/access-controls/create-access-request-policy.png and b/docs/images/platform/access-controls/create-access-request-policy.png differ diff --git a/docs/images/platform/pr-workflows/create-change-policy.png b/docs/images/platform/pr-workflows/create-change-policy.png new file mode 100644 index 000000000..4ff1ad884 Binary files /dev/null and b/docs/images/platform/pr-workflows/create-change-policy.png differ diff --git a/docs/images/platform/pr-workflows/secret-update-policy.png b/docs/images/platform/pr-workflows/secret-update-policy.png index 45e6322f1..53a4e92ca 100644 Binary files a/docs/images/platform/pr-workflows/secret-update-policy.png and b/docs/images/platform/pr-workflows/secret-update-policy.png differ