Passive Integration with Istio Service Mesh

Istio is an open source service mesh that layers transparently onto existing distributed applications. Istio’s powerful features provide a uniform and more efficient way to secure, connect, and monitor services. Istio uses a proxy to intercept all your network traffic, and consists of a control plane and a data plane. The control plane takes your desired configuration, and its view of the services, and dynamically programs the proxy servers, updating them as the rules or the environment changes. The data plane is the communication between services and support two modes - sidecar mode and ambient mode. The sidecar mode deploys an Envoy proxy along with each pod that you start in your cluster. The ambient mode uses a per-node Layer 4 proxy, and optionally a per-namespace Envoy proxy for Layer 7 features. For more information, see the Istio documentation.

Cequence Unified API Protection is a comprehensive solution that protects applications from a wide range of threats, including bot attacks, data loss, fraud, and business disruption. It does this by providing continuous, real-time protection across all phases of the application lifecycle, from discovery and inventory to risk assessment and mitigation. Cequence Unified API Protection follows a hub-and-spoke deployment model that centralizes API management and application security controls in a central hub, while spokes handle distributed application traffic. Visit the Cequence website for a detailed overview of Cequence Unified API Protection.

This document covers the integration of Istio Service Mesh with sidecar mode dataplane deployment with the Cequence UAP platform.

Passive Integration Overview

Cequence Unified API Protection integrates passively with the Istio Service Mesh by utilizing a Cequence Sensor, a data plane component, which is deployed as a sidecar container to the application pods that are running the Envoy proxy. The Cequence Sensor is responsible for capturing the traffic to the applications and sending it to the Cequence UAP platform for analysis. The Cequence Sensor organizes, filters, and normalizes network packet flow before forwarding the traffic to the Cequence control plane for analysis.

Integration using the Cequence Sensor is passive in nature and does not require any changes to the applications. Passive deployment is less effective at threat protection than active deployment, but it does not add any latency to application transactions.

The following sections describe the steps to integrate the Cequence Sensor into the Istio Service Mesh with the Istio dataplane deployed in a sidecar mode. The integration is achieved by injecting a Cequence Sensor container as a sidecar into the application pod.

Prerequisites

The following prerequisites must be confirmed before proceeding with setting up the integration between Cequence and Istio Service Mesh.

Kubernetes Cluster

Confirm that you have administrative access to the cluster to deploy the Cequence Sensor Sidecar Injector Helm chart.
The Cequence Sensor container will need to run as root user since it needs the escalated privileges to capture traffic from the interfaces it is monitoring. Please ensure that the Kubernetes cluster allows for the container to run as root.
The following Kubernetes resources are required for the Cequence Sensor to operate correctly:
- Namespace: The Cequence Sensor Sidecar Injector Helm chart creates a namespace during the deployment.
- ConfigMap: The Cequence Sensor Sidecar Injector Helm chart creates a ConfigMap during deployment. The ConfigMap stores the configuration that enables the injection of the Cequence Sensor sidecar.
- Service: The Cequence Sensor Sidecar Injector Helm chart exposes the Sensor Sidecar Injector as a service during deployment.
- ServiceAccount: The Cequence Sensor Sidecar Injector Helm chart creates a ServiceAccount during deployment.
- MutatingWebhookConfiguration: The Cequence Sensor Sidecar Injector Helm chart creates a MutatingWebhookConfiguration during deployment. The mutating webhook configuration enables the injection of the Sensor container as a sidecar into the application pods running in the namespace.
- ClusterRole: The Cequence Sensor Sidecar Injector Helm chart creates a ClusterRole to define the permissions required during the deployment.
- ClusterRoleBinding: The Cequence Sensor Sidecar Injector Helm chart creates a ClusterRoleBinding to bind the ClusterRole to the ServiceAccount during the deployment.
The following Kubernetes security context capabilities are required for the Cequence Sensor to operate correctly:
- NET_ADMIN: Enables various network-related operations such as setting promiscuous mode on the interfaces the Sensor listens on. This permission is disabled by default and needs to be enabled explicitly for the Sensor to capture the required metadata.
- CHOWN: Enables changes to the file UIDs and GIDs by the Sensor processes within the sidecar container. This permission is enabled by default, but existing orgaizational requirements or security policies can result in non-default configurations. This permission must be enabled for the Sensor to operate.
- DAC_OVERRIDE: Enables the read and write of files by the Sensor processes within the sidecar container. This permission is enabled by default, but existing orgaizational requirements or security policies can result in non-default configurations. This permission must be enabled for the Sensor to operate.
- NET_RAW: Enables the creation of packet sockets for the capture of packets received and transmitted at the network device driver level. This permission is enabled by default, but existing orgaizational requirements or security policies can result in non-default configurations. This permission must be enabled for the Sensor to capture traffic.
Confirm that the Kubernetes cluster has access to the following resources:
- Access to port TCP/443 to Cequence UAP Edge, Authentication and Policy-Engine endpoints.
- Access to the Cequence registry, registry.gitlab.com/cequence, to pull the images necessary. Alternately, you can download the images, add them to your local registry and update the Helm chart overrides file to deploy them from the local registry. The following images are required for a successful deployment:
  - sensorslim
  - cequence-sidecar-injector
