Enabling App and API Protection for Envoy Gateway
This product is not supported for your selected
Datadog site. (
).
このページは日本語には対応しておりません。随時翻訳に取り組んでいます。
翻訳に関してご質問やご意見ございましたら、
お気軽にご連絡ください。
App and API Protection for Envoy Gateway is in Preview
App and API Protection for Envoy Gateway is in Preview. Use the following instructions to try the preview.
You can enable Datadog App and API Protection for traffic managed by Envoy Gateway. The Datadog Envoy Gateway integration allows Datadog to inspect and protect your traffic for threat detection and blocking directly at the edge of your infrastructure.
Prerequisites
- A running Kubernetes cluster with Envoy Gateway 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 to allow 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
To enable App and API Protection with Envoy Gateway, do the following:
- Deploying the Datadog External Processor service in your cluster.
- Configure an
EnvoyExtensionPolicy that points to the processor service. This will direct traffic from your Envoy Gateway 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 analyzed 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 Envoy Gateway.
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 Gateway
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:v2.4.0 # Replace with the latest released 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"
# Disable TLS for communication between Envoy Gateway and the external processor. Default is true.
# By default, the external processor configuration used by Envoy Gateway is configured to not use TLS.
# You can enable TLS and configure it with DD_SERVICE_EXTENSION_TLS_KEY_FILE and DD_SERVICE_EXTENSION_TLS_CERT_FILE
# and apply a BackendTLSPolicy on the Datadog External Processor Service.
- name: DD_SERVICE_EXTENSION_TLS
value: "false"
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 EnvoyExtensionPolicy configuration
namespace: <your-preferred-namespace> # Change to your preferred namespace, ensure it's resolvable by the Envoy Gateway
labels:
app: datadog-aap-extproc
spec:
ports:
- name: grpc
port: 443
targetPort: grpc
protocol: TCP
selector:
app: datadog-aap-extproc
type: ClusterIP
Configuration options for the External Processor
The Datadog External Processor exposes some 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_SERVICE_EXTENSION_TLS | true | Enable the gRPC TLS layer. |
DD_SERVICE_EXTENSION_TLS_KEY_FILE | localhost.key | Change the default gRPC TLS layer key. |
DD_SERVICE_EXTENSION_TLS_CERT_FILE | localhost.crt | Change the default gRPC TLS layer certificate. |
DD_APPSEC_BODY_PARSING_SIZE_LIMIT | 10485760 | Maximum size of the bodies to be processed in bytes. If set to 0, the bodies are not processed. The recommended value is 10485760 (10MB). (To fully enable body processing, the allowModeOverride option should also be set in the External Processing filter configuration.) |
DD_SERVICE | serviceextensions | Service name shown in the Datadog UI. |
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. |
The External 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.
Note: As the Datadog External 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.2.2). 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.
Use an EnvoyExtensionPolicy to instruct Envoy Gateway to call the Datadog external processor. You can attach the policy to a Gateway or to specific HTTPRoute/GRPCRoute resources.
This sends all traffic on the selected Gateway to the external processor. Here is an example manifest (datadog-aap-extproc-eep.yaml):
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: EnvoyExtensionPolicy
metadata:
name: datadog-aap-extproc-eep
namespace: <your-preferred-namespace> # same namespace as the Gateway
spec:
targetRefs:
# Target the entire Gateway
- group: gateway.networking.k8s.io
kind: Gateway
name: <your-gateway-name> # update to your specific gateway name
# Target specific HTTPRoutes/GRPCRoutes
#- group: gateway.networking.k8s.io
# kind: HTTPRoute
# name: <your-http-route-name>
extProc:
- backendRefs:
- group: ""
kind: Service
name: datadog-aap-extproc-service
namespace: <your-preferred-namespace> # namespace of the external processor Service
port: 443
# Optional: Enable fail open mode. Default is false.
# Normally, if the external processor fails or times out, the filter fails and Envoy
# returns a 5xx error to the downstream client. Setting this to true allows requests
# to continue without error if a failure occurs.
failOpen: true
# Optional: Set a timeout by processing message. Default is 200ms.
# There is a maxium of 2 messages per requests with headers only and 4 messages maximum
# with body processing enabled.
# Note: This timeout also includes the data communication between Envoy and the external processor.
# The timeout should be adjusted to accommodate the additional possible processing time.
# Larger payloads will require a longer timeout.
messageTimeout: 200ms
processingMode:
# The external processor can dynamically override the processing mode as needed, instructing
# Envoy to forward request and response bodies to the external processor.
allowModeOverride: true
# Only enable the request and response header modes by default.
request: {}
response: {}
Cross‑namespace reference
If your external processor Service is in a different namespace than the policy, add a ReferenceGrant in the processor’s namespace. For example, you can do this with a manifest such as datadog-aap-eep-rg.yaml.
apiVersion: gateway.networking.k8s.io/v1beta1
kind: ReferenceGrant
metadata:
name: datadog-aap-eep-rg
namespace: <your-extproc-namespace> # namespace of the external processor Service
spec:
from:
- group: gateway.envoyproxy.io
kind: EnvoyExtensionPolicy
namespace: <your-policy-namespace> # namespace of the EnvoyExtensionPolicy (and the Gateway)
to:
- group: ""
kind: Service
name: datadog-aap-extproc-service
Validation
After applying the policy, traffic through the targeted Gateway/Routes is inspected by App and API Protection.
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.
Limitations
The Envoy Gateway integration has the following limitations:
- Observability mode (asynchronous analysis) is not available for Envoy Gateway.
For additional details on the Envoy Gateway integration compatibilities, refer to the Envoy Gateway integration compatibility page.
Further Reading