Lock Deployment Configuration
The Deployment Template might contain certain configurations intended for the DevOps team (e.g., ingress
), and not meant for developers to modify.
Therefore, Devtron allows super-admins to restrict such fields from modification or deletion.
![](https://docs.devtron.ai/~gitbook/image?url=https%3A%2F%2Fdevtron-public-asset.s3.us-east-2.amazonaws.com%2Fimages%2Fglobal-configurations%2Flock-dt%2Fnot-eligible-changes.jpg&width=768&dpr=4&quality=100&sign=8f5a69a1&sv=1)
This stands true for deployment templates in:
How is this different from the Protect Configuration feature?
The 'protect configuration' feature is meant to verify the edits by introducing an approval flow for any changes made to the configuration files, i.e., Deployment template, ConfigMaps, and Secrets. This is performed at application-level.
Whereas, the 'lock deployment configuration' feature goes one step further. It is meant to prevent any edits to specific keys by non-super-admins. This applies only to deployment templates and is performed at global-level.
Locking Deployment Keys
Go to Global Configurations → Lock Deployment Config. Click Configure Lock.
Figure 2: Configure Lock Button (Optional) Click Refer Values.YAML to check which keys you wish to lock.
Figure 3: Values.YAML File Enter the keys inside the editor on the left-hand side, e.g.,
autoscaling.MaxReplicas
. Use JSONpath expressions to enter specific keys, lists, or objects to lock.Figure 4: Referring Values.YAML File for Locking Keys Click Save.
Figure 5: Saving Locked Keys A confirmation dialog box would appear. Read it and click Confirm.
Figure 6: Confirmation Dialog
Result
While super-admins can directly edit the locked keys, let's look at a scenario where a user (non-super-admin) tries to edit the same in an unprotected base deployment template.
User can hide/unhide the locked keys as shown below.
Figure 7: Hiding Locked Keys
Let's assume the user edits one of the locked keys...
Figure 8: Editing Locked Keys ...and saves the changes.
A modal window will appear on the right highlighting the non-eligible edits.
Figure 10: Eligible and Non-eligible Changes Let's assume the user edits a key that is not locked or adds a new key.
Figure 11: Editing Allowed Keys The modal window will highlight the eligible edits. However, it will not let the user save those eligible edits unless the user clicks the checkbox: Save changes which are eligible for update.
Figure 12: Saving Eligible Changes
Once the user clicks the Update button, the permissible changes will reflect in the deployment template.
However, if it's a protected template, the user will require the approval of a configuration approver as shown below.
The same result can be seen if the user tries to edit environment-specific deployment templates.
Last updated