- Access to the Cequence Helm repository, cequence.gitlab.io/helm-charts, to pull the Cequence Sidecar Injector Helm chart.
- Access token to pull the images needed for deploying the Cequence Sensor Sidecar Injector Helm chart. Cequence will provide a deploy token to pull the images from the Cequence registy. You will need to store this token in a Kubernetes Secret and configure the object name in the Helm chart overrides file. If you are using a local registry, you need to configure the Helm chart overrides file with the Kubernetes Secret configured for the access token to pull from the local registry, assuming your local registry requires an access token.
Confirm that the host you will use to deploy the integration has access to the Kubernetes cluster and can pull the Cequence Sidecar Injector Helm chart from the Cequence Helm repository.

Istio Service Mesh

Istio Service Mesh must be installed and running. The integration has been validated with Istio version 1.22.2.
Gather the application namespaces where the sidecar container needs to be injected, to be used in The Cequence Sensor Sidecar Injector Helm chart overrides file.

Cequence UAP platform

Confirm that the Cequence UAP platform is installed and working properly before proceeding with the integration. On a new install, a member of the Cequence Customer Success team can confirm that the Cequence UAP platform is working properly.
Confirm that you have access to the credentials for a user account on the Cequence UAP platform that has the privileges to create a client token for traffic ingestion using the User Management menu.
Gather the following information from the Cequence UAP platform:
- The client ID and client secret generated for traffic ingestion from the Cequence Sensor.
- The URLs for the following Cequence UAP endpoints:
  - Edge (typically edge.uap.yourdomain.com)
  - Authentication (typically auth.uap.yourdomain.com)
  - Policy Engine (typically policy-engine.uap.yourdomain.com)

Deployment Steps

Add the Cequence Helm chart repository to prepare for the deployment.

helm repo add cequence https://cequence.gitlab.io/helm-charts
helm repo update

Create a values override file to use for deloying the Helm chart. The following section shows a sample values override file.

sidecarInjector:
  # Kubernetes Secret configured to store the Cequence provided deploy token
 image: 
   pullSecrets: "regcred"

sensorSidecar:
  # Client ID created from the UAP
  clientId: "client-id"

  # Client Secret
  clientSecret: "client-secret"

  # Subdomain used with the UAP
  subdomain: "uap.yourdomain.com"

  # Application Namespaces to be used for the configmap creation.
  app_namespaces:
    - "myapp-namespace"
    - "myapp-namespace2"

  # Kubernetes Secret configured to store the Cequence provided deploy token
  image:
    pullSecrets: "regcred"

Run the following command to create a namespace for the Cequence Sensor sidecar injector and a Kubernetes secret to enable access to the Cequence image registry.

