Understanding Link endpoints and Satellite

Open up Satellite endpoints in the Satellite control plane to control and audit network traffic between your IBM Cloud Satellite® location and services, servers, or apps that run outside of the location.

With Satellite Link endpoints, you can allow any client that runs in your Satellite location to connect to a service, server, or app that runs outside of the location, or allow a client that is connected to the IBM Cloud private network to connect to a service, server, or app that runs in your location.

To establish the connection, you must specify the destination resource's fully qualified domain name (FQDN) or IP address, port, the connection protocol, and any authentication methods in the endpoint. The endpoint is registered with the Satellite Link component of your location's Satellite control plane. To help you maintain enterprise security and audit compliance, Satellite Link additionally provides built-in controls to restrict client access to endpoints and to log and audit traffic that flows over endpoints.

Architecture

You can create two types of endpoints, depending on your use case: a cloud endpoint, or a location endpoint.

Cloud endpoint: Destination resource runs outside of the Satellite location. A cloud endpoint allows you to securely connect to a service, server, or app that runs outside of the location from a client within your Satellite location.
Location endpoint: Destination resource runs in the Satellite location. A location endpoint allows you to securely connect to a server, service, or app that runs in your Satellite location from a client that is connected to the IBM Cloud private network.

The tunnel server and the connector proxy network traffic over a secure TLS connection between cloud services and resources in your Satellite location. This Link tunnel serves as a communication path over the internet that uses the TCP protocol and port 443, and encrypts payloads via TLS. Three tunnels are created between the tunnel server in IBM Cloud and the connector in the location's control plane nodes. This redundancy supports the three availability zones of your location, and helps ensure communication in the case of a single zone failure. However, the three tunnels are orchestrated together so that the client that uses a Link endpoint sees a single connection. For more information about the Satellite Link components, see the Satellite architecture.

Cloud endpoint

By default, source clients in your Satellite location cannot reach destination resources that run outside of the location because the destination resource's IP address is not routable from within the location. Review the following architecture diagram and steps, which demonstrate how Satellite Link enables communication from Satellite locations to services that run outside of locations through Satellite endpoints.

Network traffic through Satellite Link. — Network traffic flow from a source in your IBM Cloud Satellite location to a destination resource in IBM Cloud through Satellite Link

When you create an endpoint for your destination resource, a port is opened for the Satellite Link connector on your Satellite control plane nodes. Requests from sources in your Satellite location are made to the Satellite Link connector host name and the port, such as nae4dce0eb35957baff66-edfc0a8ba65085c5081eced6816c5b9c-c000.us-east.satellite.appdomain.cloud:30819. This Link host name and port are mapped to the destination resource's domain and port.
The Satellite Link connector forwards the request to the Satellite Link tunnel server on the Satellite management plane over a secured TLS connection.
The Satellite Link tunnel server resolves the request to the destination's IP address and port, and forwards the request to the destination resource.

Location endpoint

By default, source clients that are connected to the IBM Cloud private network cannot reach destination resources that run in your Satellite location because the destination resource's IP address is not routable from outside the location. Review the following architecture diagram and steps, which demonstrate how Satellite Link enables communication from services that are connected to the IBM Cloud private network to locations through Satellite endpoints.

When you create an endpoint for a resource that runs in your Satellite location, a port is opened on the Satellite Link tunnel server and added in the endpoint configuration. Requests from sources that are connected to the IBM Cloud private network are made to the Satellite Link tunnel server host name and this port, such as c-01.us-east.link.satellite.cloud.ibm.com:30819. This Link host name and port are mapped to the destination resource's domain and port.
The Satellite Link tunnel server resolves the request to the Satellite Link connector host name and endpoint port, and forwards the request to the Satellite Link connector over a secured TLS connection.
The Satellite Link connector resolves the request to the destination's IP address and port, and forwards the request to the destination resource.

What happens if Satellite Link becomes unavailable?: Your on-location workloads continue to run independently even if the location's connectivity to IBM Cloud is unavailable. However, if any applications use a Link endpoint to communicate with IBM Cloud, communication between those apps and IBM Cloud is disrupted. Additionally, any requested changes to your Satellite location, such as adding hosts or access control requests to IBM services through Cloud Identity and Access Management, are disrupted. After connectivity is restored, logs and events are sent to your IBM Log Analysis and IBM Cloud Activity Tracker instances. Note that Satellite Link depends on the underlying connectivity of your hosts' local network to monitor and maintain the managed services for your Satellite location.

