Enabling App and API Protection for Istio

문서 > Datadog 보안 > 애플리케이션 보안 관리 > App and API Protection 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.
  - Optionally, enable the Cluster Agent Admission Controller to automatically inject the Datadog Agent host information to the App and API Protection External Processor service.

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: <your-preferred-namespace> # Change to 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:
        # ---- Optional: Agent Configuration ----
        # If you enabled the Cluster Agent Admission Controller, you can skip this section as the Agent host information is automatically injected.
        # Otherwise, configure the address of your Datadog Agent for the external 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: <your-preferred-namespace> # Change to your preferred namespace, ensure it's resolvable by the Envoy proxy
  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: <your-preferred-namespace> # Change to your preferred namespace, ensure it's resolvable by the Envoy proxy
spec:
  ## If workloadSelector is omitted, the following patches apply to Gateway pods in this EnvoyFilter's namespace
  ## Use workloadSelector to target a specific Gateway instance.
  # workloadSelector:
  #   labels:
  #     istio: ingressgateway # Label for the default Istio Gateway implementation
  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.<your-preferred-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 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.

이 구성을 완료하면 라이브러리가 애플리케이션에서 보안 데이터를 수집해 에이전트로 전송하고, 이 데이터는 다시 Datadog로 전송됩니다. 그러면 기본 감지 규칙에 기반해 공격자 기술과 잠재 구성 오류가 플래그되며, 이를 기반으로 문제 해결 단계를 진행할 수 있습니다.

애플리케이션 보안 관리에서 감지 활동을 잘 하고 있는지 확인하려면 알려진 공격 패턴을 애플리케이션으로 보내세요. 예를 들어 다음 curl 스크립트가 포함된 파일을 실행해 보안 스캐너 감지됨 규칙을 트리거할 수 있습니다.
```
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
```
참고: dd-test-scanner-log 값은 최신 릴리스에서 지원됩니다.
애플리케이션을 활성화하고 실행한 몇 분 후 Application Signals Explorer에서 위협 정보가 표시되고 Vulnerability Explorer에 취약 정보가 표시됩니다.