Faites des tests de charge de points de terminaison sécurisés avec le Test de charge Azure

Dans cet article, vous allez apprendre à utiliser le Test de charge Azure avec des points de terminaison d’application qui nécessitent une authentification. Selon l’implémentation de votre application, vous pouvez utiliser un jeton d’accès, des informations d’identification utilisateur, une identité managée ou des certificats clients pour l’authentification des demandes.

Test de charge Azure prend en charge les options suivantes pour les points de terminaison authentifiés :

• S’authentifier avec un secret partagé ou des informations d’identification d’utilisateur
• S’authentifier avec des certificats client
• S’authentifier avec une identité managée

Conditions préalables

• Un compte Azure avec un abonnement actif. Si vous n’avez pas d’abonnement Azure, créez un compte gratuit avant de commencer.
• Une ressource de test de charge Azure. Pour créer une ressource de test de charge, consultez Créer et exécuter un test de charge.

S’authentifier avec un secret partagé ou des informations d’identification

Dans ce scénario, le point de terminaison d’application nécessite que vous utilisiez un secret partagé, tel qu’un jeton d’accès, une clé API ou des informations d’identification utilisateur pour vous authentifier.

Le diagramme suivant montre comment utiliser des secrets partagés ou des informations d’identification pour s’authentifier auprès d’un point de terminaison d’application dans votre test de charge.

Le flux d’authentification avec un secret partagé ou des informations d’identification d’utilisateur est :

1. Stockez en toute sécurité le secret ou les informations d’identification, par exemple dans Azure Key Vault ou dans le magasin de secrets CI/CD.
2. Référencez le secret dans la configuration du test de charge.
3. Pour les tests basés sur JMeter, récupérez la valeur secrète avec la GetSecret fonction. Pour des tests basés sur Locust, récupérez le secret avec la fonction getenv. Transmettez la valeur secrète à la requête d’application.

Stocker le secret en toute sécurité

Pour éviter de stocker et de divulguer des informations de sécurité dans le script de test, vous pouvez stocker en toute sécurité les secrets dans Azure Key Vault ou dans le magasin de secrets CI/CD.

Vous pouvez ajouter les informations de sécurité dans un magasin de secrets de deux façons :

• Ajoutez les informations du secret dans Azure Key Vault. Suivez les étapes décrites dans Paramétriser des tests de charge avec des secrets pour stocker un secret et autoriser votre ressource de test de charge à lire sa valeur.

• Ajoutez les informations du secret en tant que secret dans CI/CD (secrets GitHub Actions ou variables secrètes Azure Pipelines).

Référencer le secret dans la configuration du test de charge

Avant de pouvoir récupérer la valeur du secret dans le script de test JMeter, vous devez référencer le secret dans la configuration du test de charge.

- name: 'Azure Load Testing'
    uses: azure/load-testing@v1
    with:
    loadtestConfigFile: 'SampleApp.yaml'
    loadtestResource: 'MyTest'
    resourceGroup: 'loadtests-rg'
    secrets: |
        [
            {
            "name": "appToken",
            "value": "${{ secrets.APP_TOKEN }}"
            }
        ]

- task: AzureLoadTest@1
    inputs:
    azureSubscription: 'MyAzureLoadTestingRG'
    loadTestConfigFile: 'SampleApp.yaml'
    loadTestResource: 'MyTest'
    resourceGroup: 'loadtests-rg'
    secrets: |
        [
            {
            "name": "appToken",
            "value": "$(appToken)"
            }
        ]

Récupérer et utiliser la valeur secrète dans le script JMeter

Vous pouvez maintenant récupérer la valeur secrète dans le script JMeter à l’aide de la fonction personnalisée GetSecret et la transmettre à la demande d’application. Par exemple, utilisez un en-tête HTTP Authorization pour transmettre un jeton OAuth à une requête.

1. Vous commencez par créer une variable définie par l’utilisateur qui récupère la valeur du secret avec la fonction personnalisée GetSecret :

   La fonction GetSecret extrait la valeur d’Azure Key Vault ou du magasin de secrets CI/CD.

   

