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:
Review the Service-to-Service Calls guide.
Latest CLI installed.
A sample application for this quick start is available as an image from Docker Hub that will display the following:
url
query string parameter).cplnquickstarts/service-to-service-quick-start:1.1
.The source code for the sample application can be viewed here.
copycpln login
copycpln profile update default --org ORG_NAME
copycpln 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.
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.
copycurl 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.
Browse to the server
Workload using the Console:
quick-start-service-to-service
.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:
copyHello! Version: 1.1GVC Name: quick-start-service-to-serviceLocation: /org/ORG_NAME/location/aws-us-west-2Workload Name: /org/ORG_NAME/gvc/quick-start-service-to-service/workload/serverResponse from URL:No URL in querystring
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:
copyhttps://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
):
copyHello! Version: 1.1GVC Name: quick-start-service-to-serviceLocation: /org/ORG_NAME/location/aws-us-west-2Workload Name: /org/ORG_NAME/gvc/quick-start-service-to-service/workload/clientResponse from URL:Request failed with status code 502
Leave this browser tab open. It will be used in step three.
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:
copycurl 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
.
copyHello! Version: 1.1GVC Name: quick-start-service-to-serviceLocation: /org/ORG_NAME/location/aws-us-west-2Workload Name: /org/ORG_NAME/gvc/quick-start-service-to-service/workload/clientResponse from URL:---Hello! Version: 1.1GVC Name: quick-start-service-to-serviceLocation: /org/ORG_NAME/location/aws-us-west-2Workload Name: /org/ORG_NAME/gvc/quick-start-service-to-service/workload/serverResponse from URL:No URL in querystring
If you received the same response, this demonstrated that the client
Workload was able to call the server
Workload internally.
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:
view
permission, set within a policy, on the Workload being specified.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.
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.