Service-to-Service Calls

​

Overview

The internal firewall rules for a workload can be configured to allow inbound access from other workloads in the same org.

Allowing this type of access decreases the latency of your workloads by making the request in the most direct path possible and increases security by validating the client certificate of the remote workload. Calling the endpoint of a service follows a specific URL syntax that is comprised of the workload name and GVC name.

​

Prerequisites

• Permissions to edit a workload.
• Optional:
  • CLI installed.

​

Internal Firewall

The internal firewall settings are part of the firewall options of a workload and can be set to one of the following types:

• None
  • No access is allowed to this workload from other workloads.
• Same GVC
  • Workloads running in the same GVC are allowed to access this workload.
• Same Org
  • Workloads running in the same org are allowed to access this workload.
• Specific Workloads
  • Only specific workloads listed in inboundAllowWorkload, including workloads from other GVC’s, are allowed access to this workload.
  • With this rule selected, the workload can be set to allow replicas of itself to access itself. Calling a workload using localhost doesn’t require this setting and will force the request to the current workload. By using this setting and sending the request using the service endpoint syntax, the request will be routed to all replicas instead of only the local one.

Only the ports listed in the workload containers array will be made accessible to other workloads.

​

Service Endpoint Syntax

Once inbound access has been allowed on a workload, the following syntax is used when calling the workload from another workload:

http://WORKLOAD_NAME.GVC_NAME.cpln.local[:PORT]

• The PORT is optional, the first port listed in the target workloads container array will be used as the default port for http requests.
• Internal communications work with GRCP, HTTP, HTTP2, and TCP.
• Requests are initiated using plain text communication. A sidecar service will initiate TLS on behalf of the workload.
• Control Plane enforces Mutual-TLS for all internal workload-to-workload communications.
• Headers may optionally be used on the receiving workload to verify that the communication was encrypted.
• Only the ports listed in the workload containers array will be made accessible to other workloads.

​

Setup Internal Firewall using the UI Console

To configure the internal firewall rules using the console:

1. Click Workloads in the left menu and click the workload to be configured.
2. Click Firewall Config and scroll to the Internal section.
3. Click the Inbound Allow Type dropdown and select the inbound access for this workload.
4. Click the Save button at the bottom of the page.

After clicking save, the rule will be enforced within a minute and a new deployment of the workload will be queued.

​

Setup Internal Firewall using the CLI

To modify the internal firewall rule with the CLI, use the workload edit command.

1. Running the following command will open the default text editor and show the metadata (in YAML) for the workload:

cpln workload edit WORKLOAD_NAME --org ORG_NAME --gvc GVC_NAME

2. Scroll down to the section internal under the firewallConfig section
3. Update the inboundAllowType property to one of the following (case sensitive) values:
   • none
   • same-gvc
   • same-org
   • workload-list

If workload-list is selected, update the inboundAllowWorkload property with the names of the allowed workloads using the format:

/org/ORG_NAME/gvc/GVC_NAME/workload/WORKLOAD_NAME

4. Save the file. If the save is successful, the new rules will be applied within a minute and a deployment of the workload will be queued.

​

Quick Start

A quick start demonstrating service-to-service calls is available here.