Enabling App and API Protection for Istio

Docs > Datadog Security > App and API Protection > Threat Management Setup > Enabling AAP Threat Detection using Datadog Tracing Libraries > Enabling App and API Protection for Istio

App and API Protection for Istio is in Preview

To try the preview of App and API Protection for Istio, follow the setup instructions below.

You can enable App and API Protection for your services within an Istio service mesh. The Datadog Istio integration allows Datadog to inspect and protect your traffic for threat detection and blocking directly at the edge of your infrastructure. This can be applied at the Istio Ingress Gateway or at the sidecar level.

Prerequisites

Before you begin, ensure you have the following:

A running Kubernetes cluster with Istio installed.
The Datadog Agent is installed and configured in your Kubernetes cluster.
- Ensure Remote Configuration is enabled and configured to enable blocking attackers through the Datadog UI.
- Ensure APM is enabled in the Agent. This allows the external processor service to send its own traces to the Agent.

Enabling threat detection

Enabling the threat detection for Istio involves two main steps:

Deploying the Datadog External Processor service.
Configuring an EnvoyFilter to direct traffic from your Istio Ingress Gateway (or sidecars) to this service.

1. Deploy the Datadog External Processor Service

This service is a gRPC server that Envoy communicates with to have requests and responses analysed by App and API Protection.

Create a Kubernetes Deployment and Service for the Datadog External Processor. It’s recommended to deploy this service in a namespace accessible by your Istio Ingress Gateway, such as istio-system or a dedicated namespace.

The Datadog External Processor Docker image is available on the Datadog Go tracer GitHub Registry.

Here is an example manifest (datadog-aap-extproc-service.yaml):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: datadog-aap-extproc-deployment
  namespace: istio-system # Or your preferred namespace, ensure it's resolvable by the Envoy proxy
  labels:
    app: datadog-aap-extproc
spec:
  replicas: 1 # Adjust replica count based on your load
  selector:
    matchLabels:
      app: datadog-aap-extproc
  template:
    metadata:
      labels:
        app: datadog-aap-extproc
    spec:
      containers:
      - name: datadog-aap-extproc-container
        image: ghcr.io/datadog/dd-trace-go/service-extensions-callout:v1.73.1 # Replace with the latest version version
        ports:
        - name: grpc
          containerPort: 443 # Default gRPC port for the external processor
        - name: health
          containerPort: 80  # Default health check port
        env:
        # ---- Required Agent Configuration ----
        # Configure the address of your Datadog Agent for the processor
        - name: DD_AGENT_HOST
          value: "<your-datadog-agent-service>.<your-datadog-agent-namespace>.svc.cluster.local"
        - name: DD_TRACE_AGENT_PORT # Optional if your Agent's trace port is the default 8126
          value: "8126"

        readinessProbe:
          httpGet:
            path: /
            port: health
          initialDelaySeconds: 5
          periodSeconds: 10
        livenessProbe:
          httpGet:
            path: /
            port: health
          initialDelaySeconds: 15
          periodSeconds: 20
---
apiVersion: v1
kind: Service
metadata:
  name: datadog-aap-extproc-service # This name will be used in the EnvoyFilter configuration
  namespace: istio-system # Must be the same namespace as the Deployment
  labels:
    app: datadog-aap-extproc
spec:
  ports:
  - name: grpc
    port: 443
    targetPort: grpc
    protocol: TCP
  selector:
    app: datadog-aap-extproc
  type: ClusterIP

Environment Variables for the External Processor

The Datadog App and API Protection External Processor supports the following environment variables to be configured:

Environment variable	Default value	Description
`DD_SERVICE_EXTENSION_HOST`	`0.0.0.0`	gRPC server listening address.
`DD_SERVICE_EXTENSION_PORT`	`443`	gRPC server port.
`DD_SERVICE_EXTENSION_HEALTHCHECK_PORT`	`80`	HTTP server port for health checks.

Configure the connection from the external processor to the Datadog Agent using these environment variables:

Environment variable	Default value	Description
`DD_AGENT_HOST`	`localhost`	Hostname or IP of your Datadog Agent.
`DD_TRACE_AGENT_PORT`	`8126`	Port of the Datadog Agent for trace collection.

Note: The External Processor is built on top of the Datadog Go Tracer. It follows the same release process as the tracer, and its Docker images are tagged with the corresponding tracer version.

You can find more configuration options in Configuring the Go Tracing Library and App and API Protection Library Configuration.

2. Configure an EnvoyFilter

Next, create an EnvoyFilter resource to instruct your Istio Ingress Gateway or specific sidecar proxies to send traffic to the datadog-aap-extproc-service you deployed. This filter tells Envoy how to connect to the external processor and which traffic to send.

Choose the appropriate configuration based on whether you want to apply App and API Protection at the Ingress Gateway or directly on your application’s sidecar proxies.

This configuration applies App and API Protection to all traffic passing through your Istio Ingress Gateway. This is a common approach to protect all north-south traffic entering your service mesh.

