3.4 KiB
stage | group | info |
---|---|---|
Configure | Configure | To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments |
Container vulnerability scanning (ULTIMATE)
Introduced in GitLab 14.8.
To view cluster vulnerabilities, you can view the vulnerability report. You can also configure your agent so the vulnerabilities are displayed with other agent information in GitLab.
View cluster vulnerabilities
Prerequisite:
- You must have at least the Developer role.
- Cluster image scanning must be part of your build process.
To view vulnerability information in GitLab:
- On the top bar, select Menu > Projects and find the project that contains the agent configuration file.
- On the left sidebar, select Infrastructure > Kubernetes clusters.
- Select the Agent tab.
- Select the agent you want to see the vulnerabilities for.
Enable cluster vulnerability scanning (ULTIMATE)
You can use cluster image scanning to scan container images in your cluster for security vulnerabilities.
To begin scanning all resources in your cluster, add a starboard
configuration block to your agent configuration file with no filters
:
starboard:
vulnerability_report:
filters: []
The namespaces that are able to be scanned depend on the Starboard Operator install mode.
By default, the Starboard Operator only scans resources in the default
namespace. To change this
behavior, edit the STARBOARD_OPERATOR
environment variable in the starboard-operator
deployment
definition.
By adding filters, you can limit scans by:
- Resource name
- Kind
- Container name
- Namespace
starboard:
vulnerability_report:
filters:
- namespaces:
- staging
- production
kinds:
- Deployment
- DaemonSet
containers:
- ruby
- postgres
- nginx
resources:
- my-app-name
- postgres
- ingress-nginx
A resource is scanned if the resource matches any of the given names and all of the given filter
types (namespaces
, kinds
, containers
, resources
). If a filter type is omitted, then all
names are scanned. In this example, a resource isn't scanned unless it has a container named ruby
,
postgres
, or nginx
, and it's a Deployment
:
starboard:
vulnerability_report:
filters:
- kinds:
- Deployment
containers:
- ruby
- postgres
- nginx
There is also a global namespaces
field that applies to all filters:
starboard:
vulnerability_report:
namespaces:
- production
filters:
- kinds:
- Deployment
- kinds:
- DaemonSet
resources:
- log-collector
In this example, the following resources are scanned:
- All deployments (
Deployment
) in theproduction
namespace. - All daemon sets (
DaemonSet
) namedlog-collector
in theproduction
namespace.