Preface

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. Because of the enormity of this endeavor, these changes will be implemented gradually over several upcoming releases. For more details, see our CTO Chris Wright’s message.

Note

This Limited Availability release is not available to all customers. Contact Red Hat Sales if you are interested in learning more about Application Interconnect.

By default, Application Interconnect includes many security features, including using mutual TLS for all service network communication between sites. By default, applying the policy system to a cluster prevents all service network communication to and from that cluster. You specify granular policies to allow only the service network communication you require.

Note

The policy system is distinct from the network-policy option which restricts access to Application Interconnect services to the current namespace as described in Configuring Application Interconnect sites using the CLI.

Each site in a service network runs a Application Interconnect router and has a private, dedicated certificate authority (CA). Communication between sites is secured with mutual TLS, so the service network is isolated from external access, preventing security risks such as lateral attacks, malware infestations, and data exfiltration. The policy system adds another layer at a cluster level to help a cluster administrator control access to a service network.

This guide assumes that you understand the following Application Interconnect concepts:

site
A namespace in which Application Interconnect is installed.
token
A token is required to establish a link between two sites.
service network
After exposing services using Application Interconnect, you have created a service network.