Service-to-Service Calls

Overview

Multiple workloads can be deployed that have a dependency on one another. By default, workloads are hardened and don't allow any access. Using the firewall configuration, rules can be set to allow the minimum allowed access. This quick start will focus on allowing internal service-to-service calls between workloads.

This quick start will demonstrate how to:

• Set up two workloads with a sample web application.
• Configure a workloads' internal firewall to accept request from other workloads.
• Prove, using the sample web application, that requests are only received by allowed workloads.

Prerequisites

• Review the Service-to-Service Calls guide.
• Permissions to create and edit a workload.
• Existing GVC.

Step One - Setup First Service

A sample image for this quick start is available from Docker Hub that will display the following:

• GVC name
• GVC namespace
• Workload name
• Response from a call to another URL (using the url query string parameter)

1. Follow the Create a Workload guide to setup a workload using the image:

copy
cplnquickstarts/service-to-service-quick-start:1.0

2. After creating the new workload, once the Workload Health shows Healthy, click on the Open link next to the Global Endpoint. A new browser tab will open and display the following:

copy
Hello! Version: 1.0
GVC Name: /org/ORG_NAME/gvc/GVC_NAME
GVC Alias: GVC_ALIAS
Workload Name: /org/ORG_NAME/gvc/GVC_NAME/workload/FIRST_WORKLOAD_NAME
Response from URL:
No URL in querystring

Step Two - Setup Second Service

1. Click on Workloads in the left menu and click the New button.

2. Create another workload just like the workload in step 1 (but using a different name) with the same image. Remember to set the serves traffic switch, set the port to 8080, set the timeout to 30, and set the All Inbound Requests Allowed switch to on in the firewall setting.

3. After creating the new workload, once the Workload Health shows Healthy, click on the Open link next to the Global Endpoint. A new browser tab will open and display the output similar to step 1, but showing the new workload name.

4. The sample application can call another URL endpoint by using the url query string parameter.
   From the new browser tab, test the call to the first service call by browsing to (since the workloads are in the same GVC, the GVC_ALIAS will be the same from the response in step 1):

   copy
   https://GLOBAL_ENDPOINT_SECOND_WORKLOAD/?url=http://FIRST_WORKLOAD_NAME.GVC_NAME.cpln.local

   Since we haven't changed the internal firewall rules, the response from the sample application will display the following:

copy
Hello! Version: 1.0
GVC Name: /org/ORG_NAME/gvc/GVC_NAME
GVC Alias: GVC_ALIAS
Workload Name: /org/ORG_NAME/gvc/GVC_NAME/workload/SECOND_WORKLOAD_NAME
Response from URL:
Request failed with status code 503

Step Three - Configure Internal Firewall

In this step, we will grant inbound access to the first workload from any workload in the same GVC.

1. Click Workloads and select the workload created in step 1. The summary page will be displayed.
2. Click Firewall Config.
3. At the bottom of the page, click the Inbound Allow Type dropdown under the Internal section, and select Same GVC. Click Save. The updated firewall rule will be active within a minute and a new deployment of the workload will be queued. Please wait a few minutes before going to the next step.

Step Four - Test the Updated Firewall Rule

In this step, we will call the first service from the second service.

1. In the browser tab that was opened for step 2, we should still have the failed response displayed.
2. Refresh the page and the following response will be displayed:

copy
Hello! Version: 1.0
GVC Name: /org/ORG_NAME/gvc/GVC_NAME
GVC Alias: GVC_ALIAS
Workload Name: /org/ORG_NAME/gvc/GVC_NAME/workload/SECOND_WORKLOAD_NAME
Response from URL:
Hello! Version: 1.0
GVC Name: /org/ORG_NAME/gvc/GVC_NAME
GVC Alias: GVC_ALIAS
Workload Name: /org/ORG_NAME/gvc/GVC_NAME/workload/FIRST_WORKLOAD_NAME
Response from URL:
No URL in querystring

3. If you received the same response, this demonstrated that the second workload was able to call the first workload internally.

Step Five - Configure Other Internal Firewall Rules

In step 3, the internal firewall rule for the first workload was set to allow access from any workload in the same GVC. We could also set the rule to allow access from any workloads within the org, crossing GVC boundaries.

Another available setting is to specify exactly which workloads can access the workload. The workloads shown are selectable and only from the same GVC. You cannot allow workloads from other GVCs using this setting. There is also a switch that can be set to allow a workload to access itself using the Service Endpoint Syntax.

Feel free to test out the other settings using the sample application to verify that the internal firewall rules are enforced. Remember that any changes to the firewall will be updated within a minute and a deployment of the workload will be queued. Please allow a few minutes between tests.

Summary

Using a sample application that can call endpoints from within a workload, we were able to demonstrate that a workload is locked down by default and will not accept any requests internally. By setting the internal firewall rule, workloads can allow different types of internal traffic from other workloads. Depending on the use case, multiple workloads can be deployed within your org and call each other internally without having to access the public Internet.