Devtron's Security Policies feature allows users to define policies based on the severity levels of vulnerabilities, which include Critical, Moderate, and Low. Users have the flexibility to set policies that either block the deployment of container images with vulnerabilities or allow their deployment.
With this feature, users can specify their desired actions for each severity level. For example, they can choose to block any container image with Critical vulnerabilities, while allowing container images with Moderate or Low vulnerabilities to be deployed.
For in-depth instructions, refer to the Configure Security Policies section.
You can establish security policies for their vulnerabilities through the Security Policies tab, which can be accessed from the left pane by navigating to Security and selecting Security Policies.
You can define policies at the following levels:
However, if you define policies at more than one level, the order of precedence would be as follows:
Application + Environment (highest priority)
Environment
Cluster
Global
Users can block all vulnerabilities
Users can block critical vulnerabilities and allow moderate and low vulnerabilities
Users can block all vulnerabilities for one application and can block only critical vulnerabilities for other applications
Users can block those vulnerabilities for which a fix is already available
Within the Global Security Policies, there are three options available:
If critical severity levels are blocked in the Global Security Policy, the same blocking will be applied to the Cluster Security Policy. Likewise, allowing critical levels in the global policy automatically allows them in Cluster Security Policies.
However, users have the flexibility to explicitly modify these policies as desired.
Cluster Security Policies offer the same three options as Global Security Policies for handling vulnerabilities. However, an extra option called Inherit is available too.
When Inherit is selected, the policy adopts settings from higher-level options. For example, if critical severity levels are blocked globally, they will also be blocked in Cluster Security Policies. Changing the global policy to allow critical levels will also allow them in Cluster Security Policies. Explicit changes can be made to these policies.
To block critical vulnerabilities globally but allow them in specific clusters:
Select the desired cluster.
Change the critical setting to allow.
This change only affects the policy of the selected cluster without impacting others or the global policy.
Environment Security Policies, like Cluster Security Policies, offer four options:
Block always
Block if fix is available
Allow
Inherit
The Environment Security Policy inherits its settings from the Cluster Security Policy, following a hierarchical structure where each level inherits the policy from its upper level.
When you select an environment, it automatically adopts the policy of the associated cluster. For example, if critical-level vulnerabilities are blocked globally but allowed in the Cluster Security Policy, the Environment Security Policy will inherit this allowance. Consequently, critical-level vulnerabilities will also be allowed in the Environment Security Policy.
However, you have the flexibility to make explicit changes to the policy if needed. This empowers you to customize the policy to align with specific requirements or preferences. Any adjustments made to the environment policy settings will be consistently applied across all applications associated with that environment.
The Application Security Policy operates on a similar principle as other policies and offers four options:
Block always
Block if fix is available
Allow
Inherit
However, in the Application Security Policy, the policy is determined by both: Application and Environment
First, choose an application from the list.
Next, configure a security policy for that application in the intended environment.
Let's say, you have defined a policy to block the deployment if critical vulnerabilities are found in a given application.
Now, go to the Build & Deploy tab of that application to select an image.
As you can see, security issues were found in the scanned image, hence it is not available for selection. Click Show Source Info.
The Security tab shows the critical vulnerabilities and the policy enforced to prevent deployment.
To block or allow specific Common Vulnerabilities and Exposures (CVE) policies, simply click Add CVE Policy.
A window will appear where you can enter the CVE ID and select whether to allow or block it.
This action will determine whether image deployment is allowed or blocked based on the presence of vulnerabilities matching that particular CVE ID. Any other deployment decisions will be made according to the policies set previously.
| Option | Description |
|---|---|
Block always
Images containing vulnerabilities will be blocked from deployment
Block if fix is available
Images containing vulnerabilities will be blocked if a fix is available and has not been applied
Allow
Images containing vulnerabilities will be allowed to be deployed regardless of whether a fix is available or not
Devtron's CI pipeline provides a Scan for vulnerabilities option as shown below. Once you enable this option, it will automatically scan the image for vulnerabilities.
To access the comprehensive security scan reports, follow these steps:
In the left sidebar, click Security and go to the Security Scans tab.
Select the desired application from the available list.
This action provides a detailed overview of the application's security scan, including CVE IDs, severity levels of vulnerabilities, and more, as shown below.
Each vulnerability is identified by a CVE ID and categorized based on Severity, Package, Current Version, and Fixed In Version.
CVE ID - Refers to the Common Vulnerability ID assigned to each vulnerability.
Severity - Indicates the severity of the vulnerability and can be classified as Critical, Medium, or Low.
Package - Contains metadata associated with the vulnerability. The CURRENT VERSION refers to the specific version of the vulnerability.
Fixed In Version - Displays the version name if the vulnerability has been addressed in a subsequent release; otherwise, it remains blank.
Devtron provides the capability to identify vulnerabilities before image deployment in the Continuous Deployment (CD) pipeline. This ensures that potential vulnerabilities are detected and addressed early in the deployment process.
To access security vulnerability details during image deployment in Devtron, follow these steps:
Click Show Source Info option for the desired image during the deployment process.
Navigate to the Security tab.
In the Security tab, you will find the security vulnerability details associated with the image.
Vulnerability information will only be displayed for images that have undergone vulnerability scanning. If no vulnerabilities were identified during the scan, the Security tab will display a zero count, indicating Security (0).
Devtron offers the capability to identify vulnerabilities even after an image has been deployed. By navigating to the App Details page, you can find comprehensive details about the vulnerabilities associated with the deployed image.
With this capability, Devtron empowers users to stay informed about the security vulnerabilities present in their deployed images.
Clicking the 'Details' link in the security vulnerabilities report (shown above) reveals detailed information about those found within the deployed image.
Devtron provides DevSecOps capabilities across your software development life cycle for both: the default CI/CD solution by Devtron as well as your existing CI/CD Tools.
One of the key components of DevSecOps is the detection of security risks. Currently, Devtron supports the following types of scanning:
Image Scan
Code Scan
Kubernetes Manifest Scan
You can integrate a scanning tool of your choice. By default, Devtron integrates with Trivy using which you can scan for the following issues:
Vulnerability
License Risks
Misconfigurations
Exposed Secrets
When you commit the code, it's essential to scan it before building a container image. By scanning early, you can catch and fix problems before they become expensive or time-consuming to remediate later.
In your application, go to App Configuration → Workflow Editor.
Click the CI pipeline of your preferred workflow.
Go to the Pre-build stage (tab).
Click + Add Task.
Choose Vulnerability_Scanner v1.0.0 plugin from the list.
Click Update Pipeline.
Based on the results of the scanner, you can also decide whether your CI should proceed further or not. This is possible through Pass/Failure Condition setting in the plugin. In the below example, we are allowing image build only if the no. of high vulnerability is zero.
Results of Pre-CI scan will be visible under Code Scan in the App Details page as shown below.
Once a container image is ready, you can scan its base image libraries, stale files, compromised licenses, and many more.
There are 2 options available:
Image scan in the Build stage (refer Security Scans)
Comprehensive scan in Post-Build stage
This section contains the steps for comprehensive scan.
Go to the Post-build stage (tab) of your CI pipeline.
Click + Add Task and choose Vulnerability_Scanner v1.0.0.
Click Update Pipeline.
Results of Post-CI scan will be visible under Image Scan in the App Details page as shown below.
There can be a loophole where the original image built in the CI stage gets compromised later (say, in publicly accessible repository). Therefore, you can scan the image and catch issues before deploying it. On top of that, you can also scan manifests to detect misconfigurations and exposed secrets.
Go to the Pre-Deployment stage (tab) of your CD pipeline.
Click + Add Task and choose Vulnerability_Scanner v1.0.0.
Click Update Pipeline.
Results of Pre-CD scan will be visible under Image Scan and Kubernetes Manifest in the App Details page as shown below.
When you deploy a helm chart, Devtron will scan the image associated with that helm chart and also the manifests, but unlike Devtron Apps, there is no code scan involved.
Results of helm app scan will be visible under Image Scan and Kubernetes Manifest in the App Details page as shown below.
You can also check for vulnerabilities within a specific workload such as job, pod, deployment, etc. There are two ways to perform it:
Go to App Details (Devtron App/Helm App) → Workloads (under K8 Resources tab).
Click a workload, e.g., Pod.
On the right-hand side, click the kebab menu (3 vertical dots).
Click Check Vulnerabilities.
Go to Resource Browser.
Select a cluster.
Click a workload within the Workloads dropdown.
Access the Check Vulnerabilities option from the kebab menu present to your selected workload.
Devtron's Security feature has two primary sections:
Security Scans - You can view the vulnerabilities detected across your applications.
Security Policies - This allows you to define guardrails to block or allow the deployment of container images depending on the vulnerabilities detected.
