Service-to-Service Calls

Overview

Multiple Workloads can be deployed to Control Plane that have a dependency on one another. By default, Workloads are hardened and don't allow any access from other Workloads. Using the internal firewall settings, secure access (using mTLS) from other Workloads can be enabled. 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 application.
• Configure a Workloads' internal firewall to accept requests from other Workloads.
• Prove, using the sample application, that requests are only received by allowed Workloads.

Prerequisites

• Review the Service-to-Service Calls guide.

• Permissions to:
  • Create and edit a GVC.
  • Create and edit a Workloads.

• Latest CLI installed.

Sample Application

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

• GVC name.
• Cloud provider location.
• Workload name.
• Response from a call to another URL (using the url query string parameter).
• The image is located at: cplnquickstarts/service-to-service-quick-start:1.1.

The source code for the sample application can be viewed here.

Step One - Create GVC and Two Workloads

1. Authenticate to Control Plane by executing the following CLI command:

copy
cpln login

2. Execute the following CLI command to update your profile with a default Org which will be used by the subsequent commands (substitute ORG_NAME for your org):

copy
cpln profile update default --org ORG_NAME

3. Execute the following CLI command to create a GVC that will contain the two Workloads:

copy
cpln gvc create --name quick-start-service-to-service --location aws-us-west-2

The GVC created is named quick-start-service-to-service and will be hosted at AWS within the us-west-2 region.

4. Execute the following CLI command to create the two Workloads that will be hosting the sample application.

Note: The cpln apply command is used to create the Workloads that are defined in the YAML manifest file. The file can be viewed by clicking here.

copy
curl https://raw.githubusercontent.com/controlplane-com/examples/main/quickstarts/5/01_create_workloads.yaml | cpln apply -f - --gvc quick-start-service-to-service

The first Workload is named server and the second is named client. They are both configured with the sample application image and the firewall rules has been set to allow outside traffic.

5. Browse to the server Workload using the Console:

   • Select the GVC named quick-start-service-to-service.
   • Click Workloads in the left menu and select server.

Once the Workload Health shows Ready, click on the Open link next to the Global Endpoint URL. A new browser tab will open and display the following:

copy
Hello! Version: 1.1
GVC Name: quick-start-service-to-service
Location: /org/ORG_NAME/location/aws-us-west-2
Workload Name: /org/ORG_NAME/gvc/quick-start-service-to-service/workload/server
Response from URL:
No URL in querystring

Step Two - Demonstrate a Failed Request

1. Browse to the client Workload using the Console:
   • Click Workloads in the left menu and select client.

Once the Workload Health shows Ready, click on the Open link next to the Global Endpoint URL. A new browser tab will open and display the output similar to step 1, but showing the second Workload name client.

The sample application can call another URL endpoint by using the url query string parameter. Since the client will be calling the server, the URL will follow the Service Endpoint Syntax.

From the new browser tab, test the call to the first service call by browsing to:

copy
https://GLOBAL_ENDPOINT_CLIENT_WORKLOAD/?url=http://server.quick-start-service-to-service.cpln.local

Since we haven't changed the internal firewall rules, the response from the sample application will display the following (indicating that the client cannot connect to the server):

copy
Hello! Version: 1.1
GVC Name: quick-start-service-to-service
Location: /org/ORG_NAME/location/aws-us-west-2
Workload Name: /org/ORG_NAME/gvc/quick-start-service-to-service/workload/client
Response from URL:
Request failed with status code 502

Leave this browser tab open. It will be used in step three.

Step Three - Configure Internal Firewall

Execute the following CLI command to update the firewall rules of the server Workload to grant inbound access from any Workload in the same GVC:

copy
curl https://raw.githubusercontent.com/controlplane-com/examples/main/quickstarts/5/02_update_first_workload_firewall.yaml | cpln apply -f - --gvc quick-start-service-to-service

The YAML file can be viewed by clicking here.

Notice that the internal firewall configuration has been set to the allow type of same-gvc.

Step Four - Test the Updated Firewall Rule

1. In the browser tab that was opened for step two, we should still have the failed response displayed.
2. Refresh the page and the following response will be displayed (it might take a minute or two for the new deployment to complete):

copy
Hello! Version: 1.1
GVC Name: quick-start-service-to-service
Location: /org/ORG_NAME/location/aws-us-west-2
Workload Name: /org/ORG_NAME/gvc/quick-start-service-to-service/workload/client
Response from URL:
---
Hello! Version: 1.1
GVC Name: quick-start-service-to-service
Location: /org/ORG_NAME/location/aws-us-west-2
Workload Name: /org/ORG_NAME/gvc/quick-start-service-to-service/workload/server
Response from URL:
No URL in querystring

Configure Other Internal Firewall Rules

In step three, the internal firewall rule for the server Workload was set to allow access from any Workload in the same GVC.

The rule can also be set to:

• Allow access from only specific Workloads. These Workloads can be from the same or different GVCs. The user configuring this setting must have the view permission, set within a policy, on the Workload being specified.
• Allow access from any Workloads within the same Org, crossing GVC boundaries.

Please experiment with the other settings using the sample application to verify that the internal firewall rules are enforced. Remember that any changes to the firewall rules 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.