Enabling App and API Protection for Google Kubernetes Engine (GKE)

Docs > Datadog Security > App and API Protection > Enabling App and API Protection > Set up App and API Protection on Kubernetes > Enabling App and API Protection for Google Kubernetes Engine (GKE)

App and API Protection for GKE is in Preview

To try the Preview of App and API Protection for GKE, use the following setup instructions.

You can enable Datadog App and API Protection on a Google Kubernetes Engine (GKE) Gateway to inspect and protect traffic at the cluster edge. The integration uses the GKE Gateway controller and the GCPTrafficExtension custom resource to attach the Datadog security processor to the GCP Cloud Load Balancer.

Prerequisites

A GKE cluster running version 1.33 or later, with the Gateway API enabled.
A Gateway resource that uses a GatewayClass supporting traffic extensions, such as gke-l7-global-external-managed or gke-l7-regional-external-managed. For the full list, see supported GatewayClasses for GCPTrafficExtension.
The Datadog Agent is installed and configured in your Kubernetes cluster.
- Remote Configuration is enabled and configured in the Datadog UI to block attackers.
- APM is enabled in the Agent so the security processor can send its own traces to the Agent.

Enabling threat detection

To enable App and API Protection on a GKE Gateway, do the following:

Deploy the Datadog security processor service in your cluster.
Create a HealthCheckPolicy so GCP can probe the security processor.
Create a GCPTrafficExtension that attaches the security processor to your Gateway.

Deploy the Datadog security processor service

The Datadog security processor is a gRPC service that analyzes requests and responses for App and API Protection. Deploy it in the same namespace as your Gateway. The Docker image is available on the Datadog Go tracer GitHub Registry.

Example manifest (datadog-aap-extproc-service.yaml):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: datadog-aap-extproc-deployment
  namespace: <your-gateway-namespace> # Same namespace as the Gateway
  labels:
    app: datadog-aap-extproc
spec:
  replicas: 1 # Adjust the 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:latest
          ports:
            - name: grpc
              containerPort: 443 # Default gRPC port for the security processor
            - name: health
              containerPort: 80  # Default health check port
          env:
            # Agent configuration: host and port of your Datadog Agent
            - 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 is referenced by the GCPTrafficExtension
  namespace: <your-gateway-namespace> # Same namespace as the Gateway
  labels:
    app: datadog-aap-extproc
spec:
  selector:
    app: datadog-aap-extproc
  ports:
    - name: grpc
      port: 443
      targetPort: grpc
      protocol: TCP
      appProtocol: HTTP2 # Required: GKE callout backends must use HTTP/2
    - name: health
      port: 80
      targetPort: health
      protocol: TCP

On GKE, backends used for Service Extension callouts must support HTTP/2. Setting appProtocol: HTTP2 on the gRPC Service port tells the GKE Gateway controller to forward traffic over HTTP/2. Without it, the load balancer can't send gRPC traffic to the security processor.

Configuration options for the security processor

The Datadog security processor exposes the following settings:

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.
`DD_APPSEC_BODY_PARSING_SIZE_LIMIT`	`0`	Maximum size of bodies to process, in bytes. If set to `0`, bodies are not processed. Recommended value is `10000000` (10MB).
`DD_SERVICE`	`serviceextensions`	Service name shown in the Datadog UI.

Configure the connection from the security processor to the Datadog Agent with 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.

The security processor is built on top of the Datadog Go Tracer and inherits all of its environment variables. See Configuring the Go Tracing Library and App and API Protection Library Configuration.

Because the Datadog security processor is built on top of the Datadog Go tracer, it generally follows the same release process as the tracer, and its Docker images are tagged with the corresponding tracer version (for example, v2.7.0). In some cases, early release versions might be published between official tracer releases, and these images are tagged with a suffix such as -docker.1.

Create a HealthCheckPolicy

GKE uses a HealthCheckPolicy to probe Services used as backends by Google Cloud load balancers. Point the policy at the security processor Service so the load balancer can probe it and start forwarding traffic.

Example manifest (datadog-aap-extproc-hc.yaml):

apiVersion: networking.gke.io/v1
kind: HealthCheckPolicy
metadata:
  name: datadog-aap-extproc-hc
  namespace: <your-gateway-namespace> # Same namespace as the Gateway and the security processor Service
spec:
  targetRef:
    group: ""
    kind: Service
    name: datadog-aap-extproc-service
  default:
    checkIntervalSec: 15
    timeoutSec: 15
    healthyThreshold: 1
    unhealthyThreshold: 2
    logConfig:
      enabled: true
    config:
      type: HTTP
      httpHealthCheck:
        portSpecification: USE_FIXED_PORT
        port: 80
        requestPath: "/"

Create a GCPTrafficExtension

Attach the security processor to your Gateway with a GCPTrafficExtension. The extension forwards requests and responses from the Gateway to the security processor for inspection.

Example manifest (datadog-aap-extproc-extension.yaml):

apiVersion: networking.gke.io/v1
kind: GCPTrafficExtension
metadata:
  name: datadog-aap-extproc-extension
  namespace: <your-gateway-namespace> # Same namespace as the Gateway
spec:
  targetRefs:
    - group: "gateway.networking.k8s.io"
      kind: Gateway
      name: <your-gateway-name> # Replace with your Gateway name
  extensionChains:
    - name: datadog-aap-chain
      matchCondition:
        celExpressions:
          - celMatcher: "1 == 1" # Match all traffic
      extensions:
        - name: datadog-aap-extension
          backendRef:
            group: ""
            kind: Service
            name: datadog-aap-extproc-service
            port: 443

          # Required: set the authority for the gRPC call to the extension.
          # Use your application hostname or the security processor Service DNS name.
          authority: "datadog-aap-extproc-service.<your-gateway-namespace>.svc.cluster.local"

          # By default, if the security processor fails or times out, the proxy returns a
          # 5xx error. To prevent this, enable the failOpen setting. When enabled, request
          # processing is stopped on error but the request is not dropped, which keeps the
          # application available.
          failOpen: true

          # Mandatory: Only set the Request and Response Headers events.
          # If body events are selected, the security processor transfers and analyzes
          # the bodies for every request without applying the relevant selection rules.
          # Use the DD_APPSEC_BODY_PARSING_SIZE_LIMIT environment variable on the callout
          # container to enable body processing.
          supportedEvents:
            - RequestHeaders
            - ResponseHeaders

          # Adjust the timeout to match your processing needs (for example, with body processing).
          # Valid range: 10ms to 10s. This is the same option as message_timeout in an Envoy ext_proc configuration.
          timeout: 1s

The Gateway, the GCPTrafficExtension, and the security processor Service referenced by backendRef must all reside in the same namespace. See the GKE Service Extensions restrictions for the full list of constraints on the extension's backend Service.

Validate

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.