> ## Documentation Index
> Fetch the complete documentation index at: https://controlplanecorporation-kyle-cron-and-quotas.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Service-to-Service Calls

> Configure internal firewall rules for workload-to-workload communication. Covers service endpoint syntax, same-GVC and cross-GVC calls, and latency benefits.

## Overview

The [internal firewall](/reference/workload/firewall#internal) rules for a [workload](/reference/workload) can be configured to allow inbound access from other [workloads](/reference/workload) in the same [org](/reference/org).

Allowing this type of access decreases the latency of your [workloads](/reference/workload) 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](#service-endpoint-syntax) that uses the [workload](/reference/workload) name and [GVC](/reference/gvc) name.

## Prerequisites

* Have [permissions](/reference/policy#permissions) to edit a [workload](/reference/workload).
* Optional: Install the [CLI](/cli-reference/installation).

## Internal Firewall

The [internal firewall](/reference/workload/firewall#internal) settings are part of the firewall options of a [workload](/reference/workload) and can be set to one of the following types:

* `None`
  * No access is allowed to this [workload](/reference/workload) from other [workloads](/reference/workload).
* `Same GVC`
  * [Workloads](/reference/workload) running in the same [GVC](/reference/gvc) are allowed to access this [workload](/reference/workload).
* `Same Org`
  * [Workloads](/reference/workload) running in the same org are allowed to access this [workload](/reference/workload).
* `Workload List`
  * Only specific [workloads](/reference/workload) listed in `inboundAllowWorkload`, including workloads from other GVCs, are allowed access to this workload.
  * With this rule selected, the [workload](/reference/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](#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](/reference/workload/autoscaling#keda) 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.

<Note>Internal workload to workload traffic that spans GVCs may also span locations and will incur egress charges.</Note>

## Service Endpoint Syntax

Once inbound access has been allowed on a [workload](/reference/workload), the following syntax is used when calling the [workload](/reference/workload) from another [workload](/reference/workload):

```text Syntax theme={null}
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.

<Note>The syntax above load-balances across all replicas. To reach an individual replica directly, or to find the hostnames assigned to a given replica, see [Finding Replica Hostnames](/reference/workload/general#finding-replica-hostnames) in the Workload reference.</Note>

## 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](/reference/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](/reference/workload).
4. Click `Update`.

After updating, a new deployment of the [workload](/reference/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](/cli-reference/commands/workload#workload-edit) command.

1. Run the following command to open the workload metadata in your default text editor:

```bash theme={null}
cpln workload edit WORKLOAD_NAME --org ORG_NAME --gvc GVC_NAME
```

2. Scroll down to the `internal` section under `firewallConfig`.
3. 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.

```text Format theme={null}
//gvc/GVC_NAME/workload/WORKLOAD_NAME
```

<Note>
  To allow a workload to call itself, use that workload's own name for `WORKLOAD_NAME`.
</Note>

4. Save the file. If the save is successful, the new rules will be applied within a minute and a deployment of the [workload](/reference/workload) will be queued.

## Quick Start

A quick start demonstrating service-to-service calls is available in the [Service-to-Service quickstart](/quickstart/quick-start-4-service-to-service).