External network requirements and security

Your Satellite location infrastructure is a part of your local network (on-prem hosts) or the network of another cloud provider, but is managed remotely via secure access from IBM Cloud. Review the following frequently asked questions about Satellite Link network security. For more information about all security options for IBM Cloud Satellite, see Security and compliance for Satellite.

Do I need to allow any unique inbound traffic from internet-facing ports through firewalls to my location?

No. Satellite Link uses standard web security ports to originate encrypted communication from your location to IBM Cloud for location management. Satellite creates unique public DNS entries for each location and assigns ports from the 32768 - 52768 range for TCP so that destination addresses can be predictably resolved by IBM Cloud. Communication channels over Link endpoints between your Satellite location to IBM Cloud are permitted through your existing outbound firewall policies for hosts.

If IBM owns the Link tunnel, how can I validate that our data is inaccessible? My organization's security policy does not allow tunnels from our networks.

Satellite Link uses a zero-trust model; IBM Cloud has no access to your workloads by default. Any management of infrastructure in your location that is initiated by IBM Site Reliability Engineers over Satellite Link is isolated from your workloads and the network connections, such as the Link endpoints, that your workloads use. For more information about what kinds of access IBM Cloud has to your Satellite location, see IBM operational access. For any other connections into your location that your applications require, you can use Satellite Link to create layer 4 communications by setting up an endpoint for each destination resource in your location. All connections through your endpoints are always under your control, including completely disabling endpoints.

How do I make my data secure in transit?

Link endpoints between your location and IBM Cloud are secured through two levels of encryption: high-security encryption from the location’s connector to IBM Cloud that is provided by IBM , and an optional additional encryption layer between the source and destination resources.

All data that is transported over Satellite Link is encrypted using TLS 1.3 standards. This level of encryption is managed by IBM.

When you create an endpoint, you can optionally provide another level of encryption by specifying data encryption protocols for the endpoint connection between the client source and destination resource. For example, even if the traffic is not encrypted on the source side, you can specify TLS encryption for the connection that goes over the internet. You can provide your own signed certificates to ensure both internal security and operational auditability without exposing any data contents. IBM only transports the encrypted connection, and your resources must be configured for the data encryption protocols that you specify.

Encryption protocols

All communication over Satellite Link is encrypted by IBM. When you create an endpoint, you can optionally specify an additional data encryption protocol for the endpoint connection between the client source and destination resource. For example, even if the traffic is not encrypted on the source side, you can specify your own additional TLS encryption for the connection that goes over the internet. Note that your resources must be configured for the data encryption protocols that you specify.

Review the following information about how Satellite Link handles each type of connection protocol.

If you use the Satellite console to create an endpoint, the destination protocol is inherited from the source protocol that you select. To specify a destination protocol, use the CLI to create an endpoint and include the --dest-protocol option in the ibmcloud sat endpoint create command.

TCP and TLS

If your destination resource does not require requests with a specific HTTP or HTTPS host name header, or can accept direct requests to its IP address instead of its host name, use the TCP or TLS protocols. Satellite Link uses the same protocol as the request to transfer the request packet to the destination.

HTTP and HTTPS

If your destination resource is configured to listen for a specific HTTP or HTTPS host name header, use the HTTP or HTTPS protocols. By using HTTP and HTTPS header remapping, Satellite Link is able to correctly route requests for multiple destination resources through TCP ports 80 (HTTP) and 443 (HTTPS).

Cloud endpoint: Source requests from your Satellite location to your destination resource that runs outside of the location contain an HTTP header such as linkconnector_hostname:port. When the request is sent from the Satellite Link connector to the Satellite Link tunnel server, the Satellite Link tunnel server changes the HTTP header on the request to the destination host name and port, such as dest_hostname:dest_port. The Satellite Link tunnel server then uses the destination's host name and port to forward the request to the correct destination resource.
Location endpoint: Source requests from clients that run outside the location to your destination resource in your Satellite location contain an HTTP header such as linkserver_hostname:endpoint_port. The Satellite Link tunnel server changes the HTTP header on the request to the destination host name and port, such as dest_hostname:dest_port, and sends the request to the Satellite Link connector. The Satellite Link connector then uses the destination's host name and port to send the request to the correct destination resource.

HTTP tunnel

When you want TLS connections to pass uninterruptedly from the source to your destination resource, such as to pass a certificate to the destination for mutual authentication, use the HTTP tunnel protocol.

