Overview
Tetrate Service Bridge (TSB) from tetrate.io is an 'edge-to-workload' application management platform. It provides a service mesh management plane designed to manage and configure networking, security, and observability. The TSB works at the backend 'edge', at cluster ingress, between the workloads within a Kubernetes cluster. The mesh management plane configures gateway and intra-cluster service connectivity.
Tetrate managed environments provide an excellent opportunity for integration with Cequence monitoring and mitigation components. A typical integration module is a 'hybrid' approach in which the Cequence Defender is spun up in the same hosting space as the TSB, and Bot Defense and API Sentinel are SaaS based.
Cequence Integration Architecture
The Cequence Unified API Protection (UAP) platform is comprised of a control plane and a data plane. The control plane includes the Cequence API Sentinel and Bot Defense components. The Cequence Defender, responsible for processing traffic, makes up the data plane.
In a hybrid model the control and analysis components for the Cequence UAP platform, along with the web UI, are provided as SaaS services, while Cequence Defender is deployed to the application cluster.
In a typical hybrid Cequence/Tetrate managed environment the Tetrate Service Bridge is configured to route incoming network application traffic through Cequence Defender where it is quickly analyzed and, if safe, forwarded onto the destination application. When mitigation policies are enabled, the Defender actively mitigates the bad traffic issuing a preconfigured mitigation response back to the requesting client. The Defender asynchronously sends network metadata to the Cequence UAP platform that then populates the Bot Defense and API Sentinel dashboards with the traffic analysis.
Sample Application:
The 'before' and 'after' topology can be viewed from within the Tetrate management Dashboard.
The first snapshot displays a "before" view showing routing configuration with network traffic forwarded to a sample application deployed within the Tetrate Service Mesh.
Figure (a): TSB Dashboard: Topology: Client is connected to Applications (Before Cequence Defender integration)
Once Cequence Defender is correctly integrated with Tetrate, application traffic will be routed to the Cequence Defender. The Defender will also send the traffic metadata over to the Cequence UAP platform and the dashboards for Cequence Bot Defense and API Sentinel will start showing the analyzed traffic data. A "fail-open" configuration is always part of the configuration to ensure that application traffic is un-interrupted in the rare event that Defender is unavailable, once deployed.
Figure (b): TSB Dashboard: Topology: Detail : Network traffic is re-routed through Cequence Defender
Integration Steps
This article section provides instructions for deploying a Cequence Defender in a Tetrate Management based Kubernetes Cluster to provide analysis and risk abatement to a Tetrate Service Mesh resident application. It supports a hybrid configuration in which Cequence Defender is resident in the customer provided infrastructure and connects to Cequence SaaS hosted Cequence UAP bot and API risk analysis services.
Step 1: Deploy Cequence Defender
Step 2: Configure Application Filter with Fail-Over
Step 3: Reconfigure TSB Gateway
Prerequisites and Support
Before you begin, please contact the Cequence Customer Success Team for configuration files, credentials, and certificates specific to your environment. You will need:
- Cequence Registry access credentials
<cq-provided-username>, <cq-provided-password>) - Defender/Cequence UAP SSL certificates.
- Site specific defender-overrides.yaml configuration file.
Step 1: Deploy Cequence Defender
Authenticate to your Tetrate Service Bridge Kubernetes cluster.
Create a local cequence repository and confirm availability of cequence/defender.
helm repo add cequence https://cequence.gitlab.io/helm-charts/
helm search repo defender
Load Cequence Registry credentials to the cluster. Credentials will be provided by Cequence Support.
kubectl create secret docker-registry regcred \
--docker-server=registry.gitlab.com \
--docker-username=<cq-provided-username> \
--docker-password=<cq-provided-password> \
--namespace cequence
Deploy certificates allowing Cequence Defender to communicate with the SaaS based Cequence UAP platform. These certificates are specific to each deployment installation.
kubectl create configmap defender-kafka-certs-cm-0 \
--from-file cqai-kafka-certs \
--namespace cequence
Deploy the Cequence Defender
The configuration file defender-overrides.yaml is specific to each customer environment. Expect to work with Cequence Customer Success Team to create a configuration file for your environment. A sample defender-overrides.yaml file is attached to this article for review.
helm upgrade --install defender cequence/defender \
--version 2.4.2 --values defender-overrides.yaml --namespace cequence
Step 2: Configure Application Filter with Fail-Over
- Deploy a Service Entry
Add a service entry to the Istio Service Registry for 'host' defender.cequence.ai. Create a service-entry.yaml similar to the one below for your environment.
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: mixed-mode-service
namespace: cequence
spec:
hosts:
- defender.cequence.ai
location: MESH_INTERNAL
ports:
- name: http
number: 80
protocol: HTTP
resolution: NONE
And apply it:
kubectl apply -f service-entry.yaml
- Establish an Envoy Filter with a fail-open policy
Deploy an Envoy Filter to create a fail-open policy back to the original application service. In the example envoy-filter.yaml file belowfirefly-iii.cequence.svc.cluster.local the original application service and is configured as the fail-open (secondary) option to defender.cequence.svc.cluster.local.
Note the connection timeout (connect_timeout) of 1 second.
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
name: aggregate-cluster
namespace: cequence
spec:
configPatches:
- applyTo: CLUSTER
match:
cluster:
name: "outbound|80||defender.cequence.ai"
patch:
operation: REMOVE
- applyTo: CLUSTER
match:
context: GATEWAY
cluster:
name: "PassthroughCluster"
patch:
operation: ADD
value:
name: "outbound|80||defender.cequence.ai"
lb_policy: CLUSTER_PROVIDED
connect_timeout: 1s
cluster_type:
name: envoy.clusters.aggregate
typed_config:
"@type": type.googleapis.com/envoy.config.cluster.aggregate.v2alpha.ClusterConfig
clusters:
- outbound|80||defender.cequence.svc.cluster.local
- outbound|80||firefly-iii.cequence.svc.cluster.local
Apply the filter:
kubectl apply -f envoy-filter.yaml
- Deploy a Destination Rule
Deploy a destination rule for outlier detection on the Cequence Defender service. Detection will be triggered on 3 consecutive 5xx errors.
Sample destinationrule-outlier.yaml:
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: outlier
namespace: cequence
spec:
host: "defender.cequence.svc.cluster.local"
trafficPolicy:
outlierDetection:
consecutive5xxErrors: 3
Step 3: Reconfigure TSB Gateway
Modify the TSB Gateway configuration file to route network traffic to the Cequence Defender service by default.
In the example below, the 'firefly' application has already been configured within the Tetrate Management platform with the TSB Gateway serving on port 443 (TLS/SSL) and forwarding traffic to the application service over port 80.
sample-fireflyapp-gateway-original.yaml:
apiVersion: gateway.tsb.tetrate.io/v2
kind: IngressGateway
Metadata:
organization: tetrate
name: cq-gw-ingress
group: cequence-gw
workspace: cequence-ws
tenant: tetrate
spec:
workloadSelector:
namespace: cequence
labels:
app: tsb-gateway-cequence
http:
- name: cequence-routing-logic
hostname: "firefly-tsb-cequence.int.cqsec.net"
port: 443
tls:
mode: SIMPLE
secretName: firefly-tsb-cequence-cert
routing:
rules:
- route:
host: "cequence/firefly-iii.cequence.svc.cluster.local"
port: 80
Once the Cequence Defender service is deployed within this environment, the application TSB Gateway routing rules for the application will be re-configured to first send traffic to the Cequence Defender and then, for 'safe' messages, onto the application.
Cequence Defender will quickly process messages, sending good and sanitized traffic back to the TSB Gateway to then forwarding onto the original application (example 'firefly'). The TSB Gateway makes the forwarding determination by looking for a unique request header ("cq-select") injected by the Cequence Defender. Response traffic is also routed through Cequence Defender in a similar manner. Cequence Defender also sends, asynchronously, Cequence UAP analysis engines (BotDefense and API Sentinel), normalized versions of the traffic message for further analysis. In mitigation mode, based on policy defined mitigation rules, Cequence Defender may take mitigation action, including blocking, or redirecting, application traffic.
A sample revised TSB configuration file for example application 'firefly' is shown below, with routing reconfigured. As shown, under the 'rules' section, this will send all traffic to the Cequence Defender, by default. If the Cequence Defender injected 'cq-select' header is found in a message it will, instead be sent to the application.
sample-fireflyapp-gateway-with-defender.yaml:
apiVersion: gateway.tsb.tetrate.io/v2
kind: IngressGateway
Metadata:
organization: tetrate
name: cq-gw-ingress
group: cequence-gw
workspace: cequence-ws
tenant: tetrate
spec:
workloadSelector:
namespace: cequence
labels:
app: tsb-gateway-cequence
http:
- name: cequence-routing-logic
hostname: "firefly-tsb-cequence.int.cqsec.net"
port: 443
tls:
mode: SIMPLE
secretName: firefly-tsb-cequence-cert
routing:
rules:
- match:
- headers:
dq-select: { regex: ".*" }
route:
host: "cequence/defender.cequence.svc.cluster.local"
port: 80
- match:
- headers:
cq-select: { regex: ".*" }
route:
host: "cequence/firefly-iii.cequence.svc.cluster.local"
port: 80
- route:
host: "cequence/defender.ceqhttps://insight.cqai-dev.eng.int.cequence.ai/#/loginuence.ai"
port: 80
- (re) Deploy the TSB Gateway
Typically this is done using the TSB CLI (tctl):
tctl apply -f gateway-with-defender.yaml
Sample Configuration Files
- Service entry
- Destination rule outlier
- Defender overrides
- Sample Firefly app gateway with Defender
- Sample Firefly app gateway
- Envoy filter
Version History
Date | Version | Notes |
Nov 1, 2021 | 2 | Updated with newer diagrams and screenshots. |
Sep 18, 2021 | 1 | Initial version. |