Activer ASM pour la surveillance sans serveur

AWS Lambda
Google Cloud Run
Azure App Service

Consultez les exigences de compatibilité afin d’en savoir plus sur les fonctionnalités ASM disponibles pour les fonctions sans serveur.

AWS Lambda

La configuration d’ASM pour AWS Lambda s’effectue en plusieurs étapes :

  1. Vous devez identifier les fonctions qui sont vulnérables ou ciblées par des attaques, et qui bénéficieraient le plus de la solution ASM. Pour trouver ces fonctions, consultez l’onglet Security du catalogue des services.
  2. Vous devez configurer l’instrumentation ASM à l’aide de l’interface de ligne de commande Datadog, d’AWS CDK, du plug-in Serverless Framework Datadog ou d’une configuration manuelle (utilisation des couches de tracing Datadog).
  3. Vous devez déclencher des signaux de sécurité dans votre application et vérifier comment Datadog affiche les informations générées.

Prérequis

  • Le tracing APM sans serveur est configuré sur la fonction Lambda, afin d’envoyer directement des traces à Datadog. Le tracing via X-Ray n’est pas suffisant pour ASM : le tracing APM doit également être activé.

Prise en main

    Le plug-in Serverless Framework Datadog vous permet de configurer et de déployer automatiquement votre fonction Lambda avec ASM.

    Pour installer et configurer le plug-in Serverless Framework Datadog, procédez comme suit :

    1. Installez le plug-in Serverless Framework Datadog :

      serverless plugin install --name serverless-plugin-datadog

    2. Ajouter le paramètre de configuration enableASM dans votre fichier serverless.yml pour activer ASM :

      custom:
  datadog:
    enableASM: true

      Votre nouveau fichier serverless.yml doit au moins contenir ce qui suit :

      custom:
  datadog:
    apiKeySecretArn: "{Datadog_API_Key_Secret_ARN}" # or apiKey
    enableDDTracing: true
    enableASM: true

      Consultez également la liste complète des paramètres de plug-in pour finaliser la configuration des paramètres de votre fonction Lambda.

    3. Redéployez la fonction et invoquez-la. Après quelques minutes, elle apparaît dans les vues ASM.

    L’interface de ligne de commande Datadog permet de modifier les configurations de fonctions Lambda existantes pour instrumenter vos applications sans les redéployer. Il s’agit du moyen le plus rapide de tirer parti de la surveillance sans serveur de Datadog.

    Si vous configurez le tracing initial de vos fonctions, suivez les étapes ci-dessous :

    1. Installez le client de l’interface de ligne de commande Datadog :

      npm install -g @datadog/datadog-ci

    2. Si vous commencez tout juste à utiliser la surveillance sans serveur Datadog, lancez l’interface de ligne de commande Datadog en mode interactif pour procéder rapidement à la première installation. Vous pouvez ignorer les autres étapes. Pour installer définitivement Datadog pour vos applications de production, ignorez cette étape et suivez les autres étapes afin d’exécuter la commande de l’interface de ligne de commande Datadog dans vos pipelines de CI/CD après un déploiement normal.

      datadog-ci lambda instrument -i --appsec

    3. Configurez les identifiants AWS :

      L’interface de ligne de commande Datadog nécessite un accès au service AWS Lambda et dépend du SDK JavaScript AWS pour résoudre les identifiants. Assurez-vous de configurer vos identifiants AWS à l’aide de la même méthode que celle utilisée lors de l’appel de l’interface de ligne de commande AWS.

    4. Configurez le site Datadog :

      export DATADOG_SITE="<DATADOG_SITE>"

      Remplacez <DATADOG_SITE> par (assurez-vous que le site Datadog sélectionné sur la droite de cette page est correct).

    5. Configurez la clé d’API Datadog :

      Datadog vous recommande d’enregistrer la clé d’API Datadog dans AWS Secrets Manager pour garantir sa sécurité. La clé doit être stockée sous forme de chaîne de texte brut (et non en tant que blob JSON). Assurez-vous que vos fonctions Lambda disposent de l’autorisation IAM secretsmanager:GetSecretValue requise.

      export DATADOG_API_KEY_SECRET_ARN="<DATADOG_API_KEY_SECRET_ARN>"

      Pour pouvoir effectuer des tests rapides, il est également possible de définir la clé d’API Datadog sous forme de texte brut :

      export DATADOG_API_KEY="<DATADOG_API_KEY>"

    6. Instrumentez vos fonctions Lambda :

      Pour instrumenter vos fonctions Lambda, exécutez la commande suivante.

      datadog-ci lambda instrument --appsec -f <functionname> -f <another_functionname> -r <aws_region> -v 91 -e 55

      Renseignez les paramètres fictifs comme suit :

      • Remplacez <nomfonction> et <autre_nomfonction> par les noms de vos fonctions Lambda.
      • Sinon, vous pouvez utiliser --functions-regex pour instrumenter automatiquement plusieurs fonctions dont le nom correspond à l’expression régulière fournie.
      • Remplacez <aws_region> par le nom de la région AWS.

      Remarque : instrumentez d’abord vos fonctions Lambda dans un environnement de développement ou intermédiaire. Si les résultats de l’instrumentation ne vous conviennent pas, exécutez uninstrument avec les mêmes arguments pour annuler les modifications.

      Pour obtenir des paramètres supplémentaires, consultez la documentation relative à l’interface de ligne de commande.

    La bibliothèque CDK Construct Datadog installe automatiquement Datadog sur vos fonctions à l’aide des couches Lambda. De plus, elle configure vos fonctions afin qu’elles envoient des métriques, traces et logs à Datadog via l’extension Lambda Datadog.

    1. Installez la bibliothèque CDK Construct Datadog :

      # For AWS CDK v1