The client source makes an HTTP connection request to the Satellite Link tunnel server or connector component, depending on whether the destination runs outside of the location or within your Satellite location. The Link component then makes the connection to the destination resource. After the initial connection is established, the Link component proxies the TCP connection between the source and destination uninterruptedly.

The Satellite Link component is not involved in TLS termination for encrypted traffic, so the destination resource must terminate the TLS connection. For example, if your destination resource requires mutual authentication, the HTTP tunnel protocol allows your client source to pass the required authentication certificate directly to the destination.

Server-side certificate authentication for TLS and HTTPS

If you select the TLS or HTTPS protocols, you can optionally require server-side verification of the destination's certificate. The certificate must be valid for the destination's host name and signed by a trusted Certificate Authority.

If your destination resource has a certificate, you do not need to provide the certificate when you create the endpoint. However, if you are testing access to a destination resource that is still in development and you do not have a trusted certificate yet, you can upload a self-signed certificate for verification. This ssl.crt file must contain the public, base-64 encoded certificate for your resource's host name and must not contain the private ssl.key certificate key. To create a self-signed certificate for testing purposes by using OpenSSL, see this self-signed SSL certificate tutorial.

Access and audit controls

Satellite Link provides built-in controls to help you restrict which clients can access endpoints, and audit user-initiated events for Link endpoints.

Restricting access with source lists

By default, after you set up an endpoint, any client can connect to the destination resource through the endpoint. For example, for a location endpoint, any client that is connected to the IBM Cloud private network can use the endpoint to connect to the destination resource that runs in your Satellite location. To limit access to the destination resource, you can specify a list of source IP ranges so that only trusted clients can access the endpoint. Note that currently you can create source lists only for endpoints of type location and cannot create source lists for endpoints of type cloud.

Auditing user-initiated events

After you set up source lists for endpoints, you can configure auditing to monitor user-initiated events for Link endpoints. IBM Cloud Satellite integrates with IBM Cloud® Activity Tracker to collect and send audit events for all link endpoints in your location to your Activity Tracker instance. To get started with auditing, see Auditing events for endpoint actions.

Use cases

Review the following list of general use cases and example use cases for Satellite Link endpoints.

Can I use Link endpoints to

Connect resources within the same Satellite location?: No. Link endpoints cannot be created between resources in the same location. Instead, resources can access each other directly. For example, an app that runs in a Red Hat OpenShift cluster in Satellite does not need to communicate through Satellite Link to access a database that exists in the same location, and can instead access that database directly through the location's private network.
Expose apps or services that run in a Red Hat OpenShift cluster in Satellite?: To see available options, see Exposing apps in Satellite clusters.
Bridge networks within the IBM Cloud public network, such as VPC spanning?: No. Instead, use the bridging solution that is recommended for your network setup. For example, you might use a Virtual Private Network (VPN) for VPC or IBM Cloud® Direct Link.
Connect to other public clouds?: Yes. With Satellite Link, you can create cloud endpoints for resources that run in other public clouds.

Example: Connect from a Satellite location to a service in another cloud provider

You want to send data from a server that runs on a host in your Satellite location to a service that runs in Amazon Web Services. The service must be publicly accessible so that the Satellite Link tunnel, which terminates within the IBM Cloud network, can access the service in the AWS network.

To establish this connection, you first create a cloud endpoint. You specify the service that runs in AWS as the destination resource. Then, the server on your on-location host connects directly to the host name of the Satellite Link connector on your location's control plane nodes. Satellite Link forwards this request to the cloud endpoint that you created for the service that runs in AWS.

Example: Enable and audit limited access to a Satellite location from IBM Cloud

You run a database in your Satellite location instead of in IBM Cloud, because the database has legal requirements to run in your on-premises data center in a specific country. However, you still need to connect to the database in your Satellite location from the IBM Cloud private network.

To establish this connection, you first create a location endpoint. You specify the database that runs in your Satellite location as the destination resource. Then, the client in the IBM Cloud private network connects directly to the host name of the Satellite Link tunnel server. Satellite Link forwards this request to the location endpoint that you created for your on-location database.

Finally, to maintain enterprise security and audit compliance, you specify a list of source IP ranges so that only trusted clients in the public cloud can access your on-location database through the endpoint. Then, you set up an IBM Cloud Activity Tracker instance so that audit logs can be automatically collected for all endpoints in your Satellite location.