Here is an example manifest (datadog-aap-gateway-filter.yaml) that targets the default Istio Ingress Gateway, which typically runs in the istio-system namespace with the label istio: ingressgateway. You must update these to match your specific application.

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: datadog-aap-gateway-filter
  namespace: istio-system # Namespace of your Istio Ingress Gateway
spec:
  workloadSelector:
    labels:
      istio: ingressgateway # Standard label for Istio Ingress Gateway pods
  configPatches:
    # Patch 1: Add the Cluster definition for the Datadog External Processing service
    - applyTo: CLUSTER
      match:
        context: GATEWAY
        cluster:
          service: "*"
      patch:
        operation: ADD
        value:
          name: "datadog_aap_ext_proc_cluster" # A unique name for this cluster configuration
          type: STRICT_DNS
          connect_timeout: 0.2s
          lb_policy: ROUND_ROBIN
          http2_protocol_options: {}
          transport_socket:
            name: envoy.transport_sockets.tls
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext
              sni: "localhost"
          load_assignment:
            cluster_name: "datadog_aap_ext_proc_cluster"
            endpoints:
            - lb_endpoints:
              - endpoint:
                  address:
                    socket_address:
                      # Address of the Datadog External Processor service
                      address: "datadog-aap-extproc-service.istio-system.svc.cluster.local" # Adjust if your service name or namespace is different
                      port_value: 443

    # Patch 2: Add the External Processing HTTP Filter to the Gateway's HTTP connection manager
    - applyTo: HTTP_FILTER
      match:
        context: GATEWAY
        listener:
          filterChain:
            filter:
              name: "envoy.filters.network.http_connection_manager"
              subFilter:
                name: "envoy.filters.http.router"
      patch:
        operation: INSERT_BEFORE
        value:
          name: envoy.filters.http.ext_proc
          typed_config:
            "@type": type.googleapis.com/envoy.extensions.filters.http.ext_proc.v3.ExternalProcessor
            grpc_service:
              envoy_grpc:
                cluster_name: "datadog_aap_ext_proc_cluster"

This configuration applies App and API Protection to specific pods within your service mesh by targeting their Istio sidecar proxies. This allows for more granular control over which services are protected.

Here is an example manifest (datadog-aap-sidecar-filter.yaml) that targets pods with the label app: <your-app-label> in the namespace <your-application-namespace>. You must update these to match your specific application.

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: datadog-aap-sidecar-filter
  namespace: <your-application-namespace> # Namespace of your application
spec:
  workloadSelector:
    labels:
      app: <your-app-label> # Label of your application pods
  configPatches:
    # Patch 1: Add the Cluster definition for the Datadog External Processing service
    - applyTo: CLUSTER
      match:
        context: SIDECAR_INBOUND
        cluster:
          service: "*"
      patch:
        operation: ADD
        value:
          name: "datadog_aap_ext_proc_cluster" # A unique name for this cluster configuration
          type: STRICT_DNS
          connect_timeout: 0.2s
          lb_policy: ROUND_ROBIN
          http2_protocol_options: {}
          transport_socket:
            name: envoy.transport_sockets.tls
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext
              sni: "localhost"
          load_assignment:
            cluster_name: "datadog_aap_ext_proc_cluster"
            endpoints:
            - lb_endpoints:
              - endpoint:
                  address:
                    socket_address:
                      # Address of the Datadog External Processor service
                      address: "datadog-aap-extproc-service.<extproc-service-namespace>.svc.cluster.local" # Adjust if your service name or namespace is different
                      port_value: 443

    # Patch 2: Add the External Processing HTTP Filter to the Sidecar's connection manager
    - applyTo: HTTP_FILTER
      match:
        context: SIDECAR_INBOUND
        listener:
          filterChain:
            filter:
              name: "envoy.filters.network.http_connection_manager"
              subFilter:
                name: "envoy.filters.http.router"
      patch:
        operation: INSERT_BEFORE
        value:
          name: envoy.filters.http.ext_proc
          typed_config:
            "@type": type.googleapis.com/envoy.extensions.filters.http.ext_proc.v3.ExternalProcessor
            grpc_service:
              envoy_grpc:
                cluster_name: "datadog_aap_ext_proc_cluster"
              timeout: 0.2s

After applying the chosen EnvoyFilter, traffic passing through your Istio Ingress Gateway or selected sidecars will be processed by the Datadog External Processor service, enabling App and API Protection features.

Validation

After this configuration is complete, the library collects security data from your application and sends it to the Agent. The Agent sends the data to Datadog, where out-of-the-box detection rules flag attacker techniques and potential misconfigurations so you can take steps to remediate.

To see App and API Protection threat detection in action, send known attack patterns to your application. For example, trigger the Security Scanner Detected rule by running a file that contains the following curl script:
```
for ((i=1;i<=250;i++)); 
do
# Target existing service's routes
curl https://your-application-url/existing-route -A dd-test-scanner-log;
# Target non existing service's routes
curl https://your-application-url/non-existing-route -A dd-test-scanner-log;
done
```
Note: The dd-test-scanner-log value is supported in the most recent releases.
A few minutes after you enable your application and send known attack patterns to it, threat information appears in the Application Signals Explorer and vulnerability information appears in the Vulnerabilities explorer.