info:To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
info:To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
---
---
# Scan Policies **(ULTIMATE)**
# Policies **(ULTIMATE)**
> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/5329) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 13.10.
> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/5329) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 13.10. Deployed behind a feature flag, disabled by default.
> - Deployed behind a feature flag, disabled by default.
> - [Enabled on self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/321258) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 14.3.
> - Disabled on GitLab.com.
Scan Policies in GitLab provide security teams a way to require scans of their choice to be run
FLAG:
On self-managed GitLab, by default this feature is available. To hide the feature,
ask an administrator to [disable the `security_orchestration_policies_configuration` flag](../../../administration/feature_flags.md).
On GitLab.com, this feature is not available.
Policies in GitLab provide security teams a way to require scans of their choice to be run
whenever a project pipeline runs according to the configuration specified. Security teams can
whenever a project pipeline runs according to the configuration specified. Security teams can
therefore be confident that the scans they set up have not been changed, altered, or disabled. You
therefore be confident that the scans they set up have not been changed, altered, or disabled. You
can access these by navigating to your project's **Security & Compliance > Scan Policies** page.
can access these by navigating to your project's **Security & Compliance > Policies** page.
- You've configured the [Prometheus service](../../project/integrations/prometheus.md#enabling-prometheus-integration).
If you're using custom Helm values for Cilium, you must enable Hubble
with flow metrics for each namespace by adding the following lines to
your [Cilium values](../../project/clusters/protect/container_network_security/quick_start_guide.md#use-the-cluster-management-template-to-install-cilium):
Once your policy is complete, save it by selecting **Save policy**
at the bottom of the editor. Existing policies can also be
removed from the editor interface by selecting **Delete policy**
at the bottom of the editor.
### Configure a Network Policy Alert
> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/3438) and [enabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/287676) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 13.9.
> - The feature flag was removed and the Threat Monitoring Alerts Project was [made generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/287676) in GitLab 14.0.
You can use policy alerts to track your policy's impact. Alerts are only available if you've
[installed](../../clusters/agent/repository.md)
and [configured](../../clusters/agent/index.md#create-an-agent-record-in-gitlab)
a Kubernetes Agent for this project.
There are two ways to create policy alerts:
- In the [policy editor UI](#container-network-policy-editor),
by clicking **Add alert**.
- In the policy editor's YAML mode, through the `metadata.annotations` property:
```yaml
metadata:
annotations:
app.gitlab.com/alert:'true'
```
Once added, the UI updates and displays a warning about the dangers of too many alerts.
## Security Policies project
## Security Policies project
NOTE:
We recommend using the [Security Policies project](#security-policies-project)
exclusively for managing policies for the project. Do not add your application's source code to such
projects.
The Security Policies feature is a repository to store policies. All security policies are stored as
The Security Policies feature is a repository to store policies. All security policies are stored as
the `.gitlab/security-policies/policy.yml` YAML file with this format:
the `.gitlab/security-policies/policy.yml` YAML file with this format:
...
@@ -85,6 +217,40 @@ scan_execution_policy:
...
@@ -85,6 +217,40 @@ scan_execution_policy:
site_profile: Site Profile D
site_profile: Site Profile D
```
```
## Security Policy project selection
NOTE:
Only project Owners have the [permissions](../../permissions.md#project-members-permissions)
to select Security Policy Project.
When the Security Policy project is created and policies are created within that repository, you
must create an association between that project and the project you want to apply policies to:
1. On the top bar, select **Menu > Projects** and find your project.
1. On the left sidebar, select **Security & Compliance > Policies**.
1. Select **Edit Policy Project**, and search for and select the
project you would like to link from the dropdown menu.
The policy editor currently only supports the YAML mode. The Rule mode is tracked in the [Allow Users to Edit Rule-mode Scan Execution Policies in the Policy UI](https://gitlab.com/groups/gitlab-org/-/epics/5363) epic.
### Scan Execution Policies Schema
### Scan Execution Policies Schema
The YAML file with Scan Execution Policies consists of an array of objects matching Scan Execution Policy Schema nested under the `scan_execution_policy` key. You can configure a maximum of 5 policies under the `scan_execution_policy` key.
The YAML file with Scan Execution Policies consists of an array of objects matching Scan Execution Policy Schema nested under the `scan_execution_policy` key. You can configure a maximum of 5 policies under the `scan_execution_policy` key.
...
@@ -198,21 +364,6 @@ In this example:
...
@@ -198,21 +364,6 @@ In this example:
and `Site Profile D`.
and `Site Profile D`.
- Secret detection scans run for every pipeline executed on the `main` branch.
- Secret detection scans run for every pipeline executed on the `main` branch.
## Security Policy project selection
When the Security Policy project is created and policies are created within that repository, you
must create an association between that project and the project you want to apply policies to. To do
this, navigate to your project's **Security & Compliance > Policies**, select
**Security policy project** from the dropdown menu, then select the **Create policy** button to save
changes.
You can always change the **Security policy project** by navigating to your project's
**Security & Compliance > Policies** and modifying the selected project.
NOTE:
Only project Owners have the [permissions](../../permissions.md#project-members-permissions)
to select Security Policy Project.
## Roadmap
## Roadmap
See the [Category Direction page](https://about.gitlab.com/direction/protect/container_network_security/)
See the [Category Direction page](https://about.gitlab.com/direction/protect/container_network_security/)
- You've configured the [Prometheus service](../../project/integrations/prometheus.md#enabling-prometheus-integration)
If you're using custom Helm values for Cilium, you must enable Hubble
with flow metrics for each namespace by adding the following lines to
your [Cilium values](../../project/clusters/protect/container_network_security/quick_start_guide.md#use-the-cluster-management-template-to-install-cilium):
Once your policy is complete, save it by pressing the **Save policy**
button at the bottom of the editor. Existing policies can also be
removed from the editor interface by clicking the **Delete policy**
button at the bottom of the editor.
### Configuring Network Policy Alerts
> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/3438) and [enabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/287676) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 13.9.
> - The feature flag was removed and the Threat Monitoring Alerts Project was [made generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/287676) in GitLab 14.0.
You can use policy alerts to track your policy's impact. Alerts are only available if you've
[installed](../../clusters/agent/repository.md)
and [configured](../../clusters/agent/index.md#create-an-agent-record-in-gitlab)
a Kubernetes Agent for this project.
There are two ways to create policy alerts:
- In the [policy editor UI](#container-network-policy-editor),
by clicking **Add alert**.
- In the policy editor's YAML mode, through the `metadata.annotations` property:
```yaml
metadata:
annotations:
app.gitlab.com/alert:'true'
```
Once added, the UI updates and displays a warning about the dangers of too many alerts.
### Container Network Policy Alert list
> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/3438) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 13.9.
> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/3438) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 13.9.
...
@@ -184,7 +38,7 @@ the selector menu in the **Status** column to set the status for each alert:
...
@@ -184,7 +38,7 @@ the selector menu in the **Status** column to set the status for each alert:
By default, the list doesn't display resolved or dismissed alerts.
By default, the list doesn't display resolved or dismissed alerts.
@@ -20,7 +20,7 @@ tasks in a secure and cloud-native way. It enables:
...
@@ -20,7 +20,7 @@ tasks in a secure and cloud-native way. It enables:
- Pull-based GitOps deployments.
- Pull-based GitOps deployments.
-[Inventory object](../../infrastructure/clusters/deploy/inventory_object.md) to keep track of objects applied to your cluster.
-[Inventory object](../../infrastructure/clusters/deploy/inventory_object.md) to keep track of objects applied to your cluster.
- Real-time access to API endpoints in a cluster.
- Real-time access to API endpoints in a cluster.
- Alert generation based on [Container network policy](../../application_security/threat_monitoring/index.md#container-network-policy).
- Alert generation based on [Container network policy](../../application_security/policies/index.md#container-network-policy).
-[CI/CD Tunnel](ci_cd_tunnel.md) that enables users to access Kubernetes clusters from GitLab CI/CD jobs even if there is no network connectivity between GitLab Runner and a cluster.
-[CI/CD Tunnel](ci_cd_tunnel.md) that enables users to access Kubernetes clusters from GitLab CI/CD jobs even if there is no network connectivity between GitLab Runner and a cluster.
Many more features are planned. Please review [our roadmap](https://gitlab.com/groups/gitlab-org/-/epics/3329)
Many more features are planned. Please review [our roadmap](https://gitlab.com/groups/gitlab-org/-/epics/3329)
...
@@ -435,8 +435,8 @@ There are several components that work in concert for the Agent to generate the
...
@@ -435,8 +435,8 @@ There are several components that work in concert for the Agent to generate the
- Enablement of [hubble-relay](https://docs.cilium.io/en/v1.8/concepts/overview/#hubble) on an
- Enablement of [hubble-relay](https://docs.cilium.io/en/v1.8/concepts/overview/#hubble) on an
existing installation.
existing installation.
- One or more network policies through any of these options:
- One or more network policies through any of these options:
- Use the [Container Network Policy editor](../../application_security/threat_monitoring/index.md#container-network-policy-editor) to create and manage policies.
- Use the [Container Network Policy editor](../../application_security/policies/index.md#container-network-policy-editor) to create and manage policies.
- Use an [AutoDevOps](../../application_security/threat_monitoring/index.md#container-network-policy-management) configuration.
- Use an [AutoDevOps](../../application_security/policies/index.md#container-network-policy) configuration.
- Add the required labels and annotations to existing network policies.
- Add the required labels and annotations to existing network policies.
- A configuration repository with [Cilium configured in `config.yaml`](repository.md#surface-network-security-alerts-from-cluster-to-gitlab)
- A configuration repository with [Cilium configured in `config.yaml`](repository.md#surface-network-security-alerts-from-cluster-to-gitlab)
@@ -137,7 +137,7 @@ Network Policies can be managed through GitLab in one of two ways:
...
@@ -137,7 +137,7 @@ Network Policies can be managed through GitLab in one of two ways:
- Management through a YAML file in each application's project (for projects using Auto DevOps). For
- Management through a YAML file in each application's project (for projects using Auto DevOps). For
more information, see the [Network Policy documentation](../../../../../topics/autodevops/stages.md#network-policy).
more information, see the [Network Policy documentation](../../../../../topics/autodevops/stages.md#network-policy).
- Management through the GitLab Policy management UI (for projects not using Auto DevOps). For more
- Management through the GitLab Policy management UI (for projects not using Auto DevOps). For more
information, see the [Container Network Policy documentation](../../../../application_security/threat_monitoring/index.md#container-network-policy-management)(Ultimate only).
information, see the [Container Network Policy documentation](../../../../application_security/policies/index.md#container-network-policy)(Ultimate only).
Each method has benefits and drawbacks:
Each method has benefits and drawbacks:
...
@@ -167,7 +167,7 @@ hubble:
...
@@ -167,7 +167,7 @@ hubble:
```
```
Additional information about the statistics page is available in the
Additional information about the statistics page is available in the
[documentation that describes the Threat Management UI](../../../../application_security/threat_monitoring/index.md#container-network-policy).
[documentation that describes the Threat Management UI](../../../../application_security/policies/index.md#container-network-policy).