mirror of
https://github.com/awatertrevi/infisical.git
synced 2026-09-22 13:39:35 +00:00
small nits for bypass pr
This commit is contained in:
Maidul Islam
@@ -515,7 +515,7 @@ export const secretApprovalRequestServiceFactory = ({
|
||||
|
||||
await smtpService.sendMail({
|
||||
recipients: approverUsers.filter((approver) => approver.email).map((approver) => approver.email!),
|
||||
subjectLine: "Secret Request Bypassed",
|
||||
subjectLine: "Infisical Secret Change Policy Bypassed",
|
||||
|
||||
substitutions: {
|
||||
projectName: project.name,
|
||||
|
||||
@@ -1,35 +1,28 @@
|
||||
|
||||
<html>
|
||||
|
||||
<head>
|
||||
<meta charset="utf-8" />
|
||||
<meta http-equiv="x-ua-compatible" content="ie=edge" />
|
||||
<title>Secret Approval Request Bypassed</title>
|
||||
<title>Secret Approval Request Policy Bypassed</title>
|
||||
</head>
|
||||
|
||||
<body>
|
||||
<h2>Infisical</h2>
|
||||
<h2>A secret approval request has been bypassed</h2>
|
||||
<p>A secret approval request has been merged without approval in project "{{projectName}}".</p>
|
||||
<h1>Infisical</h1>
|
||||
<h2>Secret Approval Request Bypassed</h2>
|
||||
<p>A secret approval request has been bypassed in the project "{{projectName}}".</p>
|
||||
|
||||
<p>
|
||||
{{requesterFullName}}
|
||||
({{requesterEmail}}) has merged
|
||||
a secret to
|
||||
{{secretPath}}
|
||||
in the
|
||||
{{environment}}
|
||||
environment.
|
||||
{{requesterFullName}} ({{requesterEmail}}) has merged
|
||||
a secret to environment {{environment}} at secret path {{secretPath}}
|
||||
without obtaining the required approvals.
|
||||
</p>
|
||||
<p>
|
||||
The following reason was provided:
|
||||
The following reason was provided for bypassing the policy:
|
||||
<em>{{bypassReason}}</em>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Go to the request panel
|
||||
To review this action, please visit the request panel
|
||||
<a href="{{approvalUrl}}">here</a>.
|
||||
</p>
|
||||
</body>
|
||||
|
||||
</html>
|
||||
@@ -14,12 +14,14 @@ This functionality works in the following way:
|
||||
|
||||
|
||||
|
||||
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.
|
||||
{/*  */}
|
||||
|
||||
|
||||
4. An eligible approver can approve or reject the access request.
|
||||
|
||||
<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.
|
||||
|
||||
|
||||
|
||||
@@ -22,15 +22,13 @@ First, you would need to create a set of policies for a certain environment. In
|
||||
|
||||
|
||||
|
||||
### 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)**.
|
||||
|
||||
|
||||
|
||||
@@ -40,6 +38,6 @@ When a user submits a change to an enviropnment that is under a particular polic
|
||||
|
||||
|
||||
|
||||
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)).
|
||||
|
||||
|
||||
@@ -127,7 +127,7 @@ export const SecretApprovalRequestAction = ({
|
||||
</Checkbox>
|
||||
{byPassApproval && (
|
||||
<FormControl
|
||||
label="Reason for Bypass"
|
||||
label="Reason for bypass"
|
||||
className="mt-2"
|
||||
isRequired
|
||||
tooltipText="Enter a reason for bypassing the secret change policy"
|
||||
|
||||
Reference in New Issue
Block a user