Controlling Access to External Services
Egress Gateways act as a gateway for traffic exiting the mesh. Users are able to define services that are allowed to send traffic to external services through the gateway
Currently only HTTPS can be sent externally. However, the original outbound requests should use HTTP. These outbound HTTP requests are converted to HTTPS requests and sent to the external services. For example, a request to http://tetrate.io
from the service that goes through an Egress Gateway is converted to a request to https://tetrate.io
, and is proxied on behalf of the originating service. Currently requests that are ultimately need to be HTTP are not supported. For example, you will not be able to use Egress Gateways if your final destination is http://tetrate.io
This document will describe how to configure Egress Gateways to allow services to only send outbound requests to specific services. The following diagram shows the request and response flow when using an Egress Gateway:
Before you get started, make sure you:
✓ Familiarize yourself with TSB concepts
✓ Install the TSB environment. You can use TSB demo for quick install
✓ Completed TSB usage quickstart. This document assumes you already created Tenant and are familiar with Workspace and Config Groups. Also you need to configure tctl to your TSB environment.
Please note that in the following example you will deploy Egress Gateway in the demo cluster that you have created using the TSB demo install. If you are using another cluster, change the cluster name in the example accordingly.
Deploy Sleep Services
In this example you will use two sleep
services, each living in separate namespaces.
Create the namespaces sleep-one
and sleep-two
:
kubectl create namespace sleep-one
kubectl create namespace sleep-two
Then follow the instructions in the "Installing sleep
Workload in TSB" document to install sleep service two sleep services in the demo
cluster. Install the service sleep-one
in namespace sleep-one
, and the service sleep-two
in namespace sleep-two
, respectively
You do NOT need to create a Workspace, as you will do this later in this example.
Create Workspace and Traffic Group for Sleep Services
You will need a Traffic Group to associate with the Egress Gateway that you will be creating later. Since a Traffic Group belongs to a Workspace, you will need to create a Workspace as well.
Create a file name sleep-workspace.yaml
with the following contents. Replace the values for cluster
, organization
, and tenant
accordingly. For demo installations, you can use the value demo
for the cluster
, and tetrate
for both organization
and tenant
.
apiversion: api.tsb.tetrate.io/v2
kind: Workspace
metadata:
organization: <organization>
tenant: <tenant>
name: sleep
spec:
displayName: Sleep Workspace
namespaceSelector:
names:
- "<cluster>/sleep-one"
- "<clluser>/sleep-two"
---
apiVersion: traffic.tsb.tetrate.io/v2
kind: Group
metadata:
organization: <organization>
tenant: <tenant>
workspace: sleep
name: sleep-tg
spec:
displayName: Sleep Traffic
namespaceSelector:
names:
- "<cluster>/sleep-one"
- "<cluster>/sleep-two"
configMode: BRIDGED
Apply with tctl
:
tctl -f sleep-workspace.yaml
Deploy Egress Gateway
Create the Egress Gateway Namespace
Egress gateways are typically managed by a separate team than the one developing the app (in this case, the sleep
services) to avoid the ownerships being mixed up.
In this example we create a separate namespace egress
to manage the Egress Gateway. Execute the following command to create a new namespace:
kubectl create namespace egress
Deploy the Egress Gateway
Create a file called egress-deploy.yaml
with the following contents:
apiVersion: install.tetrate.io/v1alpha1
kind: EgressGateway
metadata:
name: cluster-egress
namespace: egress
spec:
kubeSpec:
service:
type: NodePort
Apply with kubectl:
kubectl apply -f egress-deploy.yaml