pip install datadog-cdk-constructs

# For AWS CDK v2
pip install datadog-cdk-constructs-v2

    2. Instrumenter vos fonctions Lambda

      # For AWS CDK v1
from datadog_cdk_constructs import Datadog
# NOT SUPPORTED IN V1

# For AWS CDK v2
from datadog_cdk_constructs_v2 import Datadog

datadog = Datadog(self, "Datadog",
    python_layer_version=91,
    extension_layer_version=55,
    site="<DATADOG_SITE>",
    api_key_secret_arn="<DATADOG_API_KEY_SECRET_ARN>", // or api_key
    enable_asm=True,
  )
datadog.add_lambda_functions([<LAMBDA_FUNCTIONS>])

      Renseignez les paramètres fictifs comme suit :

      • Remplacez <SITE_DATADOG> par (assurez-vous que le SITE sélectionné à droite est correct).
      • Remplacez <DATADOG_API_KEY_SECRET_ARN> par l’ARN du secret AWS où votre clé d’API Datadog est stockée en toute sécurité. La clé doit être stockée sous forme de chaîne de texte brut (et non en tant que blob JSON). L’autorisation secretsmanager:GetSecretValue est requise. Pour effectuer un test rapide, vous pouvez utiliser apiKey et définir la clé d’API Datadog sous forme de texte brut.

      Pour obtenir plus de détails ainsi que des paramètres supplémentaires, consultez la documentation relative à la bibliothèque CDK Datadog.

    1. Installez le traceur Datadog :

      • Python

        # Use this format for x86-based Lambda deployed in AWS commercial regions
   arn:aws:lambda:<AWS_REGION>:464622532012:layer:Datadog-<RUNTIME>:91

   # Use this format for arm64-based Lambda deployed in AWS commercial regions
   arn:aws:lambda:<AWS_REGION>:464622532012:layer:Datadog-<RUNTIME>-ARM:91

   # Use this format for x86-based Lambda deployed in AWS GovCloud regions
   arn:aws-us-gov:lambda:<AWS_REGION>:002406178527:layer:Datadog-<RUNTIME>:91

   # Use this format for arm64-based Lambda deployed in AWS GovCloud regions
   arn:aws-us-gov:lambda:<AWS_REGION>:002406178527:layer:Datadog-<RUNTIME>-ARM:72
   ```
   Remplacez `<AWS_REGION>` par une région AWS valide, comme `us-east-1`. Les options disponibles pour `RUNTIME` sont `Python37`, `Python38` et `Python39`.

      • Node

        # Use this format for AWS commercial regions
  arn:aws:lambda:<AWS_REGION>:464622532012:layer:Datadog-<RUNTIME>:108

  # Use this format for AWS GovCloud regions
  arn:aws-us-gov:lambda:<AWS_REGION>:002406178527:layer:Datadog-<RUNTIME>:108
  ```
  Remplacez `<AWS_REGION>` par une région AWS valide, comme `us-east-1`. Voici la liste des options disponibles pour RUNTIME : `Node16-x`, `Node18-x`, `Node20-x`.

      • Java : Configurez les couches pour votre fonction Lambda à l’aide de l’ARN en respectant l’un des formats suivants, en fonction de l’endroit où votre fonction Lambda est déployée. Remplacez <AWS_REGION> par une région AWS valide telle que us-east-1 :

        # In AWS commercial regions
arn:aws:lambda:<AWS_REGION>:464622532012:layer:dd-trace-java:14
# In AWS GovCloud regions
arn:aws-us-gov:lambda:<AWS_REGION>:002406178527:layer:dd-trace-java:14

      • Go : le traceur Go ne fait appel à aucune couche et fonctionne comme un module Go standard. Vous pouvez installer la dernière version avec la commande suivante :

        go get -u github.com/DataDog/datadog-lambda-go

      • .NET : Configurez les couches pour votre fonction Lambda à l’aide de l’ARN en respectant l’un des formats suivants, en fonction de l’endroit où votre fonction Lambda est déployée. Remplacez <AWS_REGION> par une région AWS valide telle que us-east-1 :

        # x86-based Lambda in AWS commercial regions
arn:aws:lambda:<AWS_REGION>:464622532012:layer:dd-trace-dotnet:15
# arm64-based Lambda in AWS commercial regions
arn:aws:lambda:<AWS_REGION>:464622532012:layer:dd-trace-dotnet-ARM:15
# x86-based Lambda in AWS GovCloud regions
arn:aws-us-gov:lambda:<AWS_REGION>:002406178527:layer:dd-trace-dotnet:15
# arm64-based Lambda  in AWS GovCloud regions
arn:aws-us-gov:lambda:<AWS_REGION>:002406178527:layer:dd-trace-dotnet-ARM:15
    2. Installez l’extension Lambda Datadog en configurant les couches pour votre fonction Lambda à l’aide de l’ARN, en respectant l’un des formats suivants. Remplacez <AWS_REGION> par une région AWS valide telle que us-east-1 :
      # x86-based Lambda in AWS commercial regions
