Azure-docs: FunctionApp 2.0

[harkiratiiit]

Seems this is not compatible with FunctionApp v2.0. Here, the configuration is read by Microsoft.Extensions.Configuration

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 7feaa3d0-7233-a3cb-cb9b-a9a55b1f0d7a
• Version Independent ID: f41f9d51-52f8-1f45-1043-1344a3b74458
• Content: Key Vault references in App Service and Azure Functions
• Content Source: articles/app-service/app-service-key-vault-references.md
• Service: app-service
• GitHub Login: @mattchenderson
• Microsoft Alias: mahender

[Grace-MacJones-MSFT]

Hi @harkiratiiit, thanks for bringing this to our attention. Your feedback has been shared with the content owner for further review.

[cephalin]

@Grace-MacJones-MSFT Please assign this to @ggailey777

[romankiss]

I am facing the same problem for testing this preview feature:

run.csx:
log.LogInformation($"{Environment.GetEnvironmentVariable("TestKV")}");

logs:
@Microsoft.KeyVault(...)
It looks like the @ prefix doesn't work.

Do I need to add or replace any assembly?

Thanks
Roman

[evusik]

I am facing the same issue with Runtime version: 1.0.12205.0 (~1).
Any ETA for the fix?

[wahyuen]

Perhaps a fundamental question, was this feature meant to be something that developers could use to be able to 'resolve' application settings from code, calling out to KeyVault? Or was it originally intended to be used only at deployment time? Would be good to understand this so that myself (and possibly others) can figure out if this is a suitable feature to be waiting on.

[kennekro]

Got the same problem as romankiss above, where the @ prefix does not seem to work.
Any suggestions for solving this? Using runtime version 1.0.12205.0 (~1).

[mattchenderson]

Almost all of the issues we've seen so far are configuration related. If the app cannot resolve the secret from Key Vault because of an access policy misconfiguration, the raw reference syntax is passed in instead. Please double check your Key Vault Access policies and ensure that your app has the GET permission for secrets. The feature should work for all versions of Azure Functions hosted in Azure. It will not work locally.

[romankiss]

@mattchenderson
Thanks for info:
"_If the app cannot resolve the secret from Key Vault because of an access policy misconfiguration, the raw reference syntax is passed in instead._"

After the following changes, the AF + KV feature is working well:

1. Using a reference string with a _SecretUri_ instead of the _VaultName_/_SecretName_/_SecretVersion_
2. Adding my FunctionApp to the Key vault Access policies
3. Restarting FunctionApp

[evusik]

Thanks tons for the confirmation – I realized that I was granting permissions in the key vault access policies to the AAD service principal instead of the MSI. If you’re planning to introduce some ‘common mistakes’ section in your documentation, please include this 😊

Having fixed that, the Key Vault References now work for me. It’s a great feature, much more convenient compared to getting the secrets in the code using SDKs.

[mattchenderson]

@romankiss So the @Microsoft.KeyVault(VaultName=vaultName;SecretName=secretName;SecretVersion=secretVersion) isn't working for you? I haven't used that as much myself and will follow up with dev. It's possible we have a bug in that path.

For now, I'm going to close the issue since folks seem to have a working solution.

please-close

[romankiss]

@mattchenderson
That's right, this alternative reference way isn't working for me.

[ChrisJr]

Has there been any solution to this issue? I am encountering the same problems even after restarting the app. I am also using the SecretUri string

[Birdman65]

@ChrisJr Are you sure you are using a 2.0 version function to call the secret? I find it easier to use the first form instead of the alternative method.
I had no code changes myself,
Just had to put the SAS token in the key vault in the form of https://mystorageaccountnamehere.blob.core.windows.net/mycontainernamehere?st=2018-12-*****.., Made sure to grant the function rights in the key vault. I always forget this step...
Put the url to the secret in the app settings of the function in the form of
@Microsoft.KeyVault(SecretUri=https://mykeyvaultnamehere.vault.azure.net/secrets/*****)

In the function itself (C# compiled) where I get the secret the code didn't change its just

// Read the application settings values
Uri blobUri = new Uri(Environment.GetEnvironmentVariable("SAS", EnvironmentVariableTarget.Process));

[ChrisJr]

@Birdman65 Yes, I am using v2 of functions. All the steps are there. I gave access, reference using SecretUri.
I tried logging the results in the function and I can see it returns the string entered not the referenced value as I would expect.
EDIT: My bad, I just found that logging purposely intercepts and displays that as to not expose the secret.

[willdaviesdevelops]

@ChrisJr , can you edit your logging issue to include a link to where that's mentioned? Also, what if the Developer intended to log the secret? Or part of the secret? For example, what if the Developer wanted to include data beyond secrets? I'd like to print the first few and the last few characters of an API key. Not terribly sensitive but would like to leverage KeyVault to manage these API keys.

Perhaps, there's a use for specifying something as not secret.