Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.controlplane.com/llms.txt

Use this file to discover all available pages before exploring further.

​
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 uses 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
  • Workload List
    • Only specific workloads listed in inboundAllowWorkload, including workloads from other GVCs, are allowed access to this workload.
    • With this rule selected, the workload can be set to allow replicas of itself to access itself by enabling the Allow Access To Itself button. 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.
    • If using KEDA, enable the Allow KEDA Access button. See KEDA autoscaling for details.
  • Same GVC and Workload List
    • A combination of the Same GVC and Workload List.
Only the ports listed in the workload containers array will be made accessible to other workloads.
Internal workload to workload traffic that spans GVCs 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]
  • If PORT is omitted, the first port listed in the target workload’s container array is used as the default port for http requests.
  • Internal communication works with gRPC, HTTP, HTTP2, and TCP.
  • Requests are initiated using plaintext communication. A sidecar service initiates TLS on behalf of the workload.
  • Control Plane enforces mutual TLS (mTLS) for all internal workload-to-workload communication.
  • 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.

​
Configure internal firewall using the Console

To configure the internal firewall rules using the Console:
  1. Click Workloads in the left menu, then select the workload to configure.
  2. Click Firewall, then click the Internal tab.
  3. Click the Inbound Allow Type dropdown and select the inbound access for this workload.
  4. Click Update.
After updating, a new deployment of the workload will be queued, and once deployed, the rule will be enforced.

​
Configure internal firewall using the CLI

To modify the internal firewall rule with the CLI, use the workload edit command.
  1. Run the following command to open the workload metadata in your default text editor:
cpln workload edit WORKLOAD_NAME --org ORG_NAME --gvc GVC_NAME
  1. Scroll down to the internal section under firewallConfig.
  2. Update the inboundAllowType property to one of the following (case sensitive) values:
    • none
    • same-gvc
    • same-org
    • workload-list
To allow specific workloads, add their links to inboundAllowWorkload. Use this with workload-list, or with same-gvc when you want to allow all workloads in the same GVC plus specific workloads from other GVCs.
Format
//gvc/GVC_NAME/workload/WORKLOAD_NAME
To allow a workload to call itself, use that workload’s own name for WORKLOAD_NAME.
  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 in the Service-to-Service quickstart.