awatertrevi/infisical
1
0
Fork 0
mirror of https://github.com/awatertrevi/infisical.git synced 2026-09-22 13:39:35 +00:00
Code Issues Packages Projects Releases Wiki Activity

small nits for bypass pr

Browse Source
This commit is contained in:
Maidul Islam
2024-07-19 17:19:06 -04:00
parent f97756a07b
commit 729ca7b6d6
5 changed files with 21 additions and 28 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
docs/documentation/platform/access-controls/access-requests.mdx
View File

@@ -14,12 +14,14 @@ 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. 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.
4. An eligible approver can approve or reject the access request.
{/* ![Access Request Review](/images/platform/access-controls/review-access-request.png) */}
![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)
<Info>
If the access request matches with a policy that has a **Soft** enforcement level, the requester may bypass the policy and get access to the resource without full approval.
</Info>
4. As soon as the request is approved, developer is able to access the sought resources.
5. As soon as the request is approved, developer is able to access the sought resources.
![Access Request Dashboard](/images/platform/access-controls/access-requests-completed.png)

10
docs/documentation/platform/pr-workflows.mdx
View File

@@ -22,15 +22,13 @@ First, you would need to create a set of policies for a certain environment. In
![create secret update policy](../../images/platform/pr-workflows/secret-update-policy.png)
### Defining enforcement level
### Policy enforcement levels
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.
The enforcement level determines how strict the policy is. A **Hard** enforcement level means that any change that matches the policy will need full approval prior merging. A **Soft** enforcement level allows for break glass functionality on the request. If a change request is bypassed, the approvers will be notified via email.
### 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)**.
When creating a policy, you can choose 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)
@@ -40,6 +38,6 @@ When a user submits a change to an enviropnment that is under a particular polic
![secret update change requests](../../images/platform/pr-workflows/secret-update-request.png)
An approver is notified by email and/or Slack as soon as the request is initiated. In the Infisical Dashboard, they will be able to `approve` and `merge` (or `deny`) a request for a change in a particular environment. After that, depending on the workflows setup, the change will be automatically propagated to the right applications (e.g., using [Infisical Kubernetes Operator](https://infisical.com/docs/integrations/platforms/kubernetes)).
Approvers are notified by email and/or Slack as soon as the request is initiated. In the Infisical Dashboard, they will be able to `approve` and `merge` (or `deny`) a request for a change in a particular environment. After that, depending on the workflows setup, the change will be automatically propagated to the right applications (e.g., using [Infisical Kubernetes Operator](https://infisical.com/docs/integrations/platforms/kubernetes)).
![secrets update pull request](../../images/platform/pr-workflows/secret-update-pr.png)