Azure Load Testing Framework dynamic secret handling & local configuration

Question

Azure Load Testing Framework dynamic secret handling & local configuration

Andre Ostermeier 0

Hello,

in the last 4 weeks I have made myself familiar with Azure Load Testing and I am currently facing two issues where I would like to find a better solution for.

The scenario I have is 100 Devices doing a load test against and IoTHub endpoint. Each Device has its own secret, that is required to establish the connection. Azure Load Testing allows to ingest secrets from Key Vault via configuration. Is there any way to dynamically access those ingested secrets. The docs only show the static access unfortunately.

User's image

Is there a way to access appToken1, appToken2 ... in JMeter without creating one explicit User Defined Variable per Device? I would like to avoid having a 1:1 mapping in JMeter as this would require 100 User Defined Variables.

Before uploading the JMeter file to Azure Load Testing I usually have to change some User Defined Variables so it can deal with the different runtime environment. Giving one explicit example. I have created a custom Java plugin and in my Test Plan configuration I have a different path locally than on Azure Load Testing. But it would be great to dynamically recognize the runtime environment. Is there any parameter that allows my to identify I am running on Azure Load Testing? Another example connects quite will to bullet number 1. For local testing I want to use a User Defined Variable with a hard coded appToken here:

User's image

And before uploading it to Azure Load Testing I have to remember to change it back so it works in this environment. Any nifty way to make this dynamic?

Thank you so much,

Andre

Marilee Turscak-MSFT 37,181 Reputation points Microsoft Employee

2023-08-17T22:11:52.71+00:00

@Andre Ostermeier Like you mentioned, I don't believe that there is an example of this in the documentation. There might be a way to customize via Azure CLI, similar to this example: https://stackoverflow.com/questions/63341573/dynamic-access-to-key-vault-secret-variab
Marilee Turscak-MSFT 37,181 Reputation points Microsoft Employee

2023-08-17T22:12:19.4166667+00:00

Which document were you referencing for your current solution?
Andre Ostermeier 0 Reputation points

2023-08-18T08:30:20.9833333+00:00

@Marilee Turscak-MSFT I overcame the secret topic now by just creating a multiline JSON in Azure Key Vault that contains the secrets for all my devices. Thus I only need to ingest one secret in the Azure Load Testing configuration and have dynamic access in JMeter. I guess thats the best solution for my use case. I had seen the stackoverflow link you have shared, but from my opinion it will always create a long list of secrets independent where you ingest them.
Andre Ostermeier 0 Reputation points

2023-08-18T08:39:32.3066667+00:00

@Marilee Turscak-MSFT The second question is still unanswered I'd say. But maybe I did not express myself clearly. As depicted underneath this is the JMeter variable how it must be set up before uploading the file to Azure Load Testing.

But this doesn't work locally as the GetSecret() function is not supported. For local development I need to override the value with the real secret and then change it back to the original value before I upload it again. You can forget it then you have redo this again. And if you have like 10 of those secrets you always have to change 10 variables so it is time consuming & error prone. Is there any recommendation how to create the JMeter script in a way that it is running both locally and on Azure Load Testing with a minimum of changes required?

That's why I proposed to maybe introduce a function that allows me to identify if the script is executed in Azure Load Testing then I could at least do some scripting and proper variable assignment before my script runs.

Thanks.

Your answer

Marilee Turscak-MSFT 37,181 Reputation points Microsoft Employee

2023-08-17T22:11:52.71+00:00

@Andre Ostermeier Like you mentioned, I don't believe that there is an example of this in the documentation. There might be a way to customize via Azure CLI, similar to this example: https://stackoverflow.com/questions/63341573/dynamic-access-to-key-vault-secret-variab
Marilee Turscak-MSFT 37,181 Reputation points Microsoft Employee

2023-08-17T22:12:19.4166667+00:00

Which document were you referencing for your current solution?
Andre Ostermeier 0 Reputation points

2023-08-18T08:30:20.9833333+00:00

@Marilee Turscak-MSFT I overcame the secret topic now by just creating a multiline JSON in Azure Key Vault that contains the secrets for all my devices. Thus I only need to ingest one secret in the Azure Load Testing configuration and have dynamic access in JMeter. I guess thats the best solution for my use case. I had seen the stackoverflow link you have shared, but from my opinion it will always create a long list of secrets independent where you ingest them.
Andre Ostermeier 0 Reputation points

2023-08-18T08:39:32.3066667+00:00

@Marilee Turscak-MSFT The second question is still unanswered I'd say. But maybe I did not express myself clearly. As depicted underneath this is the JMeter variable how it must be set up before uploading the file to Azure Load Testing.

But this doesn't work locally as the GetSecret() function is not supported. For local development I need to override the value with the real secret and then change it back to the original value before I upload it again. You can forget it then you have redo this again. And if you have like 10 of those secrets you always have to change 10 variables so it is time consuming & error prone. Is there any recommendation how to create the JMeter script in a way that it is running both locally and on Azure Load Testing with a minimum of changes required?

That's why I proposed to maybe introduce a function that allows me to identify if the script is executed in Azure Load Testing then I could at least do some scripting and proper variable assignment before my script runs.

Thanks.

Share via

Azure Load Testing Framework dynamic secret handling & local configuration

Your answer