Update Readme.md: gcs to bq + cloud armor / glb

examples/README.md

@@ -4,7 +4,7 @@ This section contains **[foundational examples](./foundations/)** that bootstrap
 
 Currently available examples:
 
-- **cloud operations** - [Resource tracking and remediation via Cloud Asset feeds](./cloud-operations/asset-inventory-feed-remediation), [Granular Cloud DNS IAM via Service Directory](./cloud-operations/dns-fine-grained-iam), [Granular Cloud DNS IAM for Shared VPC](./cloud-operations/dns-shared-vpc), [Compute Engine quota monitoring](./cloud-operations/quota-monitoring), [Scheduled Cloud Asset Inventory Export to Bigquery](./cloud-operations/scheduled-asset-inventory-export-bq), [Packer image builder](./cloud-operations/packer-image-builder), [On-prem SA key management](./cloud-operations/onprem-sa-key-management), [TCP healthcheck for unmanaged GCE instances](./cloud-operations/unmanaged-instances-healthcheck)
+- **cloud operations** - [Resource tracking and remediation via Cloud Asset feeds](./cloud-operations/asset-inventory-feed-remediation), [Granular Cloud DNS IAM via Service Directory](./cloud-operations/dns-fine-grained-iam), [Granular Cloud DNS IAM for Shared VPC](./cloud-operations/dns-shared-vpc), [Compute Engine quota monitoring](./cloud-operations/quota-monitoring), [Scheduled Cloud Asset Inventory Export to Bigquery](./cloud-operations/scheduled-asset-inventory-export-bq), [Packer image builder](./cloud-operations/packer-image-builder), [On-prem SA key management](./cloud-operations/onprem-sa-key-management), [TCP healthcheck for unmanaged GCE instances](./cloud-operations/unmanaged-instances-healthcheck), [HTTP Load Balancer with Cloud Armor](./cloud-operations/glb_and_armor)
 - **data solutions** - [GCE/GCS CMEK via centralized Cloud KMS](./data-solutions/gcs-to-bq-with-least-privileges/), [Cloud Storage to Bigquery with Cloud Dataflow with least privileges](./data-solutions/gcs-to-bq-with-least-privileges/), [Data Platform Foundations](./data-solutions/data-platform-foundations/), [SQL Server AlwaysOn availability groups example](./data-solutions/sqlserver-alwayson), [Cloud SQL instance with multi-region read replicas](./data-solutions/cloudsql-multiregion/)
 - **factories** - [The why and the how of resource factories](./factories/README.md)
 - **foundations** - [single level hierarchy](./foundations/environments/) (environments), [multiple level hierarchy](./foundations/business-units/) (business units + environments)

examples/cloud-operations/glb_and_armor/README.md

@@ -1,48 +1,131 @@
 # HTTP Load Balancer with Cloud Armor
 
-Google Cloud HTTP(S) load balancing is implemented at the edge of Google's network in Google's points of presence (POP) around the world. User traffic directed to an HTTP(S) load balancer enters the POP closest to the user and is then load balanced over Google's global network to the closest backend that has sufficient capacity available.
+## Introduction
 
-Cloud Armor IP allowlist/denylist enable you to restrict or allow access to your HTTP(S) load balancer at the edge of the Google Cloud, as close as possible to the user and to malicious traffic. This prevents malicious users or traffic from consuming resources or entering your virtual private cloud (VPC) networks.
+Coming up with an amazing app idea is really hard… but what’s even worse is making sure you’re able to deploy it securely on a global scale! Many developers and engineers struggle with making sure their product backends are highly-available and secure at the same time - usually ending up focusing on one of the two. This project aims to change just that.
 
-In this lab, you configure an HTTP Load Balancer with global backends, as shown in the diagram below. Then, you stress test the Load Balancer and denylist the stress test IP with Cloud Armor.
+Using the power of terraform scripts (Infrastructure as a Code deployments), we will be creating a multi-regional infrastructure with horizontally scaling managed instance group backends, HTTP load balancing and Google’s advanced WAF (Web application Firewall) security tool (Cloud Armor) on top.
 
-![Architecture](architecture.png)
+What does this mean? Instead of a long running architecture planning and deployment sprints, we will have a robust backend infrastructure ready in just a few steps. The architecture in question is general enough to fit in a variety of use-cases, but has the potential to be adapted to any specific workload as well. For example - once deployed, this particular architecture can be adapted to run a mobile app’s backend or be used to host proprietary workloads at scale. Not to get into too much detail, let’s elaborate on this in the next section.
 
-## Running the example
+## Use cases
 
