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
Create a Workspace and a Gateway Group for Egress Gateway
You will also need to create a Workspace and a Gateway Group for the Egress Gateway that you just created.
Create a file named egress-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: egress
spec:
displayName: Egress Workspace
namespaceSelector:
names:
- "<cluster>/egress"
---
apiVersion: gateway.tsb.tetrate.io/v2
kind: Group
metadata:
organization: <organization>
tenant: <tenant>
workspace: egress
name: egress-gw
spec:
displayName: Egress Gateway
namespaceSelector:
names:
- "<cluster>/egress"
configMode: BRIDGED
Apply with tctl
tctl apply -f egress-workspace.yaml
Configure Egress Gateway
In this example, you will be applying different configurations to the two sleep services.
sleep-one will be configured so that it can access all external URLs, but sleep-two will only be allowed to access a single destination (in this sample, "edition.cnn.com").
Create a file named egress-config.yaml with the following contents. Replace the values for organization and tenant accordingly. For demo installations, you can use the value tetrate for both organization and tenant.
apiVersion: gateway.tsb.tetrate.io/v2
kind: EgressGateway
metadata:
organization: <organization>
tenant: <tenant>
workspace: egress
group: egress-gw
name: cluster-egress
spec:
workloadSelector:
namespace: egress
labels:
app: cluster-egress
authorization:
- from:
mode: CUSTOM
serviceAccounts: ["sleep-one/sleep"]
to: ["*"]
- from:
mode: CUSTOM
serviceAccounts: ["sleep-two/sleep"]
to: ["edition.cnn.com"]
Apply with tctl
tctl apply -f egress-config.yaml
Create TrafficSettings to use Egress Gateway
Finally, create traffic settings to tie the Traffic Group that the services are associated to with the Egress Gateway.
Create a file named sleep-traffic-setting-egress.yaml with the following contents. Replace the values for organization and tenant accordingly. For demo installations, you can use the value tetrate for both organization and tenant.
The host value is in <namespace>/<fqdn> format. The fqdn value is derived from the namespace and metadata.name values specified in the previous step:
apiVersion: traffic.tsb.tetrate.io/v2
kind: TrafficSetting
metadata:
organization: <organization>
tenant: <tenant>
workspace: sleep
group: sleep-tg
name: sleep-traffic-settings
spec:
egress:
host: egress/cluster-egress.egress.svc.cluster.local
Apply this with tctl:
tctl apply -f sleep-traffic-setting-egress.yaml
Testing
To test whether Egress Gateway is working correctly, you will be sending requests from the sleep services to external services.
For this you will need to figure out the Pod names for sleep-one and sleep-two. Execute the following commands to lookup the Pod names:
export SLEEP_ONE_POD=$(kubectl get pod -n sleep-one -l app=sleep -o jsonpath='{.items[*].metadata.name}')
export SLEEP_TWO_POD=$(kubectl get pod -n sleep-two -l app=sleep -o jsonpath='{.items[*].metadata.name}')
Execute the following commands against sleep-one. Since you have configured the Egress Gateway such that sleep-one is allowed to access all external services, the following commands should all display "200":
kubectl exec ${SLEEP_ONE_POD} -n sleep-one -c sleep -- \
curl http://twitter.com \
-s \
-o /dev/null \
-L \
-w "%{http_code}\n"
kubectl exec ${SLEEP_ONE_POD} -n sleep-one -c sleep -- \
curl http://github.com \
-s \
-o /dev/null \
-L \
-w "%{http_code}\n"
kubectl exec ${SLEEP_ONE_POD} -n sleep-one -c sleep -- \
curl http://edition.cnn.com \
-s \
-o /dev/null \
-L \
-w "%{http_code}\n"
kubectl exec ${SLEEP_ONE_POD} -n sleep-one -c sleep -- \
curl http://httpbin.org \
-s \
-o /dev/null \
-L \
-w "%{http_code}\n"
Do the same for service sleep-two by replacing SLEEP_ONE_POD to SLEEP_TWO_POD, and sleep-one to sleep-two, respectively.
This time, only requests to edition.cnn.com should display "200". All other requests should display "403".