arn:aws:lambda:<AWS_REGION>:464622532012:layer:Datadog-Extension:55
# arm64-based Lambda in AWS commercial regions
arn:aws:lambda:<AWS_REGION>:464622532012:layer:Datadog-Extension-ARM:55
# x86-based Lambda in AWS GovCloud regions
arn:aws-us-gov:lambda:<AWS_REGION>:002406178527:layer:Datadog-Extension:55
# arm64-based Lambda in AWS GovCloud regions
arn:aws-us-gov:lambda:<AWS_REGION>:002406178527:layer:Datadog-Extension-ARM:55

    1. Installez le traceur Datadog :
      • Python
        # Use this format for x86-based Lambda deployed in AWS commercial regions
   arn:aws:lambda:<AWS_REGION>:464622532012:layer:Datadog-<RUNTIME>:91

   # Use this format for arm64-based Lambda deployed in AWS commercial regions
   arn:aws:lambda:<AWS_REGION>:464622532012:layer:Datadog-<RUNTIME>-ARM:91

   # Use this format for x86-based Lambda deployed in AWS GovCloud regions
   arn:aws-us-gov:lambda:<AWS_REGION>:002406178527:layer:Datadog-<RUNTIME>:91

   # Use this format for arm64-based Lambda deployed in AWS GovCloud regions
   arn:aws-us-gov:lambda:<AWS_REGION>:002406178527:layer:Datadog-<RUNTIME>-ARM:91
   ```
   Remplacez `<AWS_REGION>` par une région AWS valide, comme `us-east-1`. Voici la liste des options disponibles pour `RUNTIME` : `Python38`, `Python39`, `Python310`, `Python311`, `Python312`.

    .

    • Node

      # Use this format for AWS commercial regions
  arn:aws:lambda:<AWS_REGION>:464622532012:layer:Datadog-<RUNTIME>:108

  # Use this format for AWS GovCloud regions
  arn:aws-us-gov:lambda:<AWS_REGION>:002406178527:layer:Datadog-<RUNTIME>:108
  ```
  Remplacez `<AWS_REGION>` par une région AWS valide, comme `us-east-1`. Voici la liste des options disponibles pour RUNTIME : `Node16-x`, `Node18-x`, `Node20-x`.

    • Java : Configurez les couches pour votre fonction Lambda à l’aide de l’ARN en respectant l’un des formats suivants, en fonction de l’endroit où votre fonction Lambda est déployée. Remplacez <AWS_REGION> par une région AWS valide telle que us-east-1 :

      # In AWS commercial regions
arn:aws:lambda:<AWS_REGION>:417141415827:layer:dd-trace-java:14
# In AWS GovCloud regions
arn:aws-us-gov:lambda:<AWS_REGION>:002406178527:layer:dd-trace-java:14

    • Go : le traceur Go ne fait appel à aucune couche et fonctionne comme un module Go standard. Vous pouvez installer la dernière version avec la commande suivante :

      go get -u github.com/DataDog/datadog-lambda-go

    • .NET : Configurez les couches pour votre fonction Lambda à l’aide de l’ARN en respectant l’un des formats suivants, en fonction de l’endroit où votre fonction Lambda est déployée. Remplacez <AWS_REGION> par une région AWS valide telle que us-east-1 :

      # x86-based Lambda in AWS commercial regions
arn:aws:lambda:<AWS_REGION>:417141415827:layer:dd-trace-dotnet:15
# arm64-based Lambda in AWS commercial regions
arn:aws:lambda:<AWS_REGION>:417141415827:layer:dd-trace-dotnet-ARM:15
# x86-based Lambda in AWS GovCloud regions
arn:aws-us-gov:lambda:<AWS_REGION>:002406178527:layer:dd-trace-dotnet:15
# arm64-based Lambda  in AWS GovCloud regions
arn:aws-us-gov:lambda:<AWS_REGION>:002406178527:layer:dd-trace-dotnet-ARM:15

    1. Installez l’extension Lambda Datadog en configurant les couches pour votre fonction Lambda à l’aide de l’ARN, en respectant l’un des formats suivants. Remplacez <AWS_REGION> par une région AWS valide telle que us-east-1 :

      # x86-based Lambda in AWS commercial regions
