diff options
Diffstat (limited to 'doc/topics/web_application_firewall')
| -rw-r--r-- | doc/topics/web_application_firewall/index.md | 8 | ||||
| -rw-r--r-- | doc/topics/web_application_firewall/quick_start_guide.md | 48 |
2 files changed, 28 insertions, 28 deletions
diff --git a/doc/topics/web_application_firewall/index.md b/doc/topics/web_application_firewall/index.md index 83b3bfb1cef..1c1728d9277 100644 --- a/doc/topics/web_application_firewall/index.md +++ b/doc/topics/web_application_firewall/index.md @@ -1,7 +1,7 @@ --- 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/#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/#assignments --- @@ -16,9 +16,9 @@ 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 GitLab's [Ingress](../../user/clusters/applications.md#ingress) +application along with a service and Ingress resource. In the GitLab [Ingress](../../user/clusters/applications.md#ingress) deployment, the [ModSecurity](https://modsecurity.org/) -module is loaded into Ingress-NGINX by default and monitors the traffic going to the applications +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. @@ -55,7 +55,7 @@ If you are using a self-managed instance of GitLab, you need to 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: **Note:** +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. diff --git a/doc/topics/web_application_firewall/quick_start_guide.md b/doc/topics/web_application_firewall/quick_start_guide.md index 3df22854437..df355ff2413 100644 --- a/doc/topics/web_application_firewall/quick_start_guide.md +++ b/doc/topics/web_application_firewall/quick_start_guide.md @@ -1,50 +1,50 @@ --- 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/#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/#assignments --- # Getting started with the Web Application Firewall -This is a step-by-step guide that will help you use GitLab's [Web Application Firewall](index.md) after +This is a step-by-step guide to help you use the GitLab [Web Application Firewall](index.md) after deploying a project hosted on GitLab.com to Google Kubernetes Engine using [Auto DevOps](../autodevops/index.md). -We will use GitLab's native Kubernetes integration, so you will not need +The GitLab native Kubernetes integration is used, so you do not need to create a Kubernetes cluster manually using the Google Cloud Platform console. -We will create and deploy a simple application that we create from a GitLab template. +A simple application is created and deployed based on a GitLab template. -These instructions will also work for a self-managed GitLab instance. However, you will +These instructions also work for a self-managed GitLab instance. However, you need to ensure your own [runners are configured](../../ci/runners/README.md) and [Google OAuth is enabled](../../integration/google.md). -GitLab's Web Application Firewall is deployed with [Ingress](../../user/clusters/applications.md#ingress), -so it will be available to your applications no matter how you deploy them to Kubernetes. +The GitLab Web Application Firewall is deployed with [Ingress](../../user/clusters/applications.md#ingress), +so it is available to your applications no matter how you deploy them to Kubernetes. ## Configuring your Google account Before creating and connecting your Kubernetes cluster to your GitLab project, you need a Google Cloud Platform account. If you do not already have one, -sign up at <https://console.cloud.google.com>. You will need to either sign in with an existing +sign up at <https://console.cloud.google.com>. You need to either sign in with an existing Google account (for example, one that you use to access Gmail, Drive, etc.) or create a new one. 1. To enable the required APIs and related services, follow the steps in the ["Before you begin" section of the Kubernetes Engine docs](https://cloud.google.com/kubernetes-engine/docs/quickstart#before-you-begin). 1. Make sure you have created a [billing account](https://cloud.google.com/billing/docs/how-to/manage-billing-account). -TIP: **Tip:** +NOTE: Every new Google Cloud Platform (GCP) account receives [$300 in credit](https://console.cloud.google.com/freetrial), -and in partnership with Google, GitLab is able to offer an additional $200 for new GCP accounts to get started with GitLab's +and in partnership with Google, GitLab is able to offer an additional $200 for new GCP accounts to get started with the GitLab Google Kubernetes Engine integration. All you have to do is [follow this link](https://cloud.google.com/partners/partnercredit/?PCN=a0n60000006Vpz4AAC) and apply for credit. ## Creating a new project from a template -We will use one of GitLab's project templates to get started. As the name suggests, +We use a GitLab project templates to get started. As the name suggests, those projects provide a barebones application built on some well-known frameworks. 1. In GitLab, click the plus icon (**+**) at the top of the navigation bar and select **New project**. 1. Go to the **Create from template** tab where you can choose for example a Ruby on Rails, Spring, or NodeJS Express project. - We will use the Ruby on Rails template. + Use the Ruby on Rails template.  @@ -57,7 +57,7 @@ those projects provide a barebones application built on some well-known framewor 1. Click **Create project**. Now that the project is created, the next step is to create the Kubernetes cluster -under which this application will be deployed. +to deploy this application under. ## Creating a Kubernetes cluster from within GitLab @@ -76,9 +76,9 @@ under which this application will be deployed.  1. The last step is to provide the cluster details. - 1. Give it a name, leave the environment scope as is, and choose the GCP project under which the cluster - will be created (per the instructions to [configure your Google account](#configuring-your-google-account), a project should have already been created for you). - 1. Choose the [region/zone](https://cloud.google.com/compute/docs/regions-zones/) under which the cluster will be created. + 1. Give it a name, leave the environment scope as is, and choose the GCP project under which to create the cluster. + (Per the instructions to [configure your Google account](#configuring-your-google-account), a project should have already been created for you.) + 1. Choose the [region/zone](https://cloud.google.com/compute/docs/regions-zones/) to create the cluster in. 1. Enter the number of nodes you want it to have. 1. Choose the [machine type](https://cloud.google.com/compute/docs/machine-types). @@ -94,7 +94,7 @@ to take full advantage of Auto DevOps. ## Install Ingress -GitLab's Kubernetes integration comes with some +The GitLab Kubernetes integration comes with some [pre-defined applications](../../user/project/clusters/index.md#installing-applications) for you to install. @@ -111,14 +111,14 @@ auditing anomalous traffic, blocking mode ensures the traffic doesn't reach past After Ingress is installed, wait a few seconds and copy the IP address that is displayed in order to add in your base **Domain** at the top of the page. For -the purpose of this guide, we will use the one suggested by GitLab. Once you have +the purpose of this guide, we use the one suggested by GitLab. Once you have filled in the domain, click **Save changes**.  Prometheus should also be installed. It is an open-source monitoring and -alerting system that we will use to supervise the deployed application. -We will not install GitLab Runner as we will use the shared runners that +alerting system that is used to supervise the deployed application. +Installing GitLab Runner is not required as we use the shared runners that GitLab.com provides. ## Enabling Auto DevOps (optional) @@ -162,13 +162,13 @@ deploys the application in Kubernetes ([Auto Deploy](../autodevops/stages.md#aut The **production** stage creates Kubernetes objects like a Deployment, Service, and Ingress resource. The -application will be monitored by the WAF automatically. +application is monitored by the WAF automatically. ## Validating Ingress is running ModSecurity Now we can make sure that Ingress is running properly with ModSecurity and send a request to ensure our application is responding correctly. You must connect to -your cluster either using [Cloud Shell](https://cloud.google.com/shell/) or the [Google Cloud SDK](https://cloud.google.com/sdk/install). +your cluster either using [Cloud Shell](https://cloud.google.com/shell/) or the [Google Cloud SDK](https://cloud.google.com/sdk/docs/install). 1. After connecting to your cluster, check if the Ingress-NGINX controller is running and ModSecurity is enabled. @@ -201,7 +201,7 @@ your cluster either using [Cloud Shell](https://cloud.google.com/shell/) or the NAME HOSTS PORTS production-auto-deploy fjdiaz-auto-devv-2.34.68.60.207.nip.io,le-16730183.34.68.60.207.nip.io 80, 443 - $ curl --location --insecure fjdiaz-auto-devv-2.34.68.60.207.nip.io | grep 'Rails!' --after 2 --before 2 + $ curl --location --insecure "fjdiaz-auto-devv-2.34.68.60.207.nip.io" | grep 'Rails!' --after 2 --before 2 <body> <p>You're on Rails!</p> </body> @@ -216,7 +216,7 @@ Now let's send a potentially malicious request, as if we were a scanner, checking for vulnerabilities within our application and examine the ModSecurity logs: ```shell -$ curl --location --insecure fjdiaz-auto-devv-2.34.68.60.207.nip.io --header "User-Agent: absinthe" | grep 'Rails!' --after 2 --before 2 +$ curl --location --insecure "fjdiaz-auto-devv-2.34.68.60.207.nip.io" --header "User-Agent: absinthe" | grep 'Rails!' --after 2 --before 2 <body> <p>You're on Rails!</p> </body> |