Skip to content
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -1,8 +1,8 @@
## Configuring a Secure Proxy

For security reasons, Runtime does not expose egress IPs. Customers who need a way to secure communication with downstream services using IP whitelisting can use a proxy between their backend service and I/O Runtime.
If you only need to allowlist Adobe I/O Runtime's outbound (egress) IP ranges on your downstream service, you can retrieve them directly with `aio runtime ip-list get` — see [Secure communication with back-end services](../security-general.md#secure-communication-with-back-end-services). No proxy is required for that case.

This can be done by adding a proxy component (in this example, an AWS EC2 instance running nginx). The proxy component will have a fixed IP address, so using an IP allowlist can secure the backend service. Communication between I/O Runtime and the proxy component will be secured via mutual TLS (mTLS) communication.
A proxy is still useful when you need a single, stable IP address rather than a set of ranges, or when you want to secure the connection with mutual TLS (mTLS). This can be done by adding a proxy component (in this example, an AWS EC2 instance running nginx). The proxy component will have a fixed IP address, so using an IP allowlist can secure the backend service. Communication between I/O Runtime and the proxy component will be secured via mutual TLS (mTLS) communication.

![](../../../images/configure-proxy.png)

Expand Down
10 changes: 9 additions & 1 deletion src/pages/guides/runtime_guides/security-general.md
Original file line number Diff line number Diff line change
Expand Up @@ -73,7 +73,15 @@ You can secure web actions using any CDN by following these steps:

## Secure communication with back-end services

For security reasons, Runtime does not expose egress IPs . Customers who need a way to communicate securely with their back-end services can use a proxy between their system and Runtime, as described in [Configuring a Secure Proxy](reference_docs/configuringproxy.md).
If your back-end service restricts inbound traffic by IP, you can retrieve the current Adobe I/O Runtime outbound (egress) IP ranges and add them to your allowlist by running:

```
aio runtime ip-list get
```

This command (added in [`@adobe/aio-cli-plugin-runtime` 8.3.0](../../intro_and_overview/release-notes.md)) lets you update corporate or network allowlists without opening a support ticket. The first time you run it for a given Adobe org, you are prompted to accept the egress IP allowlist terms and provide a contact email for IP-change notifications; subsequent calls in the same org are non-interactive. Because these ranges can change over time, re-run the command periodically and watch for change notifications rather than hard-coding individual addresses.

If you instead need a single, stable IP address — or want to secure the connection with mutual TLS (mTLS) — you can route traffic through a proxy you control, as described in [Configuring a Secure Proxy](reference_docs/configuringproxy.md).

Runtime ingress IPs are not static. To facilitate operational changes, IPs returned when looking up I/O Runtime endpoints may change. To ensure uninterrupted service availability, it is critical that clients honor the Time to Live (TTL) returned by I/O Runtime DNS records. When the IPs associated with these endpoints change due to operational adjustments, clients who rely on the outdated addresses may experience service disruptions, increased latency, or network connectivity issues. How clients honoring TTL is implementation-specific, but in general, clients should not cache DNS records for longer than the specified TTL.

Expand Down