-Clone this repository or [open it in cloud shell](https://ssh.cloud.google.com/cloudshell/editor?cloudshell_git_repo=https%3A%2F%2Fgithub.com%2Fterraform-google-modules%2Fcloud-foundation-fabric&cloudshell_print=cloud-shell-readme.txt&cloudshell_working_dir=examples%2Fcloud-operations%2Fglb-and-armor), then go through the following steps to create resources:
+Google Cloud enables workloads of all types to be deployed at any scale using a variety of high-performing resources. But even though there’s many ways to implement any architecture, some workloads are more specific than others and we will be discussing one such very common implementation in this document.
 
-* `terraform init`
-* `terraform apply -var project_id=my-project-id`
+In a world of rapidly scaling products, some workloads require high compute power or specific licenses while making sure the workloads are secured by a managed service and highly available across multiple regions. An architecture consisting of Managed Instance Groups in multiple regions available through an HTTP Load Balancer with Cloud Armor enabled is ideal for such use-cases.
 
-The following outputs will be available once everything is deployed:
+This architecture caters to multiple workloads ranging from the ones requiring compliance with specific data access restrictions to compute-specific proprietary applications with specific licensing and OS requirements. Descriptions of some possible use-cases are as follows:
 
-* `glb_ip_address`, containing the IPv4 address of the HTTP Load Balancer 
-* `vm_siege_external_ip`, containing the external IPv4 address of the siege VM.
+* __Proprietary OS workloads__: Some applications require specific Operating systems (enterprise grade Linux distributions) with specific licensing requirements with low-level access to the kernel. In such cases, since the applications cannot be containerised and horizontal scaling is required, multi-region Managed Instance Group (MIG) with custom instance images are the ideal implementation.
+* __Industry-specific applications__: Your applications may require high compute power alongside a sophisticated layer of networking security. This architecture satisfies both these requirements by promising configurable compute power on the instances backed by various features offered by Cloud Armor such as traffic restriction, DDoS protection etc.
+* __Workloads requiring GDPR compliance__: Most applications require restricting data access and usage from outside a certain region (mostly to comply with data residency requirements). This architecture caters to such workloads perfectly because Cloud Armor allows you to lock access to your workloads from various fine-grained identifiers.
+* __Medical Queuing systems__: Another great example usage for this  architecture will be applications requiring high compute power, availability and limited memory access requirements such as a medical queuing system.
+* __DDoS Protection and WAF__:  Applications and workloads exposed to the internet are constantly under the risk for DDoS attacks. While L3/L4 and protocol based attacks are handled at Google’s edge, L7 attacks can still be immensely effective with botnets. A setup of an external Cloud Load Balancer with Cloud Armor and well crafted WAF rules would be the best way to mitigate such attacks.
+* __Geofencing__: If you want to restrict content served on your application due to licensing restrictions (similar to OTT content in the US), Geofencing allows you to create a virtual perimeter to stop the service from being accessed outside the region. The architecture of using a Cloud Load Balancer with Cloud Armor enables you to implement geofencing around your applications and services.
 
-Once done testing, you can clean up resources by running `terraform destroy`.
+## Architecture
 
-## Testing the example
+<img src="architecture.png" width="500">
 
-1. Connect to the siege VM and run the following command 
+The main components that we would be setting up are (to learn more about these products, click on the hyperlinks):
 
-        siege -c 250 -t150s http://$LB_IP`ß
+* [Cloud Armor](https://cloud.google.com/armor) - Google Cloud Armor is the web-application firewall (WAF) and DDoS mitigation service that helps users defend their web apps and services at Google scale at the edge of Google’s network.
+* [Cloud Load Balancer](https://cloud.google.com/load-balancing) - When your app usage spikes, it is important to scale, optimize and secure the app. Cloud Load Balancing is a fully distributed solution that balances user traffic to multiple backends to avoid congestion, reduce latency and increase security. Some important features it offers that we use here are:
+  * Single global anycast IP and autoscaling - CLB acts as a frontend to all your backend instances across all regions. It provides cross-region load balancing, automatic multi-region failover and scales to support increase in resources.
+  * Global Forwarding Rule - To route traffic to different regions, global load balancers use global forwarding rules, which bind the global IP address and a single target proxy.
+  * Target Proxy - For external HTTP(S) load balancers, proxies route incoming requests to a URL map. This is essentially how you can handle the connections.
+  * URL Map - URL Maps are used to route requests to a backend service based on the rules that you define for the host and path of an incoming URL.
+  * Backend Service - A Backend Service defines CLB distributes traffic. The backend service configuration consists of a set of values - protocols to connect to backends, session settings, health checks and timeouts.
+  * Health Check - Health check is a method provided to determine if the corresponding backends respond to traffic. Health checks connect to backends on a configurable, periodic basis. Each connection attempt is called a probe. Google Cloud records the success or failure of each probe.
+* [Firewall Rules](https://cloud.google.com/vpc/docs/firewalls) - Firewall rules let you allow or deny connections to or from your VM instances based on a configuration you specify.
+* [Managed Instance Groups (MIG)](https://cloud.google.com/compute/docs/instance-groups) - Instance group is a collection of VM instances that you can manage as a single entity. MIGs allow you to operate apps and workloads on multiple identical VMs. You can also leverage the various features like autoscaling, autohealing, regional / multi-zone deployments.
 
-2. In the Cloud Console, on the Navigation menu, click Network Services > Load balancing.
-3. Click Backends.
-4. Click http-backend.
-5. Navigate to http-lb.
-6. Click on the Monitoring tab.
-7. Monitor the Frontend Location (Total inbound traffic) between North America and the two backends for 2 to 3 minutes. At first, traffic should just be directed to us-east1-mig but as the RPS increases, traffic is also directed to europe-west1-mig. This demonstrates that by default traffic is forwarded to the closest backend but if the load is very high, traffic can be distributed across the backends.
-8. Re-run terraform as follows:
+## Costs
+
+Pricing Estimates - We have created a sample estimate based on some usage we see from new startups looking to scale. This estimate would give you an idea of how much this deployment would essentially cost per month at this scale and you extend it to the scale you further prefer.
+
+<https://cloud.google.com/products/calculator/#id=3105bbf2-4ee0-4289-978e-9ab6855d37ed>
+
+## Setup
+
+This solution assumes you already have a project created and set up where you wish to host these resources. If not, and you would like for the project to create a new project as well,  please refer to the [github repository](https://github.com/GoogleCloudPlatform/cloud-foundation-fabric/tree/master/examples/data-solutions/gcs-to-bq-with-least-privileges) for instructions.
+
+### Prerequisites
+
+* Have an [organization](https://cloud.google.com/resource-manager/docs/creating-managing-organization) set up in Google cloud.
+* Have a [billing account](https://cloud.google.com/billing/docs/how-to/manage-billing-account) set up.
+* Have an existing [project](https://cloud.google.com/resource-manager/docs/creating-managing-projects) with [billing enabled](https://cloud.google.com/billing/docs/how-to/modify-project).
+
+### Roles & Permissions
+
+In order to spin up this architecture, you will need to be a user with the “__Project owner__” [IAM](https://cloud.google.com/iam) role on the existing project:
+
+Note: To grant a user a role, take a look at the [Granting and Revoking Access](https://cloud.google.com/iam/docs/granting-changing-revoking-access#grant-single-role) documentation.
+
+### Spinning up the architecture
+
+#### Step 1: Cloning the repository
+
+Click on the button below, sign in if required and when the prompt appears, click on “confirm”.
+
+[<img src="shell_button.png" width="250">](https://goo.gle/GoCloudArmor)
+
+This will clone the repository to your cloud shell and a screen like this one will appear:
+
+![cloud_shell](cloud_shell.png)
+
+Before we deploy the architecture, you will need the following information:
+
+* The __project ID__.
+* A __unique prefix__ that you want all the deployed resources to have (for example: awesomestartup). This must be a string with no spaces or tabs.
+
+#### Step 2: Deploying the resources
+
+1. After cloning the repo, and going through the prerequisites, head back to the cloud shell editor.
+2. Make sure you’re in the following directory. if not, you can change your directory to it via the ‘cd’ command:
+
+       cloudshell_open/cloud-foundation-fabric/examples/cloud-operations/glb_and_armor
+
+3. Run the following command to initialize the terraform working directory:
+
+       terraform init
+
+4. Copy the following command into a console and replace __[my-project-id]__ with your project’s ID. Then run the following command to run the terraform script and create all relevant resources for this architecture:
+
+       terraform apply -var project_id=[my-project-id]
+
+The resource creation will take a few minutes… but when it’s complete, you should see an output stating the command completed successfully with a list of the created resources.
+
+__Congratulations__! You have successfully deployed an HTTP Load Balancer with two Managed Instance Group backends and Cloud Armor security.
+
+## Testing your architecture
+
+1. Connect to the siege VM using SSH (from Cloud Console or CLI) and run the following command:
+
+        siege -c 250 -t150s http://$LB_IP
+
+2. In the Cloud Console, on the Navigation menu, click __Network Services > Load balancing__.
+3. Click __Backends__, then click __http-backend__ and navigate to __http-lb__
+4. Click on the __Monitoring__ tab.
+5. Monitor the Frontend Location (Total inbound traffic) between North America and the two backends for 2 to 3 minutes. At first, traffic should just be directed to __us-east1-mig__ but as the RPS increases, traffic is also directed to __europe-west1-mig__. This demonstrates that by default traffic is forwarded to the closest backend but if the load is very high, traffic can be distributed across the backends.
+6. Now, to test the IP deny-listing, rerun terraform as follows:
 
         terraform apply -var project_id=my-project-id -var enforce_security_policy=true
 
-   Like this we have applied a security policy to denylist the IP address of the siege VM
+This, applies a security policy to denylist the IP address of the siege VM
 
-9. From the siege VM run the following command and verify that you get a 403 Forbidden error code back.
+7. To test this, from the siege VM run the following command and verify that you get a __403 Forbidden__ error code back.
 
         curl http://$LB_IP
+
+## Cleaning up your environment
+
+The easiest way to remove all the deployed resources is to run the following command in Cloud Shell:
+
+        terraform destroy
+
+The above command will delete the associated resources so there will be no billable charges made afterwards.
+
 <!-- BEGIN TFDOC -->
 
 ## Variables