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:
A sample image for this quick start is available from Docker Hub that will display the following:
urlquery string parameter)
When creating the workload:
Serves Trafficswitch on and set the port to
Optionsstep, set the
Timeout Secondsto 30.
Firewallstep, turn the
All Inbound Requests Allowedswitch on so you can call the application from the Internet.
Healthy, click on the
Openlink next to the
Global Endpoint. A new browser tab will open and display the following:
copyHello! Version: 1.0GVC Name: /org/ORG_NAME/gvc/GVC_NAMEGVC Alias: GVC_ALIASWorkload Name: /org/ORG_NAME/gvc/GVC_NAME/workload/FIRST_WORKLOAD_NAMEResponse from URL:No URL in querystring
The source code for the sample application can be downloaded from here.
Workloads in the left menu and click the
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.
After creating the new workload, once the
Workload Health shows
Healthy, click on the
Open link next to the
A new browser tab will open and display the output similar to step 1, but showing the new workload name.
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):
Since we haven't changed the internal firewall rules, the response from the sample application will display the following:
copyHello! Version: 1.0GVC Name: /org/ORG_NAME/gvc/GVC_NAMEGVC Alias: GVC_ALIASWorkload Name: /org/ORG_NAME/gvc/GVC_NAME/workload/SECOND_WORKLOAD_NAMEResponse from URL:Request failed with status code 503
In this step, we will grant inbound access to the first workload from any workload in the same GVC.
Workloadsand select the workload created in step 1. The summary page will be displayed.
Inbound Allow Typedropdown under the
Internalsection, 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.
In this step, we will call the first service from the second service.
copyHello! Version: 1.0GVC Name: /org/ORG_NAME/gvc/GVC_NAMEGVC Alias: GVC_ALIASWorkload Name: /org/ORG_NAME/gvc/GVC_NAME/workload/SECOND_WORKLOAD_NAMEResponse from URL:Hello! Version: 1.0GVC Name: /org/ORG_NAME/gvc/GVC_NAMEGVC Alias: GVC_ALIASWorkload Name: /org/ORG_NAME/gvc/GVC_NAME/workload/FIRST_WORKLOAD_NAMEResponse from URL:No URL in querystring
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.
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.