debian-mirror-gitlab/doc/user/clusters/agent/vulnerabilities.md
2022-05-07 20:08:51 +05:30

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:

To view vulnerability information in GitLab:

  1. On the top bar, select Menu > Projects and find the project that contains the agent configuration file.
  2. On the left sidebar, select Infrastructure > Kubernetes clusters.
  3. Select the Agent tab.
  4. Select the agent you want to see the vulnerabilities for.

Cluster agent security tab UI

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 the production namespace.
  • All daemon sets (DaemonSet) named log-collector in the production namespace.