diff options
Diffstat (limited to 'doc/topics/web_application_firewall/quick_start_guide.md')
-rw-r--r-- | doc/topics/web_application_firewall/quick_start_guide.md | 48 |
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> |