arn:aws:lambda:<AWS_REGION>:417141415827:layer:Datadog-Extension:55
# arm64-based Lambda in AWS commercial regions
arn:aws:lambda:<AWS_REGION>:417141415827:layer:Datadog-Extension-ARM:55
# x86-based Lambda in AWS GovCloud regions
arn:aws-us-gov:lambda:<AWS_REGION>:002406178527:layer:Datadog-Extension:55
# arm64-based Lambda in AWS GovCloud regions
arn:aws-us-gov:lambda:<AWS_REGION>:002406178527:layer:Datadog-Extension-ARM:55

    1. Activez ASM en ajoutant les variables d’environnement suivantes sur le déploiement de votre fonction :

      environment:
  AWS_LAMBDA_EXEC_WRAPPER: /opt/datadog_wrapper
  DD_SERVERLESS_APPSEC_ENABLED: true

    2. Pour les fonctions Node et Python uniquement, vérifiez bien que le gestionnaire de la fonction est correctement défini :

      • Node : définissez le gestionnaire de votre fonction sur /opt/nodejs/node_modules/datadog-lambda-js/handler.handler.
        • Définissez également la variable d’environnement DD_LAMBDA_HANDLER sur votre gestionnaire d’origine, comme myfunc.handler.
      • Python : définissez le gestionnaire de votre fonction sur datadog_lambda.handler.handler.
        • Définissez également la variable d’environnement DD_LAMBDA_HANDLER sur votre gestionnaire d’origine, comme myfunc.handler.

    3. Redéployez la fonction et invoquez-la. Après quelques minutes, elle apparaît dans les vues ASM.

    Envoi - Powershell

    La prise en charge de Google Cloud par ASM est disponible en version bêta.

    Fonctionnement de serverless-init

    L’application serverless-init utilise un wrapper pour incorporer votre processus et l’exécute en tant que sous-processus. Elle initie un écouteur DogStatsD pour les métriques ainsi qu’un écouteur d’Agent de trace pour les traces. Elle recueille les logs en utilisant un wrapper pour incorporer les flux stdout/stderr de votre application. Une fois le bootstrap terminé, serverless-init exécute votre commande en tant que sous-processus.

    Pour bénéficier d’une instrumentation complète, assurez-vous d’appeler datadog-init dans la première commande exécutée au sein de votre conteneur Docker. Pour ce faire, définissez-la comme point d’entrée ou comme premier argument dans CMD.

    Prise en main

      Ajoutez les instructions et arguments suivants à votre Dockerfile.

      COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
