Managing Vulnerabilities #
GitLab offers several Dashboards and Management tools in order to triage and track vulnerabilities. In this lesson, we will go over the Security Dashboard and Vulnerability Management Console.
Step 1: Viewing Vulnerability Reports #
Each vulnerability report contains vulnerabilities from the scans of the most recent branch merged into the default branch.
The vulnerability reports display the total number of vulnerabilities by severity. Below this, a table shows each vulnerabilities detected which includes:
- the scanner where it was detected
- activity (including related issues or available solutions)
In order to access vulnerability reports, navigate to Security & Compliance left navigation menu and selecting Vulnerability Reports
Click on the any vulnerability within the list
Select the Status box
Press the Change Status button
Note: This allows for better filtering, enabling the security team to better triage security issues
- Now scroll to the bottom of the page, and add a comment in the text box and press the Save comment button
Note: This will save the comment in the Vulnerability page to enable collaboration between different members of the AppSec team
- Now click on Create Issue button
Note: This will take you to an issue creation prompt. This allows you to create an issue (confidential or not) in order to collaborate with developers on a resolution.
- Fill anything you want, scroll down, and click on the Create Issue button
Note: Now you have an issue which can be used for AppSec and Development teams to collaborate on resolving the vulnerability.
Step 2: Accessing the Security Dashboard #
At the project level, the Security Dashboard displays a chart with the number of vulnerabilities introduced to the default branch over time.
- Access the Security Dashboard by going to Security & Compliance left navigation menu and selecting Security Dashboard
Note: Nothing will be present, wait a day for it to be populated. Eventually over time with new commits introducing and resolving vulnerabilities, you’ll have something like this:
Step 3: Operational Container Scanning #
Go to the the Security & Compliance left navigation menu and press Policies
Click on the New policy button
Press the Select policy button under the Scan execution policy section
Fill out the following information:
- Name: Policy Name
- Description: Policy Description
Check the Enabled button under Policy status
Create a Rule
Scheduleactions for the
agentsimplenotes in namespaces default,kube-system
Note: Make sure that the agent-name (simplenotes) is typed in correctly, this will be the agent running in our cluster which we will use to scan our pods for vulnerabilities.
The namespaces we are scanning here are default and kube-system, where all our pods are loaded.
The 00:00 is measured in UTC time according to the system-time of the kubernetes agent (simplenotes) pod.
- Create an Action
THEN Require a
Container Scanningscan to run
Click on the Configure with a merge request button
Merge the newly added code
Note: Now that the policy has been created, we must wait until the scheduled time for the scanner to run
Go to the the Security & Compliance left navigation menu and press Vulnerability report
Click on the Operational vulnerabilities tab
View all the different vulnerabilities found in the cluster, there should be a good amount
Step 4: Viewing Audit Events #
Audit Events track important events, including who performed the related action and when. You can use audit events to track, for example:
- Who changed the permission level of a particular user for a GitLab project, and when.
- Who added a new user or removed a user, and when.
You can see a list of available Audit Events in the documentation.
- In order to access audit events, navigate to Security & Compliance left navigation menu and selecting Audit events
Note: You should see a few basic events around adding security policies
Step 5: Enabling and Testing Policy as Code #
Policy as Code is a way of creating policies by just editing code. In this section we will be using GitOps in order to deploy network policies which will limit access to our restricted-echo pods from other pods.
We can see the Network Policy we will be applying in the
network-policies/restricted-echo.yaml file, which prevents any pod without the label
access=true from accessing the
- Open the WebIDE from the project page
Note: To learn more about the GitLab Web IDE and how to use/configure it, checkout the Web IDE documentation
Add the following to the file, updating the
gitops: manifest_projects: - id: <your-full-project-path> paths: - glob: '/network-policies/*.yaml'
It looks as follows for this particular project:
gitops: manifest_projects: - id: tech-marketing/devsecops/initech/simple-notes paths: - glob: '/network-policies/*.yaml'
Click on the Source Control Tab on the left of the Web IDE. It looks as follows:
Click on the Commit & Push Button
In the Commit to new branch? dialog box, select No Use the current branch “main”
Now let’s wait for the pipeline to complete, this should take a few mins - so grab a coffee ☕️ or tea 🍵, or whatever you like! If the pipeline happens to fail, please checkout the troubleshooting documentation.
Testing Policy as Code #
- Open a terminal and connect to your cluster
$ gcloud container clusters get-credentials fern-initech --zone us-central1-c --project fdiaz-02874dfa Fetching cluster endpoint and auth data. kubeconfig entry generated for fern-initech.
Note: You should use the command, provided by GKE as seen in previous lessons
- Verify that the network policy has been installed
$ kubectl get networkpolicy NAME POD-SELECTOR AGE access-restricted-nginx app=restricted-nginx 35m
- Create a
busyboxcontainer and try and access our
$ kubectl run busybox --rm -ti --image=busybox:1.28 -- /bin/sh If you don't see a command prompt, try pressing enter. / # wget --spider --timeout=1 restricted-nginx Connecting to restricted-nginx (10.4.5.28:80) wget: download timed out
Note: When performing a wget, we should timeout since we cannot access the pod without the label
Exit from the container by typing
exitin the commandline
busyboxcontainer, with the
access=truelabel, and try and access our
$ kubectl run busybox --rm -ti --labels="access=true" --image=busybox:1.28 -- /bin/sh If you don't see a command prompt, try pressing enter. / # wget --spider --timeout=1 restricted-nginx Connecting to restricted-nginx (10.4.5.28:80) remote file exists
Note: This time the wget should work since we have the label present
Congratulations, you are now able to use some of GitLab’s Security Tools within your AppSec Workflow and to better collaborate with others. Thanks for going through the Getting Started Documentation!