Add third use case description in README

blueprints/serverless/cloud-run-corporate/README.md

@@ -12,7 +12,7 @@ If you are interested in following this guide, take a look to the chapters' blue
 
 ## Architecture
 
-This blueprint creates multiple architectures depending on the use case. Some may have one or two projecs while others may have four or more. Some use [Private Service Connect (PSC)](https://cloud.google.com/vpc/docs/private-service-connect) to access Google APIs, and others a [Layer 7 Internal Load Balancer](https://cloud.google.com/load-balancing/docs/l7-internal). Even security plays a role and [VPC Service Controls](https://cloud.google.com/vpc-service-controls) is introduced.
+This blueprint creates multiple architectures depending on the use case. Some may have one or two projecs while others may have four or more. Some use [Private Service Connect (PSC)](https://cloud.google.com/vpc/docs/private-service-connect) to access Google APIs, and others a [Layer 7 Internal Load Balancer](https://cloud.google.com/load-balancing/docs/l7-internal). Even security plays a role and [VPC Service Controls (VPC SC)](https://cloud.google.com/vpc-service-controls) is introduced.
 
 ## Prerequisites
 
@@ -100,13 +100,59 @@ prj_onprem_id = "[your-onprem-project-id]"
 
 SSH into the test VM and run `curl`, you should see the same output as in the previous use case.
 
-### Use case 3: Access to Cloud Run from another project, with VPC SC
+### Use case 3: Access to Cloud Run from another project
 
-[Done, update README]
+Corporate apps are used by multiple teams and projects. This blueprint explores accessing from a different project to where Cloud Run is deployed. For simplicity only one more project is used but the concepts would apply to any number of projects. Three different cases are implemented:
+
+#### 3.1
+
+The first case allows access to Cloud Run from any project as well as the Internet.
+
+<p style="left"> <img src="images/use-case-3.1.png" width="500"> </p>
+
+This is achieved with `ingress_settings` value set to `"all"`. This is the deafult if not specified but this blueprint sets it to `"internal"` by default. Add a new project and this setting in `terraform.tfvars`:
+
+```tfvars
+prj_main_id      = "[your-main-project-id]"
+prj_prj1_id      = "[your-project1-id]"
+ingress_settings = "all"
+```
+
+Note the different PSC endpoints created in each project and the different IPs. Each project can choose its own RFC1918 IP to reach the same Cloud Run service.
+
+#### 3.2
+
+It is possible to block access from the Internet restoring `ingress_settigns` to `"internal"` but this will also block access from any other project.
+
+<p style="left"> <img src="images/use-case-3.2.png" width="500"> </p>
+
+Simply omit `ingress_settigns` in `terraform.tfvars`:
+
+```tfvars
+prj_main_id = "[your-main-project-id]"
+prj_prj1_id = "[your-project1-id]"
+```
+
+#### 3.3
+
+To allow access from other projects while keeping access from the Internet restricted, you need to add those projects to a VPC SC perimeter together with Cloud Run.
+
+<p style="left"> <img src="images/use-case-3.3.png" width="500"> </p>
+
+VPC SC requires an [Access Policy](https://cloud.google.com/access-context-manager/docs/overview#access-policies). You can use an existing policy or create a new one, but an organization can only have one organization-level access policy. The policy name is a unique numeric identifier assigned by Google Cloud.
+
+Make sure to check out the [IAM roles](https://cloud.google.com/access-context-manager/docs/access-control) required to configure access policies and VPC SC. Also, include the identity that runs Terraform to avoid losing access from it once the perimeter is created. Set the following in `terraform.tfvars`:
+
+```tfvars
+prj_main_id   = "[your-main-project-id]"
+prj_prj1_id   = "[your-project1-id]"
+access_policy = "[policy-name]"
+tf_identity   = "[user or SA account]"
+```
 
 ### Use case 4:
 
-### Use case 5:
+[TODO]
 
 ## Cleaning up your environment