with the type set to `File` (see [Configuring the cluster](#configuring-the-cluster)).
with the type set to `File` (see [Configuring the cluster](#configuring-the-cluster)).
## Configuring the cluster
### Configuring the cluster
1. Create a new service account.
1. Create a new service account.
...
@@ -128,7 +136,7 @@ only. You can apply additional protection to your cluster by
...
@@ -128,7 +136,7 @@ only. You can apply additional protection to your cluster by
and [configuring Starboard Operator](https://aquasecurity.github.io/starboard/v0.10.3/operator/configuration/#install-modes)
and [configuring Starboard Operator](https://aquasecurity.github.io/starboard/v0.10.3/operator/configuration/#install-modes)
to install in restricted mode.
to install in restricted mode.
## Configuration
### Configuration
To include the `Cluster-Image-Scanning.gitlab-ci.yml` template (GitLab 14.1 and later), add the
To include the `Cluster-Image-Scanning.gitlab-ci.yml` template (GitLab 14.1 and later), add the
following to your `.gitlab-ci.yml` file:
following to your `.gitlab-ci.yml` file:
...
@@ -149,7 +157,7 @@ GitLab saves the results as a
...
@@ -149,7 +157,7 @@ GitLab saves the results as a
that you can download and analyze later. When downloading, you always receive the most recent
that you can download and analyze later. When downloading, you always receive the most recent
artifact.
artifact.
### Customize the cluster image scanning settings
#### Customize the cluster image scanning settings
You can customize how GitLab scans your cluster. For example, to restrict the analyzer to get
You can customize how GitLab scans your cluster. For example, to restrict the analyzer to get
results for only a certain workload, use the [`variables`](../../../ci/yaml/index.md#variables)
results for only a certain workload, use the [`variables`](../../../ci/yaml/index.md#variables)
...
@@ -157,7 +165,7 @@ parameter in your `.gitlab-ci.yml` to set [CI/CD variables](#cicd-variables-for-
...
@@ -157,7 +165,7 @@ parameter in your `.gitlab-ci.yml` to set [CI/CD variables](#cicd-variables-for-
The variables you set in your `.gitlab-ci.yml` overwrite those in
The variables you set in your `.gitlab-ci.yml` overwrite those in
`Cluster-Image-Scanning.gitlab-ci.yml`.
`Cluster-Image-Scanning.gitlab-ci.yml`.
#### CI/CD variables for cluster image scanning
##### CI/CD variables for cluster image scanning
You can [configure](#customize-the-cluster-image-scanning-settings) analyzers by using the following CI/CD variables:
You can [configure](#customize-the-cluster-image-scanning-settings) analyzers by using the following CI/CD variables:
...
@@ -169,7 +177,7 @@ You can [configure](#customize-the-cluster-image-scanning-settings) analyzers by
...
@@ -169,7 +177,7 @@ You can [configure](#customize-the-cluster-image-scanning-settings) analyzers by
| `CIS_RESOURCE_NAMESPACE` | `""` | Namespace of the Kubernetes resource you want to filter vulnerabilities for. For example, `production`. |
| `CIS_RESOURCE_NAMESPACE` | `""` | Namespace of the Kubernetes resource you want to filter vulnerabilities for. For example, `production`. |
| `CIS_RESOURCE_KIND` | `""` | Kind of the Kubernetes resource you want to filter vulnerabilities for. For example, `deployment`. |
| `CIS_RESOURCE_KIND` | `""` | Kind of the Kubernetes resource you want to filter vulnerabilities for. For example, `deployment`. |
### Override the cluster image scanning template
#### Override the cluster image scanning template
If you want to override the job definition (for example, to change properties like `variables`), you
If you want to override the job definition (for example, to change properties like `variables`), you
must declare and override a job after the template inclusion, and then
must declare and override a job after the template inclusion, and then
...
@@ -186,7 +194,7 @@ cluster_image_scanning:
...
@@ -186,7 +194,7 @@ cluster_image_scanning:
CIS_RESOURCE_NAME:nginx
CIS_RESOURCE_NAME:nginx
```
```
### Connect with Kubernetes cluster associated to the project
#### Connect with Kubernetes cluster associated to the project
If you want to connect to the Kubernetes cluster associated with the project and run Cluster Image Scanning jobs without
If you want to connect to the Kubernetes cluster associated with the project and run Cluster Image Scanning jobs without
configuring the `CIS_KUBECONFIG` variable, you must extend `cluster_image_scanning` and specify the environment you want to scan.
configuring the `CIS_KUBECONFIG` variable, you must extend `cluster_image_scanning` and specify the environment you want to scan.
...
@@ -200,7 +208,7 @@ cluster_image_scanning:
...
@@ -200,7 +208,7 @@ cluster_image_scanning:
action:prepare
action:prepare
```
```
## Reports JSON format
### Reports JSON format
The cluster image scanning tool emits a JSON report file. For more information, see the
The cluster image scanning tool emits a JSON report file. For more information, see the
[schema for this report](https://gitlab.com/gitlab-org/security-products/security-report-schemas/-/blob/master/dist/container-scanning-report-format.json).
[schema for this report](https://gitlab.com/gitlab-org/security-products/security-report-schemas/-/blob/master/dist/container-scanning-report-format.json).
...
@@ -265,6 +273,27 @@ Here's an example cluster image scanning report:
...
@@ -265,6 +273,27 @@ Here's an example cluster image scanning report:
}
}
```
```
## Cluster image scanning with the GitLab Kubernetes Agent
You can use the [GitLab Kubernetes Agent](../../clusters/agent/index.md) to
scan images from within your Kubernetes cluster and record the vulnerabilities in GitLab.
You can use [cluster image scanning](../../application_security/cluster_image_scanning/index.md)
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's `config.yaml` with no `filters`:
```yaml
starboard:
vulnerability_reports:
filters:[]
```
The namespaces that are able to be scanned depend on the [Starboard Operator install mode](https://aquasecurity.github.io/starboard/latest/operator/configuration/#install-modes).
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
```yaml
starboard:
vulnerability_reports:
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`:
```yaml
starboard:
vulnerability_reports:
filters:
-kinds:
-Deployment
containers:
-ruby
-postgres
-nginx
```
There is also a global `namespaces` field that applies to all filters:
```yaml
starboard:
vulnerability_reports:
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
## Debugging
## Debugging
To debug the cluster-side component (`agentk`) of the GitLab Kubernetes Agent, set the log
To debug the cluster-side component (`agentk`) of the GitLab Kubernetes Agent, set the log