When it comes to critical environments (let's say, production), you as a superadmin might want to introduce an approval flow for application deployment or changes made to the configuration files. Enforcing such restrictions will prevent unwanted deployments and direct modifications to sensitive configurations.
The Approval Policy feature in Devtron lets you introduce an approval mechanism whenever your users perform the following actions:
Deploying an Application to an Environment
Changes in Deployment Template
Changes in ConfigMap
Changes in Secret
Users need to have super-admin permissions to create an approval policy.
Go to Global Configurations → Approval Policy.
Click + Create Profile.
Give a name to the policy, e.g., banking-prod-approval, and add a description (optional) preferably explaining what it does.
Additionally, you can decide who can grant approval from the following 3 options:
Option 1: Choose Any Approver if you want to allow any user with Image Approver permissions and/or Configuration Approver permissions to approve 'Deployment' request and 'Configuration Change' respectively. Choose the number of approvals your users must get to proceed with their changes. The permissible limit ranges from one approval (minimum) to six approvals (maximum).
Option 2: Choose Specific Approver → User Group → Add Criteria to choose one or more user groups who can provide the requisite number of approvals. The permissible limit is [1 to 6] for each user group you add. From the selected group(s), only the users having Image Approver and/or Configuration Approver permissions can approve.
Option 3: Choose Specific Approver → Specific Users (dropdown) to cherry-pick the names of the user(s) who can provide an approval. Here, there is no upper limit to the approvals (unlike the above options), so the user must obtain approvals from all the specific members you add to the policy.
If a user belongs to multiple groups (see Option 2 above), their approval is considered and counted for each group. For example, if you mandate 2 approvals: 1 from DevOps group and 1 from Compliance group; an approval from a common user (belonging to both groups) will count as 2 approvals.
However, once a group's required approvals are met, extra approvals won’t count. For example, if a request needs 2 Security and 3 QA approvals and already has 2 Security and 2 QA approvals, an approval from a user in both teams will count only for QA. The user appears in both lists but doesn’t add to Security’s count.
Yes, apart from the users having approver access, super-admins can also approve the requests (provided the requests are not their own).
Even if the user mentioned in the policy no longer exists, the approval conditions will remain unchanged. Therefore, to prevent unfulfilled approval conditions because of an absent user, it's best to remove that specific user from the policy.
Click Save Changes.
After you create an approval policy, you can apply it. Click Apply Profile on the same screen.
From the Select profiles to apply dropdown, choose the policy you wish to apply. You also have the option to select more than one policy (if they exist) using the checkbox.
Choose the scope from the dropdown given next to Use selected policy for approval of. Here you can decide whether your policy is for:
Approval of Deployment - Select 'Deployments' from the dropdown.
Approval of Configuration Change - Select 'Configuration change' from the dropdown. You can further select: Deployment template, ConfigMaps, Secrets. Select the ones to which your policy should apply so that any change to your chosen configurations will require an approval.
Under Apply to, you get the following options to choose from:
Specific Criteria - Select this option to apply your policy to specific environment(s) of specific applications.
Example: In case of Deployment
Example: In case of Configuration Change
By match criteria - Select this option to use a combination of filters to create criteria. Your policy will only apply to target pipelines/configurations fulfilling your criteria (including existing and future ones). (Optional) You may also write a note for your other team members to understand the intent and context of your policy.
Example: In case of Deployment
Example: In case of Configuration Change
Global - Select this option to apply your chosen policies to every deployment pipeline or configurations (existing and future) of all applications in all clusters.
Example: In case of Deployment
Example: In case of Configuration Change
Click Save Changes.
Users need to have super-admin permissions to apply more policies to a scope.
As shown in step 2 of Apply an Approval Policy, you can choose multiple policies and apply them to a scope (e.g., Global, Cluster, Application, Environment, Base Configuration). However, if you have already applied and now you wish to apply more policies to the same scope, you may do so by following either of the below steps:
Go to Applied Profiles tab.
Use the filters to find the applied profile and scope (e.g., Global, Cluster, Application).
Click the context menu.
Click Manage policy.
Use the Select profiles to apply dropdown and tick the policy/policies you wish to apply.
Click Save Changes.
Use the checkboxes to select the relevant scopes (e.g., Global, Cluster, Application).
Click the Manage Profiles button on the floating widget.
Click Add.
Use the Select profile to apply dropdown and tick the policy/policies you wish to apply in bulk.
Review the changes if needed, and click Save Changes.
If you apply multiple policies together, the user has to meet the approval conditions of all the applied policies. Example 1: if 'Policy A' demands 3 approvals specifically from John, Jane, and Jessy; and if 'Policy B' requires 1 approval from 'Product User Group', the user will have to get 4 approvals. Example 2: if 'Policy A' demands 3 approvals specifically from John, Jane, and Jessy; and if 'Policy B' requires 2 approvals from anyone, the user will still have to get 3 approvals from John, Jane, and Jessy. In short, the stricter conditions from the policies are enforced first and they have to be fulfilled.
Users need to have super-admin permissions to remove an applied approval policy.
If you have already applied policies and wish to remove some of them from a scope, follow the steps below. The approval conditions of the removed policy will no longer apply to the given scope, and the conditions of other policies (if applied to the same scope) will remain.
Go to Applied Profiles tab.
Use the filters to find the applied profile and scope (e.g., Global, Cluster, Application).
Click the context menu.
Click Manage policy.
In the Select profiles to apply dropdown, click 'x' next to the policy/policies you wish to remove.
Click Save Changes.
Use the checkboxes to select the relevant scopes (e.g., Global, Cluster, Application)..
Click the Manage Profiles button on the widget.
Click Remove.
In the Remove Approval Policy dropdown, click 'x' next to the policy/policies you wish to remove.
Review the changes if needed, and click Save Changes.
At least one policy must remain applied to a scope, so you cannot remove all the policies from a scope. You may use the delete procedure instead.
If you have already applied policies to a scope (e.g., Global, Cluster, Application) and wish to delete all of them from that given scope, follow the steps below. Note: This will not delete the approval policy you originally created. Moreover, deployment pipelines may still continue inheriting profiles from higher scopes (e.g., Global, Cluster, Application).
Go to Applied Profiles tab.
Use the filters to find the applied profile(s).
Click the Delete option in the context menu or use the checkboxes to select multiple scopes for deletion.
Users need to have super-admin permissions to delete an approval policy.
If you no longer require a given approval policy, you may delete it. This action will automatically remove its rules enforced earlier for both, deployments and configuration change.
Go to Profiles tab.
Click the delete icon next to the profile you wish to delete.
Assume you created a policy (shown below) that blocks the deployment of a banking application to an environment unless there are two approvals. No user can trigger the deployment unless the images are approved.
The user first requests approval of the intended image. Only those with the necessary permissions will show up in the approver list. Moreover, the user can also opt to notify all users apart from the approvers.
Only those with Image Approver permissions can then approve the request.
If SES/SMTP is configured in Devtron, the approver gets notified via email. This enables the approver to take an action directly from the mail, such as View Request and Approve Request.
The user can then proceed with deploying the approved image.
Assume you created a policy (shown below) that prevents direct changes to the configuration files (Deployment Template, ConfigMaps, Secrets) of a banking application unless there is one approval.
The user first requests approval for pushing a configuration change in Deployment Template/ConfigMap/Secret.
Only those with Configuration Approver permissions can then approve the request.
If SES/SMTP is configured in Devtron, the approver gets notified via email. Therefore, the approver can take an action directly from the mail as shown below.
