[Question] Secret value format query/issue

[ochadwick-westminster]

Release version

APIOps Toolkit for Azure APIM v5.0.1

Question Details

Apologies if this had already been asked but I could not find it in the closed issues. I'm having some trouble using the environment specific configuration files when it comes to substituting named-value values that are of type secret. I've been through the documentation and believe I am using the format defined, but when the APIM import completes into the target environment, the secret value is being set to the value specified in the configuration file as a literal value.

The named value in the configuration file setup looks like:

...
- name: wcc-mri-soap-services-key
    properties:
      displayName: wcc-mri-soap-services-key
      value: "{#APIM_SECRET__WCC_MRI_SOAP_SERVICES_KEY#}"
...

I've confirmed that the secret is created an an environment secret in Github and have added some logging to the workflow which confirms that value is coming through into the workflow correctly.

Expected behavior

I'm expecting that when the APIM import completes that the named value wcc-mri-soap-services-key has a secret value set to the key held as the secret value in Github.

Actual behavior

The value being put into APIM as the value of the named value is the literal string {#APIM_SECRET__WCC_MRI_SOAP_SERVICES_KEY#}

Reproduction Steps

1. Added the secret named above as an environment secret for the test environment in Github.
2. Added the snippet shown above into the configuration.test.yaml file for the test environment.
3. Run the pipeline to deploy the changes to our test environment.
4. Observed the value of the named value secret created in the test environment.

[guythetechie]

@ochadwick-westminster - this step in your Github workflow should replace the value in the YAML file. Can you confirm whether it runs successfully?

[ochadwick-westminster]

@guythetechie - Thanks for pointing out that step. In our environment we have a dev apim the extraction runs from so the secrets substiution needs to happen on the publish steps for both test and production. I hadn't realised that step was only configured to run on production, I've updated that now and the step is running, thanks for that.

However its now giving an error suggesting the value after the substitution takes place is an empty string.

So the config file for the test environment I have configured looks like before:

- name: wcc-mri-soap-services-key
    properties:
      displayName: wcc-mri-soap-services-key
      value: "{#APIM_SECRET__WCC_MRI_SOAP_SERVICES_KEY#}"

I havent altered anything around the substitution step other than adding my secret to the testSecretValue variable on the step. When this runs in the pipeline the logs look correct. I've also added a step for debug purposes to ouput the actual secret just to make sure its coming through correctly. Both of these are shown below in the execution log:

In addition, i've added a step to ouput the contents of the configuration file after the substitution step has run, and that appears to show the problem where the substituted value is empty:

[guythetechie]

@ochadwick-westminster - I'm not familiar with that replace token action, but looking at their documentation, it seems you have to pass the replacement as an environment variable in the step. Your first screenshot shows env properties for apiops_release_version, Logging__LogLevel__Default, and testSecretValue, but not APIM_SECRET__WCC_MRI_SOAP_SERVICES_KEY. Should probably look like this:

      - name: "Perform namevalue secret substitution in configuration.${{ inputs.API_MANAGEMENT_ENVIRONMENT}}.yaml"
        uses: cschleiden/replace-tokens@v1.1
        with:
          tokenPrefix: "{#"
          tokenSuffix: "#}"
          files: ${{ format('["**/configuration.{0}.yaml"]', inputs.API_MANAGEMENT_ENVIRONMENT) }}
        env:
          APIM_SECRET__WCC_MRI_SOAP_SERVICES_KEY: the replacement value (e.g ${{ secrets.APIM_SECRET__WCC_MRI_SOAP_SERVICES_KEY }})

[ochadwick-westminster]

@guythetechie Have tried that and it looks to be working. Thank you very much for the help.