- Enable operational container scanning
- Configure scanner resource requirements
- View cluster vulnerabilities
- Scanning private images
You can use operational container scanning to scan container images in your cluster for security vulnerabilities. You
can enable the scanner to run on a cadence as configured via the
agent config, or setup
scan execution policies within a
project that houses the agent.
scan execution policiesare configured, the configuration from
scan execution policytakes precedence.
To enable scanning of all images within your Kubernetes cluster via the agent configuration, add a
container_scanning configuration block to your agent
configuration with a
cadence field containing a CRON expression for when the scans are run.
container_scanning: cadence: '0 0 * * *' # Daily at 00:00 (Kubernetes cluster time)
cadence field is required. GitLab supports the following types of CRON syntax for the cadence field:
- A daily cadence of once per hour at a specified hour, for example:
0 18 * * *
- A weekly cadence of once per week on a specified day and at a specified hour, for example:
0 13 * * 0
By default, operational container scanning attempts to scan the workloads in all
namespaces for vulnerabilities. You can set the
vulnerability_report block with the
field which can be used to restrict which namespaces are scanned. For example,
if you would like to scan only the
kube-system namespaces, you can use this configuration:
container_scanning: cadence: '0 0 * * *' vulnerability_report: namespaces: - default - kube-system
To enable scanning of all images within your Kubernetes cluster via scan execution policies, we can use the scan execution policy editor To create a new schedule rule.
Here is an example of a policy which enables operational container scanning within the cluster the Kubernetes agent is attached to:
- name: Enforce Container Scanning in cluster connected through my-gitlab-agent for default and kube-system namespaces enabled: true rules: - type: schedule cadence: '0 10 * * *' agents: <agent-name>: namespaces: - 'default' - 'kube-system' actions: - scan: container_scanning
The keys for a schedule rule are:
cadence(required): a CRON expression for when the scans are run
agents:<agent-name>(required): The name of the agent to use for scanning
agents:<agent-name>:namespaces(optional): The Kubernetes namespaces to scan. If omitted, all namespaces are scanned
You can view the complete schema within the scan execution policy documentation.
By default the scanner pod’s default resource requirements are:
requests: cpu: 100m memory: 100Mi limits: cpu: 500m memory: 500Mi
You can customize it with a
container_scanning: resource_requirements: requests: cpu: 200m memory: 200Mi limits: cpu: 700m memory: 700Mi
Operational Container Scanningthrough
scan execution policies, you would need to define the resource requirements within the agent configuration file.
To view vulnerability information in GitLab:
- On the left sidebar, select Search or go to and find the project that contains the agent configuration file.
- Select Operate > Kubernetes clusters.
- Select the Agent tab.
- Select an agent to view the cluster vulnerabilities.
This information can also be found under operational vulnerabilities.
Introduced in GitLab 16.4.
To scan private images, the scanner relies on the image pull secrets (direct references and from the service account) to pull the image.