kubectl create ns cequence-sensor
kubectl create secret docker-registry regcred \
  --docker-server="registry.gitlab.com" \
  --docker-username=<registry_username> \
  --docker-password=<registry_password> -n cequence-sensor

Deploy the Cequence Sensor Sidecar Injector Helm chart using the values override file by running the following command.

helm upgrade --install cequence-sensor-sidecar cequence/sensor-sidecar-injector \
     -f values-override.yaml \
     -n cequence-sensor

Update the deployment in the application namespaces you chose in the overrides file to include the following annotation. Alternately, update the application deployment YAML to make the Cequence Sensor container persistent. Updating the application deployment YAML restarts the pod and adds the Cequence Sensor container.
```
spec: 
  template: 
    metadata: 
      annotations: 
        sidecar-injector.cequence.com/inject: cequence-sensor
```
To confirm that the Cequence Sensor container is injected as a sidecar into the application pods, run the following command.
```
kubectl get pods -n myapp-namespace myapp-pod
```
When sidecar injection is successful, the command shows three containers for the pod: the application container, the Envoy proxy container, and the Cequence Sensor container.

Confirm that the Cequence Sensor container is capturing the traffic to the applications and sending the traffic to the Cequence UAP platform for analysis.

Log in to Cequence UAP UI and navigate to Sitemap Discovery under the Threat Protection section on the left navigation pane to check the hosts and endpoints discovered.
Navigate to Detection under the Threat Protection section on the left navigation pane to check real time traffic chart and anlysis of the transactions being sent by the Sensor.
Navigate to Dashboard under the Runtime Inventory section on the left navigation pane to check the API endpoints discovered and initial analysis of the APIs.

Expanding the Integration to Additional Namespaces

To deploy the Cequence Sensor sidecar container into additional namespaces, follow the steps below:

Update the app_namespaces field in the values override file with the additional namespaces.

Run the following command to upgrade the Helm chart with the updated values override file.

helm upgrade --install cequence-sensor-sidecar cequence/sensor-sidecar-injector \
     -f values-override.yaml -n cequence-sensor

Update the deployment in the application namespaces you chose in the overrides file to include the following annotation. Alternately, update the application deployment YAML to make the Cequence Sensor container persistent. Updating the application deployment YAML restarts the pod and adds the Cequence Sensor container.

spec: 
  template: 
    metadata: 
      annotations: 
        sidecar-injector.cequence.com/inject: cequence-sensor

Troubleshooting

If the Cequence Sensor container does not show up as part of the application pod, check the logs of the Cequence Sensor container for errors.

kubectl logs -n myapp-namespace myapp-pod -c cequence-sensor

If the Cequence UAP UI does not show any traffic under Sitemap Discovery, check the logs of the Cequence Sensor for errors.

kubectl exec -it -n myapp-namespace myapp-pod -c cequence-sensor -- /bin/bash
cd sensor-connector/logs
tail -f sensor-connector.log

When Cequence Sensor is functioning correctly, the output of the command resembles the following example.

===========================================================================
2024-07-17T04:12:50.973Z info
==============================connector stats==============================
{}
reader: read: 6042, rate: 3, read-queue: length: 0, adds: 0, removes: 0, drops: 0, avg-rec-sz: 0.00kb;
pipeline: sensor-unified-api-edge, received: 5666, filtered out: 0, written: 5666
  datasink: sensor-api-edge, type: http, connected: true, received: 5666, written: 5666, errors: 0, conn_drops: 0, rate: 4, write_time: 0us
===========================================================================

If the errors indicate authentication issues, check the client ID and client secret used in the values override file.
If there are connectivity errors, check the connectivity to the Cequence UAP platform endpoints from the Kubernetes cluster.
If the written counters under datasink are not incrementing, check that the Cequence UAP platform endpoints are configured correctly in the values override file.
If the received counters under datasink are not incrementing, please contact the Cequence Customer Success team for further assistance.