2. Mettez à jour le composant échantillonneur JMeter pour transmettre le secret dans la requête.

   Par exemple, pour fournir un jeton d’accès OAuth2, vous configurez l’en-tête HTTP Authorization en ajoutant un HTTP Header Manager :

   

Récupérer et utiliser la valeur secrète dans le script Locust

Vous pouvez maintenant récupérer la valeur secrète dans le script Locust et la transmettre à la demande d’application. Par exemple, utilisez un en-tête HTTP Authorization pour transmettre un jeton OAuth à une requête.

Les secrets configurés dans la configuration du test de charge sont accessibles en tant que variables d’environnement.

1. Initialisez une variable avec la valeur secrète à l’aide du nom du secret spécifié dans la configuration du test de charge.

my_secret = os.getenv("appToken")

1. Référencez la variable dans votre script de test pour utiliser la valeur secrète stockée dans Azure KeyVault.

S’authentifier avec des certificats client

Dans ce scénario, le point de terminaison d’application nécessite que vous utilisiez un certificat client pour vous authentifier. Le Test de charge Azure prend en charge le type de certificats de certificat à clé publique Standard #12 (PKCS12). Vous pouvez également utiliser plusieurs certificats clients dans un test de charge.

Le diagramme suivant montre comment utiliser un certificat client pour s’authentifier auprès d’un point de terminaison d’application dans votre test de charge.

Le flux d’authentification avec des certificats clients est le suivant :

1. Stockez en toute sécurité le certificat client dans Azure Key Vault.
2. Référencez le certificat dans la configuration du test de charge.
3. Pour les tests JMeter, Azure Load Testing transmet de manière transparente le certificat à toutes les applications. Pour les tests basés sur Locust, vous pouvez récupérer le certificat dans votre script de test et le transmettre aux requêtes.

Stocker le certificat client dans Azure Key Vault

Pour éviter de stocker et de divulguer, le certificat client en même temps que le script JMeter, vous stockez le certificat dans Azure Key Vault.

Suivez les étapes décrites dans Importer un certificat pour stocker votre certificat dans Azure Key Vault.

Accorder l’accès à votre coffre de clés Azure

Lorsque vous stockez des secrets ou des certificats de test de charge dans Azure Key Vault, votre ressource de test de charge utilise une identité managée pour accéder au coffre de clés. Une fois l’identité de gestion configurée, vous devez accorder à l’identité managée de votre ressource de test de charge l’autorisation de lire ces valeurs à partir du coffre de clés.

Pour accorder à votre ressource de test de charge Azure les autorisations nécessaires pour lire des secrets ou des certificats à partir de votre coffre de clés Azure :

1. Dans le portail Azure, accédez à votre ressource Azure Key Vault.

   Si vous n’avez pas encore de coffre de clés, suivez les instructions du démarrage rapide Azure Key Vault pour en créer un.

2. Dans le volet de gauche, sélectionnez Stratégies d’accès, puis + Créer.

3. Dans l’onglet Autorisations, sous Autorisations du secret, sélectionnez Obtenir, puis sélectionnez Suivant.

   Remarque

   Le Test de charge Azure récupère les certificats en tant que secret pour vous assurer que la clé privée du certificat est disponible.

4. Sous l’onglet Principal, trouvez et sélectionnez l’identité managée de la ressource de test de charge, puis sélectionnez Suivant.

   Si vous utilisez une identité managée affectée par le système, le nom de l’identité managée correspond à celui de votre ressource de test de charge Azure.

5. Cliquez à nouveau sur Suivant.

   Lorsque votre test s’exécute, l’identité managée associée à votre ressource de test de charge peut désormais lire les secrets ou certificats de votre test de charge à partir de votre coffre de clés.

Référencer le certificat dans la configuration du test de charge

Pour passer le certificat client aux demandes d’application, vous devez référencer le certificat dans la configuration du test de charge.

certificates:
    - name: <my-certificate-name>
      value: <my-keyvault-secret-ID>

