Skip to main content

​
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

​
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
  • Same GVC
  • Same Org
  • 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.
Internal workload to workload traffic that spans GVC’s may also span locations and will incur egress charges.

​
Service Endpoint Syntax

Once inbound access has been allowed on a workload, the following syntax is used when calling the workload from another workload:
Syntax
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 gRPC, 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
  1. Scroll down to the section internal under the firewallConfig section
  2. 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:
Format
/org/ORG_NAME/gvc/GVC_NAME/workload/WORKLOAD_NAME
If you want to allow the workload the ability to call itself, the WORKLOAD_NAME will be the same as the name of the workload.
  1. 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.