Skip to content

G
gitlab-ce
Commit e5a77123 authored by Alan Paruszewski's avatar Alan Paruszewski
Browse files
Options

Remove documentation for GitLab WAF 

This change removes documentation for GitLab WAF.

Changelog: removed
parent 631c7c83
Expand all Hide whitespace changes
Inline Side-by-side
Showing with 3 additions and 541 deletions
doc/topics/autodevops/customize.md
View file @ e5a77123
......@@ -337,7 +337,6 @@ applications.
| `AUTO_DEVOPS_CHART_REPOSITORY_PASSWORD` | From GitLab 11.11, used to set a password to connect to the Helm repository. Defaults to no credentials. Also set `AUTO_DEVOPS_CHART_REPOSITORY_USERNAME`. |
| `AUTO_DEVOPS_DEPLOY_DEBUG` | From GitLab 13.1, if this variable is present, Helm outputs debug logs. |
| `AUTO_DEVOPS_ALLOW_TO_FORCE_DEPLOY_V<N>` | From [auto-deploy-image](https://gitlab.com/gitlab-org/cluster-integration/auto-deploy-image) v1.0.0, if this variable is present, a new major version of chart is forcibly deployed. For more information, see [Ignore warnings and continue deploying](upgrading_auto_deploy_dependencies.md#ignore-warnings-and-continue-deploying). |
| `AUTO_DEVOPS_MODSECURITY_SEC_RULE_ENGINE` | From GitLab 12.5, used in combination with [ModSecurity feature flag](../../user/clusters/applications.md#web-application-firewall-modsecurity) to toggle [ModSecurity's `SecRuleEngine`](https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-(v2.x)#SecRuleEngine) behavior. Defaults to `DetectionOnly`. |
| `BUILDPACK_URL` | Buildpack's full URL. Can point to either [a Git repository URL or a tarball URL](#custom-buildpacks). |
| `CANARY_ENABLED` | From GitLab 11.0, used to define a [deploy policy for canary environments](#deploy-policy-for-canary-environments). |
| `CANARY_PRODUCTION_REPLICAS` | Number of canary replicas to deploy for [Canary Deployments](../../user/project/canary_deployments.md) in the production environment. Takes precedence over `CANARY_REPLICAS`. Defaults to 1. |
......
doc/topics/autodevops/stages.md
View file @ e5a77123
......@@ -645,42 +645,6 @@ ciliumNetworkPolicy:
For more information on installing Network Policies, see
[Install Cilium using GitLab CI/CD](../../user/clusters/applications.md#install-cilium-using-gitlab-cicd).
### Web Application Firewall (ModSecurity) customization
> [Introduced](https://gitlab.com/gitlab-org/charts/auto-deploy-app/-/merge_requests/44) in GitLab 12.8.
Customization on an [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/)
or on a deployment base is available for clusters with
[ModSecurity installed](../../user/clusters/applications.md#web-application-firewall-modsecurity).
To enable ModSecurity with Auto Deploy, you must create a `.gitlab/auto-deploy-values.yaml`
file in your project with the following attributes.
|Attribute | Description | Default |
-----------|-------------|---------|
|`enabled` | Enables custom configuration for ModSecurity, defaulting to the [Core Rule Set](https://coreruleset.org/) | `false` |
|`secRuleEngine` | Configures the [rules engine](https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-(v2.x)#secruleengine) | `DetectionOnly` |
|`secRules` | Creates one or more additional [rule](https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-(v2.x)#SecRule) | `nil` |
In the following `auto-deploy-values.yaml` example, some custom settings
are enabled for ModSecurity. Those include setting its engine to
process rules instead of only logging them, while adding two specific
header-based rules:
```yaml
ingress:
modSecurity:
enabled: true
secRuleEngine: "On"
secRules:
- variable: "REQUEST_HEADERS:User-Agent"
operator: "printer"
action: "log,deny,id:'2010',status:403,msg:'printer is an invalid agent'"
- variable: "REQUEST_HEADERS:Content-Type"
operator: "text/plain"
action: "log,deny,id:'2011',status:403,msg:'Text is not supported as content type'"
```
### Running commands in the container
Applications built with [Auto Build](#auto-build) using Herokuish, the default
......
doc/user/application_security/threat_monitoring/index.md
View file @ e5a77123
......@@ -16,34 +16,8 @@ Monitoring** page.
GitLab supports statistics for the following security features:
- [Web Application Firewall](../../clusters/applications.md#web-application-firewall-modsecurity)
- [Container Network Policies](../../../topics/autodevops/stages.md#network-policy)
## Web Application Firewall
The Web Application Firewall section provides metrics for the NGINX
Ingress controller and ModSecurity firewall. This section has the
following prerequisites:
- Project has to have at least one [environment](../../../ci/environments/index.md).
- [Web Application Firewall](../../clusters/applications.md#web-application-firewall-modsecurity) has to be enabled.
- [Elastic Stack](../../clusters/applications.md#web-application-firewall-modsecurity) has to be installed.
If you are using custom Helm values for the Elastic Stack you have to
configure Filebeat similarly to the [vendored values](https://gitlab.com/gitlab-org/gitlab/-/blob/f610a080b1ccc106270f588a50cb3c07c08bdd5a/vendor/elastic_stack/values.yaml).
The **Web Application Firewall** section displays the following information
about your Ingress traffic:
- The total amount of requests to your application
- The proportion of traffic that is considered anomalous according to
the configured rules
- The request breakdown graph for the selected time interval
If a significant percentage of traffic is anomalous, you should
investigate it for potential threats by
[examining the Web Application Firewall logs](../../clusters/applications.md#web-application-firewall-modsecurity).
## Container Network Policy
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/32365) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 12.9.
......
doc/user/clusters/applications.md
View file @ e5a77123
......@@ -34,7 +34,7 @@ Despite being deprecated, the recommended way for installing GitLab integrated a
> - [Deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/327908) in GitLab 13.12.
WARNING:
The GitLab Managed Apps CI/CD installation method was [deprecated in 13.12](https://gitlab.com/gitlab-org/gitlab/-/issues/327908).
The GitLab Managed Apps CI/CD installation method was [deprecated in 13.12](https://gitlab.com/gitlab-org/gitlab/-/issues/327908).
Your applications continue to work. However, we no longer support and maintain the GitLab CI/CD template for
Managed Apps (`Managed-Cluster-Applications.gitlab-ci.yml`).
As a replacement, we are working on a [cluster management project template](https://gitlab.com/gitlab-org/gitlab/-/issues/327908),
......@@ -404,9 +404,9 @@ These values can be specified using [CI/CD variables](../../ci/variables/README.
- `GITLAB_RUNNER_GITLAB_URL` is used for `gitlabUrl`.
- `GITLAB_RUNNER_REGISTRATION_TOKEN` is used for `runnerRegistrationToken`
The methods of specifying these values are mutually exclusive. Either specify variables `GITLAB_RUNNER_REGISTRATION_TOKEN` and `GITLAB_RUNNER_TOKEN` as CI variables (recommended) or provide values for `runnerRegistrationToken:` and `runnerToken:` in `.gitlab/managed-apps/gitlab-runner/values.yaml`. If you choose to use CI variables, comment out or remove `runnerRegistrationToken:` and `runnerToken:` from `.gitlab/managed-apps/gitlab-runner/values`.
The methods of specifying these values are mutually exclusive. Either specify variables `GITLAB_RUNNER_REGISTRATION_TOKEN` and `GITLAB_RUNNER_TOKEN` as CI variables (recommended) or provide values for `runnerRegistrationToken:` and `runnerToken:` in `.gitlab/managed-apps/gitlab-runner/values.yaml`. If you choose to use CI variables, comment out or remove `runnerRegistrationToken:` and `runnerToken:` from `.gitlab/managed-apps/gitlab-runner/values`.
The runner registration token allows connection to a project by a runner and therefore should be treated as a secret to prevent malicious use and code exfiltration through a runner. For this reason, we recommend that you specify the runner registration token as a [protected variable](../../ci/variables/README.md#protect-a-cicd-variable) and [masked variable](../../ci/variables/README.md#mask-a-cicd-variable) and do not commit them to the Git repository in the `values.yaml` file.
The runner registration token allows connection to a project by a runner and therefore should be treated as a secret to prevent malicious use and code exfiltration through a runner. For this reason, we recommend that you specify the runner registration token as a [protected variable](../../ci/variables/README.md#protect-a-cicd-variable) and [masked variable](../../ci/variables/README.md#mask-a-cicd-variable) and do not commit them to the Git repository in the `values.yaml` file.
You can customize the installation of GitLab Runner by defining
`.gitlab/managed-apps/gitlab-runner/values.yaml` file in your cluster
......@@ -1260,108 +1260,6 @@ as `*.example.com.`) to reach your apps. If your external endpoint is an IP
address, use an A record. If your external endpoint is a hostname, use a CNAME
record.
#### Web Application Firewall (ModSecurity)
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/21966) in GitLab 12.7.
WARNING:
The Web Application Firewall is in its end-of-life process. It is [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/271276)
in GitLab 13.6, and planned for [removal](https://gitlab.com/gitlab-org/gitlab/-/issues/271349)
in GitLab 14.0.
A Web Application Firewall (WAF) examines traffic being sent or received,
and can block malicious traffic before it reaches your application. The benefits
of a WAF are:
- Real-time security monitoring for your application.
- Logging of all your HTTP traffic to the application.
- Access control for your application.
- Highly configurable logging and blocking rules.
By default, GitLab provides you with a WAF known as [`ModSecurity`](https://www.modsecurity.org/),
which is a toolkit for real-time web application monitoring, logging, and access
control. GitLab applies the [OWASP's Core Rule Set](https://coreruleset.org/),
which provides generic attack detection capabilities.
This feature:
- Runs in "Detection-only mode" unless configured otherwise.
- Is viewable by checking your Ingress controller's `modsec` log for rule violations.
For example:
```shell
kubectl -n gitlab-managed-apps logs -l app=nginx-ingress,component=controller -c modsecurity-log -f
```
To enable WAF, switch its respective toggle to the enabled position when installing
or updating [Ingress application](#ingress).
If this is your first time using the GitLab WAF, we recommend you follow the
[quick start guide](../project/clusters/protect/web_application_firewall/quick_start_guide.md).
There is a small performance overhead by enabling ModSecurity. If this is
considered significant for your application, you can disable ModSecurity's
rule engine for your deployed application in any of the following ways:
1. Set the [deployment variable](../../topics/autodevops/index.md)
`AUTO_DEVOPS_MODSECURITY_SEC_RULE_ENGINE` to `Off` to prevent ModSecurity
from processing any requests for the given application or environment.
1. Switch its respective toggle to the disabled position, and then apply changes
by selecting **Save changes** to reinstall Ingress with the recent changes.
![Disabling WAF](../project/clusters/protect/web_application_firewall/img/guide_waf_ingress_save_changes_v12_10.png)
##### Logging and blocking modes
To help you tune your WAF rules, you can globally set your WAF to either
*Logging* or *Blocking* mode:
- *Logging mode*: Allows traffic matching the rule to pass, and logs the event.
- *Blocking mode*: Prevents traffic matching the rule from passing, and logs the event.
To change your WAF's mode:
1. If you haven't already done so,
[install ModSecurity](../project/clusters/protect/web_application_firewall/quick_start_guide.md).
1. Navigate to **Operations > Kubernetes**.
1. In **Applications**, scroll to **Ingress**.
1. Under **Global default**, select your desired mode.
1. Select **Save changes**.
##### WAF version updates
Enabling, disabling, or changing the logging mode for **ModSecurity** is only
allowed in same version of [Ingress](#ingress) due to limitations in
[Helm](https://helm.sh/) which might be overcome in future releases.
The **ModSecurity** user interface controls are disabled if the version deployed
differs from the one available in GitLab. However, actions at the [Ingress](#ingress)
level, such as uninstalling, can still be performed:
![WAF settings disabled](../project/clusters/protect/web_application_firewall/img/guide_waf_ingress_disabled_settings_v12_10.png)
Update [Ingress](#ingress) to the most recent version to take advantage of bug
fixes, security fixes, and performance improvements. To update the
[Ingress application](#ingress), you must first uninstall it, and then re-install
it as described in [Install ModSecurity](../project/clusters/protect/web_application_firewall/quick_start_guide.md).
##### Viewing Web Application Firewall traffic
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/14707) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 12.9.
You can view Web Application Firewall traffic by navigating to your project's
**Security & Compliance > Threat Monitoring** page. From there, you can see
tracked over time:
- The total amount of traffic to your application.
- The proportion of traffic that's considered anomalous by the Web Application
Firewall's default [OWASP ruleset](https://coreruleset.org/).
If a significant percentage of traffic is anomalous, investigate it for potential threats
by [examining the Web Application Firewall logs](#web-application-firewall-modsecurity).
![Threat Monitoring](img/threat_monitoring_v12_9.png)
### JupyterHub
> - Introduced in GitLab 11.0 for project-level clusters.
......
doc/user/project/clusters/protect/index.md
View file @ e5a77123
......@@ -18,9 +18,6 @@ containers themselves.
The following capabilities are available to protect deployed applications in Kubernetes:
- Web Application Firewall
- [Overview](web_application_firewall/index.md)
- [Installation guide](web_application_firewall/quick_start_guide.md)
- Container Network Security
- [Overview](container_network_security/index.md)
- [Installation guide](container_network_security/quick_start_guide.md)
......
doc/user/project/clusters/protect/web_application_firewall/index.md deleted 100644 → 0
View file @ 631c7c83
---
stage: Protect
group: Container Security
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/#assignments
---
# Web Application Firewall
WARNING:
The Web Application Firewall is in its end-of-life process. It is [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/271276)
in GitLab 13.6, and planned for [removal](https://gitlab.com/gitlab-org/gitlab/-/issues/271349)
in GitLab 14.0.
A web application firewall (or WAF) filters, monitors, and blocks HTTP traffic to
and from a web application. By inspecting HTTP traffic, it can prevent attacks
stemming from web application security flaws. It can be used to detect SQL injection,
Cross-Site Scripting (XSS), Remote File Inclusion, Security Misconfigurations, and
much more.
## Overview
GitLab provides a WAF out of the box after Ingress is deployed. All you need to do is deploy your
application along with a service and Ingress resource. In the GitLab [Ingress](../../../../clusters/applications.md#ingress)
deployment, the [ModSecurity](https://modsecurity.org/)
module is loaded into Ingress-NGINX by default and monitors the traffic to the applications
which have an Ingress. The ModSecurity module runs with the [OWASP Core Rule Set (CRS)](https://coreruleset.org/)
by default. The OWASP CRS detects and logs a wide range of common attacks.
By default, the WAF is deployed in Detection-only mode and only logs attack attempts.
## Requirements
The Web Application Firewall requires:
- **Kubernetes**
To enable the WAF, you need:
- Kubernetes 1.12+.
- A load balancer. You can use NGINX-Ingress by deploying it to your
Kubernetes cluster by either:
- Using the [`nginx-ingress` Helm chart](https://github.com/helm/charts/tree/master/stable/nginx-ingress).
- Installing the [Ingress GitLab Managed App](../../../../clusters/applications.md#ingress) with WAF enabled.
- **Configured Kubernetes objects**
To use the WAF on an application, you need to deploy the following Kubernetes resources:
- [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)
- [Service](https://kubernetes.io/docs/concepts/services-networking/service/)
- [Ingress Resource](https://kubernetes.io/docs/concepts/services-networking/ingress/)
## Quick start
If you are using GitLab.com, see the [quick start guide](quick_start_guide.md) for
how to use the WAF with GitLab.com and a Kubernetes cluster on Google Kubernetes Engine (GKE).
If you are using a self-managed instance of GitLab, you must configure the
[Google OAuth2 OmniAuth Provider](../../../../../integration/google.md) before
you can configure a cluster on GKE. Once this is set up, you can follow the steps on the
[quick start guide](quick_start_guide.md)
to get started.
NOTE:
This guide shows how the WAF can be deployed using Auto DevOps. The WAF
is available by default to all applications no matter how they are deployed,
as long as they are using Ingress.
## Network firewall vs. Web Application Firewall
A network firewall or packet filter looks at traffic at the Network (L3) and Transport (L4) layers
of the [OSI Model](https://en.wikipedia.org/wiki/OSI_model), and denies packets from entry based on
a set of rules regarding the network in general.
A Web Application Firewall operates at the Application (L7) layer of the OSI Model and can
examine all the packets traveling to and from a specific application. A WAF can set
more advanced rules around threat detection.
## Features
ModSecurity is enabled with the [OWASP Core Rule Set (CRS)](https://github.com/coreruleset/coreruleset/) by
default. The OWASP CRS logs attempts to the following attacks:
- [SQL Injection](https://wiki.owasp.org/index.php/OWASP_Periodic_Table_of_Vulnerabilities_-_SQL_Injection)
- [Cross-Site Scripting](https://wiki.owasp.org/index.php/OWASP_Periodic_Table_of_Vulnerabilities_-_Cross-Site_Scripting_(XSS))
- [Local File Inclusion](https://wiki.owasp.org/index.php/Testing_for_Local_File_Inclusion)
- [Remote File Inclusion](https://wiki.owasp.org/index.php/OWASP_Periodic_Table_of_Vulnerabilities_-_Remote_File_Inclusion)
- [Code Injection](https://wiki.owasp.org/index.php/Code_Injection)
- [Session Fixation](https://wiki.owasp.org/index.php/Session_fixation)
- [Scanner Detection](https://wiki.owasp.org/index.php/Category:Vulnerability_Scanning_Tools)
- [Metadata/Error Leakages](https://wiki.owasp.org/index.php/Improper_Error_Handling)
It is good to have a basic knowledge of the following:
- [Kubernetes](https://kubernetes.io/docs/home/)
- [Ingress](https://kubernetes.github.io/ingress-nginx/)
- [ModSecurity](https://www.modsecurity.org/)
- [OWASP Core Rule Set](https://github.com/coreruleset/coreruleset/)
## Roadmap
You can find more information on the product direction of the WAF in
[Category Direction - Web Application Firewall](https://about.gitlab.com/direction/protect/web_application_firewall/).
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7