COPY --from=datadog/dd-lib-js-init /operator-build/node_modules /dd_tracer/node/
ENV DD_SERVICE=datadog-demo-run-nodejs
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1
ENV DD_APPSEC_ENABLED=1
ENTRYPOINT ["/app/datadog-init"]
CMD ["/nodejs/bin/node", "/chemin/vers/votre/application.js"]

      Explication

      1. Copiez serverless-init Datadog et collez-le dans votre image Docker.

        COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init

      2. Copiez le traceur Node.JS Datadog et collez-le dans votre image Docker.

        COPY --from=datadog/dd-lib-js-init /operator-build/node_modules /dd_tracer/node/

        Si vous installez directement la bibliothèque de traceur Datadog dans votre application, comme indiqué dans les instructions relatives à l’instrumentation de traceur manuelle, ignorez cette étape.

      3. (Facultatif) Ajoutez des tags Datadog.

        ENV DD_SERVICE=datadog-demo-run-nodejs
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1
ENV DD_APPSEC_ENABLED=1

      4. Modifiez le point d’entrée afin d’intégrer votre application au processus serverless-init Datadog à l’aide d’un wrapper. Remarque : si un point d’entrée est déjà défini au sein de votre Dockerfile, consultez la section [Autre configuration possible)(#alt-node).

        ENTRYPOINT ["/app/datadog-init"]

      5. Exécutez votre application binaire incorporée au sein du point d’entrée. Adaptez cette ligne en fonction de vos besoins.

        CMD ["/nodejs/bin/node", "/path/to/your/app.js"]

      Autre configuration possible

      Si un point d’entrée est déjà défini au sein de votre Dockerfile, vous avez également la possibilité de modifier l’argument CMD.

      COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
COPY --from=datadog/dd-lib-js-init /operator-build/node_modules /dd_tracer/node/
ENV DD_SERVICE=datadog-demo-run-nodejs
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1
ENV DD_APPSEC_ENABLED=1
CMD ["/app/datadog-init", "/nodejs/bin/node", "/chemin/vers/votre/application.js"]

      Si vous souhaitez que votre point d’entrée soit également instrumenté, vous pouvez intervertir votre point d’entrée et vos arguments CMD. Pour en savoir plus, consultez la section Fonctionnement de serverless-init.

      COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
COPY --from=datadog/dd-lib-js-init /operator-build/node_modules /dd_tracer/node/
ENV DD_SERVICE=datadog-demo-run-nodejs
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1
ENV DD_APPSEC_ENABLED=1
ENTRYPOINT ["/app/datadog-init"]
CMD ["/your_entrypoint.sh", "/nodejs/bin/node", "/chemin/vers/votre/application.js"]

      Tant que votre commande à exécuter est transmise à datadog-init en tant qu’argument, vous obtiendrez une instrumentation complète.

      Ajoutez les instructions et arguments suivants à votre Dockerfile.

      COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
RUN pip install --target /dd_tracer/python/ ddtrace
ENV DD_SERVICE=datadog-demo-run-python
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1
ENV DD_APPSEC_ENABLED=1
ENTRYPOINT ["/app/datadog-init"]
CMD ["/dd_tracer/python/bin/ddtrace-run", "python", "app.py"]

      Explication

      1. Copiez serverless-init Datadog et collez-le dans votre image Docker.

        COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init

      2. Installez le traceur Python Datadog.

        RUN pip install --target /dd_tracer/python/ ddtrace

        Si vous installez directement la bibliothèque de traceur Datadog dans votre application, comme indiqué dans les instructions relatives à l’instrumentation de traceur manuelle, ignorez cette étape.

      3. (Facultatif) Ajoutez des tags Datadog.

        ENV DD_SERVICE=datadog-demo-run-python
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1
ENV DD_APPSEC_ENABLED=1

      4. Modifiez le point d’entrée afin d’intégrer votre application au processus serverless-init Datadog à l’aide d’un wrapper. Remarque : si un point d’entrée est déjà défini au sein de votre Dockerfile, consultez la section [Autre configuration possible)(#alt-python).

        ENTRYPOINT ["/app/datadog-init"]

      5. Exécutez votre application binaire incorporée au sein du point d’entrée et lancée par la bibliothèque de traceur Datadog. Adaptez cette ligne en fonction de vos besoins.

        CMD ["/dd_tracer/python/bin/ddtrace-run", "python", "app.py"]

      Autre configuration possible

      Si un point d’entrée est déjà défini au sein de votre Dockerfile, vous avez également la possibilité de modifier l’argument CMD.

      COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
RUN pip install --target /dd_tracer/python/ ddtrace
ENV DD_SERVICE=datadog-demo-run-python
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1
ENV DD_APPSEC_ENABLED=1
CMD ["/app/datadog-init", "/dd_tracer/python/bin/ddtrace-run", "python", "app.py"]

      Si vous souhaitez que votre point d’entrée soit également instrumenté, vous pouvez intervertir votre point d’entrée et vos arguments CMD. Pour en savoir plus, consultez la section Fonctionnement de serverless-init.

      COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
RUN pip install --target /dd_tracer/python/ ddtrace
ENV DD_SERVICE=datadog-demo-run-python
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1
ENV DD_APPSEC_ENABLED=1
ENTRYPOINT ["/app/datadog-init"]
CMD ["your_entrypoint.sh", "/dd_tracer/python/bin/ddtrace-run", "python", "app.py"]

      Tant que votre commande à exécuter est transmise à datadog-init en tant qu’argument, vous obtiendrez une instrumentation complète.

      Ajoutez les instructions et arguments suivants à votre Dockerfile.

      COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
ADD 'https://dtdg.co/latest-java-tracer' /dd_tracer/java/dd-java-agent.jar
ENV DD_SERVICE=datadog-demo-run-java
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1
ENV DD_APPSEC_ENABLED=1
ENTRYPOINT ["/app/datadog-init"]
CMD ["./mvnw", "spring-boot:run"]

      Explication

      1. Copiez serverless-init Datadog et collez-le dans votre image Docker.

        COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init

      2. Ajoutez le traceur Java Datadog à votre image Docker.

        ADD 'https://dtdg.co/latest-java-tracer' /dd_tracer/java/dd-java-agent.jar

        Si vous installez directement la bibliothèque de traceur Datadog dans votre application, comme indiqué dans les instructions relatives à l’instrumentation de traceur manuelle, ignorez cette étape.

      3. (Facultatif) Ajoutez des tags Datadog.

        ENV DD_SERVICE=datadog-demo-run-java
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1
ENV DD_APPSEC_ENABLED=1

      4. Modifiez le point d’entrée afin d’intégrer votre application au processus serverless-init Datadog à l’aide d’un wrapper. Remarque : si un point d’entrée est déjà défini au sein de votre Dockerfile, consultez la section [Autre configuration possible)(#alt-java).

        ENTRYPOINT ["/app/datadog-init"]

      5. Exécutez votre application binaire incorporée au sein du point d’entrée. Adaptez cette ligne en fonction de vos besoins.

        CMD ["./mvnw", "spring-boot:run"]

      Autre configuration possible

      Si un point d’entrée est déjà défini au sein de votre Dockerfile, vous avez également la possibilité de modifier l’argument CMD.

      COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
ADD 'https://dtdg.co/latest-java-tracer' /dd_tracer/java/dd-java-agent.jar
ENV DD_SERVICE=datadog-demo-run-java
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1
ENV DD_APPSEC_ENABLED=1
CMD ["/app/datadog-init", "./mvnw", "spring-boot:run"]

      Si vous souhaitez que votre point d’entrée soit également instrumenté, vous pouvez intervertir votre point d’entrée et vos arguments CMD. Pour en savoir plus, consultez la section Fonctionnement de serverless-init.

      COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
ADD 'https://dtdg.co/latest-java-tracer' /dd_tracer/java/dd-java-agent.jar
ENV DD_SERVICE=datadog-demo-run-java
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1
ENV DD_APPSEC_ENABLED=1
ENTRYPOINT ["/app/datadog-init"]
CMD ["your_entrypoint.sh", "./mvnw", "spring-boot:run"]

      Tant que votre commande à exécuter est transmise à datadog-init en tant qu’argument, vous obtiendrez une instrumentation complète.

      Effectuez une installation manuelle du traceur Go avant de déployer votre application. Compilez votre binaire Go en prenant soin d’activer le tag appsec (go build --tags "appsec" ...). Ajoutez les instructions et arguments suivants à votre Dockerfile.

      COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
ENTRYPOINT ["/app/datadog-init"]
ENV DD_SERVICE=datadog-demo-run-go
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1
ENV DD_APPSEC_ENABLED=1

      Explication

      1. Copiez serverless-init Datadog et collez-le dans votre image Docker.

        COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init

      2. Modifiez le point d’entrée afin d’intégrer votre application au processus serverless-init Datadog à l’aide d’un wrapper. Remarque : si un point d’entrée est déjà défini au sein de votre Dockerfile, consultez la section [Autre configuration possible)(#alt-go).

        ENTRYPOINT ["/app/datadog-init"]

      3. (Facultatif) Ajoutez des tags Datadog.

        ENV DD_SERVICE=datadog-demo-run-go
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1
ENV DD_APPSEC_ENABLED=1

      4. Exécutez votre application binaire incorporée au sein du point d’entrée. Adaptez cette ligne en fonction de vos besoins.

        CMD ["/path/to/your-go-binary"]

      Autre configuration possible

      Si un point d’entrée est déjà défini au sein de votre Dockerfile, vous avez également la possibilité de modifier l’argument CMD.

      COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
ENV DD_SERVICE=datadog-demo-run-go
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1
ENV DD_APPSEC_ENABLED=1
CMD ["/app/datadog-init", "/chemin/vers/votre-binaire-go"]

      Si vous souhaitez que votre point d’entrée soit également instrumenté, vous pouvez intervertir votre point d’entrée et vos arguments CMD. Pour en savoir plus, consultez la section Fonctionnement de serverless-init.

      COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
ENV DD_SERVICE=datadog-demo-run-go
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1
ENV DD_APPSEC_ENABLED=1
ENTRYPOINT ["/app/datadog-init"]
CMD ["your_entrypoint.sh", "/chemin/vers/votre-binaire-go"]

      Tant que votre commande à exécuter est transmise à datadog-init en tant qu’argument, vous obtiendrez une instrumentation complète.

      Ajoutez les instructions et arguments suivants à votre Dockerfile.

      COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
COPY --from=datadog/dd-lib-dotnet-init /datadog-init/monitoring-home/ /dd_tracer/dotnet/
ENV DD_SERVICE=datadog-demo-run-dotnet
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1
ENV DD_APPSEC_ENABLED=1
ENTRYPOINT ["/app/datadog-init"]
CMD ["dotnet", "helloworld.dll"]

      Explication

      1. Copiez serverless-init Datadog et collez-le dans votre image Docker.

        COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init

      2. Copiez le traceur .NET Datadog et collez-le dans votre image Docker.

        COPY --from=datadog/dd-lib-dotnet-init /datadog-init/monitoring-home/ /dd_tracer/dotnet/

        Si vous installez directement la bibliothèque de traceur Datadog dans votre application, comme indiqué dans les instructions relatives à l’instrumentation de traceur manuelle, ignorez cette étape.

      3. (Facultatif) Ajoutez des tags Datadog.

        ENV DD_SERVICE=datadog-demo-run-dotnet
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1
ENV DD_APPSEC_ENABLED=1

      4. Modifiez le point d’entrée afin d’intégrer votre application au processus serverless-init Datadog à l’aide d’un wrapper. Remarque : si un point d’entrée est déjà défini au sein de votre Dockerfile, consultez la section [Autre configuration possible)(#alt-dotnet).

        ENTRYPOINT ["/app/datadog-init"]

      5. Exécutez votre application binaire incorporée au sein du point d’entrée. Adaptez cette ligne en fonction de vos besoins.

        CMD ["dotnet", "helloworld.dll"]

      Autre configuration possible

      Si un point d’entrée est déjà défini au sein de votre Dockerfile, vous avez également la possibilité de modifier l’argument CMD.

      COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
COPY --from=datadog/dd-lib-dotnet-init /datadog-init/monitoring-home/ /dd_tracer/dotnet/
ENV DD_SERVICE=datadog-demo-run-dotnet
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1
ENV DD_APPSEC_ENABLED=1
CMD ["/app/datadog-init", "dotnet", "helloworld.dll"]

      Si vous souhaitez que votre point d’entrée soit également instrumenté, vous pouvez intervertir votre point d’entrée et vos arguments CMD. Pour en savoir plus, consultez la section Fonctionnement de serverless-init.

      COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
COPY --from=datadog/dd-lib-dotnet-init /datadog-init/monitoring-home/ /dd_tracer/dotnet/
ENV DD_SERVICE=datadog-demo-run-dotnet
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1
ENV DD_APPSEC_ENABLED=1
ENTRYPOINT ["/app/datadog-init"]
CMD ["your_entrypoint.sh", "dotnet", "helloworld.dll"]

      Tant que votre commande à exécuter est transmise à datadog-init en tant qu’argument, vous obtiendrez une instrumentation complète.

      Effectuez une installation manuelle du traceur Ruby avant de déployer votre application. Consultez l’exemple d’application.

      Ajoutez les instructions et arguments suivants à votre Dockerfile.

      COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
ENV DD_SERVICE=datadog-demo-run-ruby
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1
ENV DD_APPSEC_ENABLED=1
ENV DD_TRACE_PROPAGATION_STYLE=datadog
ENTRYPOINT ["/app/datadog-init"]
CMD ["rails", "server", "-b", "0.0.0.0"]

      Explication

      1. Copiez serverless-init Datadog et collez-le dans votre image Docker.

        COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init

      2. (Facultatif) Ajoutez des tags Datadog.

        ENV DD_SERVICE=datadog-demo-run-ruby
ENV DD_ENV=datadog-demo
ENV DD_APPSEC_ENABLED=1
ENV DD_VERSION=1

      3. Cette variable d’environnement est requise pour le bon fonctionnement de la propagation des traces dans Cloud Run. Pensez à bien définir cette variable pour tous les services en aval instrumentés par Datadog.

        ENV DD_TRACE_PROPAGATION_STYLE=datadog

      4. Modifiez le point d’entrée afin d’intégrer votre application au processus serverless-init Datadog à l’aide d’un wrapper. Remarque : si un point d’entrée est déjà défini au sein de votre Dockerfile, consultez la section [Autre configuration possible)(#alt-ruby).

        ENTRYPOINT ["/app/datadog-init"]

      5. Exécutez votre application binaire incorporée au sein du point d’entrée. Adaptez cette ligne en fonction de vos besoins.

        CMD ["rails", "server", "-b", "0.0.0.0"]

      Autre configuration possible

      Si un point d’entrée est déjà défini au sein de votre Dockerfile, vous avez également la possibilité de modifier l’argument CMD.

      COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
ENV DD_SERVICE=datadog-demo-run-ruby
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1
ENV DD_APPSEC_ENABLED=1
ENV DD_TRACE_PROPAGATION_STYLE=datadog
CMD ["/app/datadog-init", "rails", "server", "-b", "0.0.0.0"]

      Si vous souhaitez que votre point d’entrée soit également instrumenté, vous pouvez intervertir votre point d’entrée et vos arguments CMD. Pour en savoir plus, consultez la section Fonctionnement de serverless-init.

      COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
ENV DD_SERVICE=datadog-demo-run-ruby
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1
ENV DD_APPSEC_ENABLED=1
ENV DD_TRACE_PROPAGATION_STYLE=datadog
ENTRYPOINT ["/app/datadog-init"]
CMD ["your_entrypoint.sh", "rails", "server", "-b", "0.0.0.0"]

      Tant que votre commande à exécuter est transmise à datadog-init en tant qu’argument, vous obtiendrez une instrumentation complète.

      Ajoutez les instructions et arguments suivants à votre Dockerfile.

      COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
ADD https://github.com/DataDog/dd-trace-php/releases/latest/download/datadog-setup.php /datadog-setup.php
RUN php /datadog-setup.php --php-bin=all
ENV DD_SERVICE=datadog-demo-run-php
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1
ENTRYPOINT ["/app/datadog-init"]

# utiliser la commande suivante pour une image basée sur Apache et sur mod_php
RUN sed -i "s/Listen 80/Listen 8080/" /etc/apache2/ports.conf
EXPOSE 8080
CMD ["apache2-foreground"]

# utiliser la commande suivante pour une image basée sur Nginx et sur php-fpm
RUN ln -sf /dev/stdout /var/log/nginx/access.log && ln -sf /dev/stderr /var/log/nginx/error.log
EXPOSE 8080
CMD php-fpm; nginx -g daemon off;

      Remarque : le point d’entrée datadog-init intègre votre processus à l’aide d’un wrapper et recueille les logs à partir de celui-ci. Pour garantir le bon fonctionnement des logs, assurez-vous que vos processus Apache, Nginx ou PHP écrivent le résultat vers stdout.

      Explication

      1. Copiez serverless-init Datadog et collez-le dans votre image Docker.

        COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init

      2. Copiez et installez le traceur PHP Datadog.

        ADD https://github.com/DataDog/dd-trace-php/releases/latest/download/datadog-setup.php /datadog-setup.php
RUN php /datadog-setup.php --php-bin=all

        Si vous installez directement la bibliothèque de traceur Datadog dans votre application, comme indiqué dans les instructions relatives à l’instrumentation de traceur manuelle, ignorez cette étape.

      3. (Facultatif) Ajoutez des tags Datadog.

        ENV DD_SERVICE=datadog-demo-run-php
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1

      4. Modifiez le point d’entrée afin d’intégrer votre application au processus serverless-init Datadog à l’aide d’un wrapper. Remarque : si un point d’entrée est déjà défini au sein de votre Dockerfile, consultez la section [Autre configuration possible)(#alt-php).

        ENTRYPOINT ["/app/datadog-init"]

      5. Exécutez votre application.

        Utilisez la commande suivante pour une image basée sur Apache et mod_php :

        RUN sed -i "s/Listen 80/Listen 8080/" /etc/apache2/ports.conf
EXPOSE 8080
CMD ["apache2-foreground"]

        Utilisez la commande suivante pour une image basée sur Nginx et php-fpm :

        RUN ln -sf /dev/stdout /var/log/nginx/access.log && ln -sf /dev/stderr /var/log/nginx/error.log
EXPOSE 8080
CMD php-fpm; nginx -g daemon off;

      Autre configuration possible

      Si un point d’entrée est déjà défini au sein de votre Dockerfile et que vous utilisez une image basée sur Apache et mod_php, vous avez également la possibilité de modifier l’argument CMD.

      COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
ADD https://github.com/DataDog/dd-trace-php/releases/latest/download/datadog-setup.php /datadog-setup.php
RUN php /datadog-setup.php --php-bin=all
ENV DD_SERVICE=datadog-demo-run-php
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1
RUN sed -i "s/Listen 80/Listen 8080/" /etc/apache2/ports.conf
EXPOSE 8080
CMD ["/app/datadog-init", "apache2-foreground"]

      Si vous souhaitez que votre point d’entrée soit également instrumenté, vous pouvez intervertir votre point d’entrée et vos arguments CMD. Pour en savoir plus, consultez la section Fonctionnement de serverless-init.

      COPY --from=datadog/serverless-init:1 /datadog-init /app/datadog-init
ADD https://github.com/DataDog/dd-trace-php/releases/latest/download/datadog-setup.php /datadog-setup.php
RUN php /datadog-setup.php --php-bin=all
ENV DD_SERVICE=datadog-demo-run-php
ENV DD_ENV=datadog-demo
ENV DD_VERSION=1
ENTRYPOINT ["/app/datadog-init"]

# utiliser la commande suivante pour une image basée sur Apache et mod_php
RUN sed -i "s/Listen 80/Listen 8080/" /etc/apache2/ports.conf
EXPOSE 8080
CMD ["your_entrypoint.sh", "apache2-foreground"]

# utiliser la commande suivante pour une image basée sur Nginx et php-fpm
RUN ln -sf /dev/stdout /var/log/nginx/access.log && ln -sf /dev/stderr /var/log/nginx/error.log
EXPOSE 8080
CMD your_entrypoint.sh php-fpm; your_entrypoint.sh nginx -g daemon off;

      Tant que votre commande à exécuter est transmise à datadog-init en tant qu’argument, vous obtiendrez une instrumentation complète.

      Azure App Service

      Configuration

      Définir les paramètres de votre application

      Pour activer ASM sur votre application, commencez par ajouter les paires key/value suivantes sous la section Applications Settings des paramètres de votre configuration Azure.

      Configuration d'Azure App Service : la zone Application Settings est affichée, sous la section Configuration des paramètres de l'interface Azure. Trois paramètres sont indiqués : DD_API_KEY, DD_SERVICE et DD_START_APP.
      • DD_API_KEY correspond à votre clé d’API Datadog.
      • DD_CUSTOM_METRICS_ENABLED permet d’activer les métriques custom (facultatif).
      • DD_SITE correspond au paramètre du site Datadog. Votre site est . Par défaut, ce paramètre a pour valeur datadoghq.com.
      • DD_SERVICE correspond au nom du service utilisé pour ce programme. Par défaut, sa valeur correspond à celle du champ name dans package.json.
      • DD_START_APP correspond à la commande utilisée pour lancer votre application. Exemple : node ./bin/www (inutile pour les applications exécutées dans Tomcat).
      • La valeur de DD_APPSEC_ENABLED doit être définie sur 1, afin d’activer ASM.

      Identifier votre commande de lancement

      Pour les applications Azure App Service Web Linux qui ont été développées à l’aide de l’option de déploiement de code sur des runtimes intégrés, la commande permettant de lancer l’application dépend du langage. Les valeurs par défaut sont fournies dans la documentation Azure. Vous trouverez ci-dessous plusieurs exemples.

      Définissez les valeurs ci-dessous dans la variable d’environnement DD_START_APP. Les exemples ci-dessous s’appliquent à l’application datadog-demo, le cas échéant.

      RuntimeExemple de valeur DD_START_APPDescription
      .NETnode ./bin/wwwExécute le fichier de configuration Node PM2 ou votre fichier de script.
      .NET Coredotnet datadog-demo.dllExécute un fichier .dll qui reprend le nom de votre application Web par défaut.

      Remarque : le nom du fichier .dll indiqué dans la commande doit correspondre au nom de votre fichier .dll. Dans certaines situations, ce nom est différent de celui de votre application Web;
      PHPcp /home/site/wwwroot/default /etc/nginx/sites-available/default && service nginx reloadCopie le secret à l’emplacement pertinent et lance l’application.
      Collecte d’erreurs du navigateurgunicorn --bind=0.0.0.0 --timeout 600 quickstartproject.wsgiScript de lancement personnalisé. Cet exemple repose sur une commande Gunicorn permettant de lancer une application Django.
      Javajava -jar /home/site/wwwroot/datadog-demo.jarLa commande permettant de lancer votre application. Elle n’est pas requise pour les applications exécutées dans Tomcat.

      Remarque : lorsque de nouveaux paramètres sont enregistrés, l’application redémarre.

      Définir des paramètres généraux

        Accédez à General settings, puis ajoutez ce qui suit dans le champ Startup Command :

        curl -s https://raw.githubusercontent.com/DataDog/datadog-aas-linux/v1.4.0/datadog_wrapper | bash
        Configuration Azure App Service : les paramètres relatifs à la pile, sous la section Configuration des paramètres dans l'interface Azure. En dessous des paramètres liés à la pile, à la version majeure et à la version mineure se trouve un champ Startup Command qui a pour valeur la commande curl indiquée ci-dessus.

        Téléchargez le fichier datadog_wrapper depuis la page des versions, puis importez-le dans votre application à l’aide de la commande suivante dans l’interface de ligne de commande Azure :

          az webapp deploy --resource-group <nom_groupe> --name <nom_application> --src-path <chemin-vers-wrapper-datadog> --type=startup

        Tester la détection des menaces

        Pour voir la détection des menaces Application Security Management en action, envoyez des patterns d’attaque connus sur votre application. Par exemple, envoyez un en-tête HTTP avec la valeur acunetix-product pour déclencher une tentative d’attaque par analyse des vulnérabilités :

        curl -H 'My-ASM-Test-Header: acunetix-product' https://url-de-votre-fonction/route-existante

        Quelques minutes après avoir activé votre application et envoyé les patterns d’attaque, des informations sur les menaces s’affichent dans l’Application Signals Explorer.

        La page des détails des signaux de sécurité, avec des tags, des métriques, des suggestions d'étapes à suivre, ainsi que les adresses IP malveillantes associées à une menace.

        Pour aller plus loin

        Documentation, liens et articles supplémentaires utiles:

        Fonctionnement d'Application SecurityDOCUMENTATION more more Règles Application Security Management prêtes à l'emploiDOCUMENTATION more more Dépannage d'Application Security ManagementDOCUMENTATION more more Application Threat ManagementDOCUMENTATION more more