certificates:
    - name: <my-certificate-name>
      value: <my-keyvault-secret-ID>

Lorsque vous exécutez votre test de charge, le Test de charge Azure récupère le certificat client à partir d’Azure Key Vault et l’injecte automatiquement dans chaque requête web JMeter.

Pour les tests Locust, vous pouvez récupérer le certificat et l’utiliser dans votre script de test. Les certificats configurés dans la configuration de test de charge sont disponibles dans le ALT_CERTIFICATES_DIR.

cert_dir = os.getenv("ALT_CERTIFICATES_DIR")
cert_file = open(os.path.join(cert_dir), "cert_name_in_keyvault.pfx")

Authentifier avec une identité managée

Dans ce scénario, le point de terminaison de l’application nécessite que vous utilisiez une identité managée pour vous authentifier. Vous pouvez utiliser des identités gérées attribuées par le système et par l'utilisateur.

Le flux d’authentification à l’aide d’une identité managée est le suivant :

1. Affectez l’identité managée que le point de terminaison cible identifie à la ressource Azure Load Testing.
2. Sélectionnez l’identité managée dans la configuration du test de charge.

Vous devez configurer votre script de tests de charge pour extraire le jeton d’accès à l’aide de l’identité managée et utiliser le jeton pour authentifier les demandes auprès du point de terminaison cible. Par exemple, vous pouvez obtenir un jeton via un appel REST HTTP au point de terminaison IMDS (Azure Instance Metadata Service), puis transmettre le jeton à une requête à l’aide de l’en-tête Authorization HTTP.

Attribuer l’identité managée

Attribuez l’identité managée qui a l’accès requis au point de terminaison cible à votre ressource Azure Load Testing. Lorsque vous exécutez le test, Azure Load Testing affecte cette identité aux instances du moteur. Cela garantit que vos demandes d’extraction de jetons d’accès à l’aide de l’identité managée réussissent.

Vous pouvez utiliser une identité managée affectée par le système ou une identité managée affectée par l’utilisateur,

• Pour utiliser une identité managée affectée par le système, attribuez d’abord une identité managée affectée par le système à votre ressource Azure Load Testing. Une fois activée, fournissez les autorisations RBAC requises pour cette identité sur le point de terminaison cible.

• Pour utiliser une identité managée affectée par l’utilisateur, attribuez d’abord l’identité affectée par l’utilisateur à votre ressource Azure Load Testing. Si cette identité n’a pas les autorisations RBAC requises sur le point de terminaison cible, fournissez les autorisations requises. Si votre script de test utilise plusieurs identités affectées par l’utilisateur, affectez les identités multiples à votre ressource et assurez-vous qu’elles disposent des autorisations RBAC requises.

Sélectionner l’identité managée dans la configuration du test de charge

Sélectionnez l’identité managée requise lorsque vous créez ou modifiez un test dans Azure Load Testing.

- name: 'Azure Load Testing'
    uses: azure/load-testing@v1
    with:
    loadtestConfigFile: 'SampleApp.yaml'
    loadtestResource: 'MyTest'
    resourceGroup: 'loadtests-rg'
    referenceIdentities:
        - kind: "Engine"
          type: "user-assigned"
          identity: /subscriptions/abcdef01-2345-6789-0abc-def012345678/resourceGroups/sample-rg/providers/Microsoft.ManagedIdentity/userAssignedIdentities/sample-identity

- task: AzureLoadTest@1
    inputs:
    azureSubscription: 'MyAzureLoadTestingRG'
    loadTestConfigFile: 'SampleApp.yaml'
    loadTestResource: 'MyTest'
    resourceGroup: 'loadtests-rg'
    referenceIdentities:
        - kind: "Engine"
          type: "user-assigned"
          identity: /subscriptions/abcdef01-2345-6789-0abc-def012345678/resourceGroups/sample-rg/providers/Microsoft.ManagedIdentity/userAssignedIdentities/sample-identity

Contenu connexe

• Découvrez comment paramétriser un test de charge.

• En savoir plus sur l’utilisation de plusieurs certificats dans un test de charge.