summaryrefslogtreecommitdiff
path: root/doc/topics/web_application_firewall/quick_start_guide.md
diff options
context:
space:
mode:
Diffstat (limited to 'doc/topics/web_application_firewall/quick_start_guide.md')
-rw-r--r--doc/topics/web_application_firewall/quick_start_guide.md48
1 files changed, 24 insertions, 24 deletions
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.
![Select project template](../autodevops/img/guide_project_template_v12_3.png)
@@ -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.
![Google auth](../autodevops/img/guide_google_auth_v12_3.png)
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**.
![Cluster Base Domain](../autodevops/img/guide_base_domain_v12_3.png)
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>