App Configuration - Key Vault Integration update

[my3sons]

Hello @mssfang and @mrm9084

I see that there have been some recent updates to the app configuration source code to expand on the App Configuration/Key Vault integration, as it looks like that rather than just returning the secret URI from App Configuration, there is an implementation to return the actual secret value (see below). If this is the case, do you know when there might be a preview version available we can play with?

public KeyVaultSecret getSecret(URI secretIdentifier, int timeout) {
    if (secretClient == null) {
        build();
    }
    String[] tokens = secretIdentifier.getPath().split("/");

    String name = (tokens.length >= 3 ? tokens[2] : null);
    String version = (tokens.length >= 4 ? tokens[3] : null);
    return secretClient.getSecret(name, version).block(Duration.ofSeconds(timeout));
}

[mrm9084]

@my3sons I don't think there is a plan for that as it is just a hook into the Key Vault Secrets library. Do you have a link to where you saw the reference? It might just be a sample as that is the main use case.

[my3sons]

Hello @mrm9084

I am referring to this class here: https://github.com/Azure/azure-sdk-for-java/blob/master/sdk/appconfiguration/azure-spring-cloud-appconfiguration-config/src/main/java/com/azure/spring/cloud/config/stores/KeyVaultClient.java

I guess my thought is that this capability (getting Key Vault Secret directly from App configuration client) should be there by default. Currently, if you implement your com.azure.data.appconfiguration.ConfigurationClient and ask it to return a ConfigurationSetting that references a KeyVault secret, the ConfigurationClient returns the URI of the secret, and not the actual secret value. The KeyVault API does not even support getting a secret value based on URI, but only secret name. Therefore, we now are left with creating a KeyVault client, parsing the response we got back from ConfigurationClient to get the secret name from the URI and then make another API call to get the actual secret value. Ideally, the ConfigurationClient should do all of that for us and based on the KeyVaultClient class referenced in my link above, it looks like you folks are going that direction, unless I am missing something.

[mrm9084]

Hi @my3sons that library is for Spring Boot/Spring Cloud users. It takes a user provided credential and accesses Key Vault with it to return the Secret. App Configuration will never have access to users secrets stored in Key Vault. The method used here is the intended way for this operation to happen.

[mrm9084]

If you use the latest version of the SDK will parse the information for you in the next minor release, which is in beta right now. https://github.com/Azure/azure-sdk-for-java/blob/master/sdk/appconfiguration/azure-data-appconfiguration/CHANGELOG.md#120-beta1-2021-04-09. It is expected that the client makes a second request for key vault secrets.

[my3sons]

Hello @mrm9084

Yea, the longer back story to all this is that we do have a number of Spring Boot App Services that we have implemented using App Configuration and for the most part using the pattern depicted here: https://docs.microsoft.com/en-us/azure/azure-app-configuration/quickstart-java-spring-app. For these apps, other than our Configuration Properties class, we had to implement almost zero code to leverage App Configuration for both standard key/value pairs, as well as KeyVault referenced properties/settings. It all works great!

We recently have deployed a few Spring Boot apps to our Vnets. The problem we are now facing (and one that we have faced before with KeyVault) is that the Azure Java SDKs use the reactor netty implementation under the hood, and the http client that netty is using does not honor the default DNS nameresolver (and instead uses Google DNS), and we have firewall rules on our Vnet that deny that, so the Azure ConfigurationClient fails because it cannot resolve the hostname for our App Configuration endpoint, see this link for more details: https://docs.microsoft.com/en-us/answers/questions/307797/azure-key-vault-uri-dns-name-resolver-exception.html

Given that there does not seem to be a way via configuration to change the DNS resolver associated to the http client, we seem to be forced into implementing the ConfigurationClient the old-fashioned way using the Azure SDK and doing something like the below. So now that we rolling our own ConfigurationClient, we end up back where this started and how do we best deal with KeyVault based configuration settings. I will check out the link you provided above to see how this might simplify things for us, thanks!

   reactor.netty.http.client.HttpClient nettyHttpClient =
            reactor.netty.http.client.HttpClient.create()
                    .resolver(DefaultAddressResolverGroup.INSTANCE);

    HttpClient httpClient= new NettyAsyncHttpClientBuilder(nettyHttpClient).build();


    DefaultAzureCredential tokenCredential = new DefaultAzureCredentialBuilder().build();
    final ConfigurationClient client = new ConfigurationClientBuilder()
            .credential(tokenCredential) // use Managed Identity
            .httpClient(httpClient)
            .endpoint("myConfigEndpoint")
            .buildClient();

[mrm9084]

@my3sons Sorry, I thought you were using just the SDK. We have seen the issue you are having before. I think this is what you are looking for https://github.com/Azure/azure-sdk-for-java/tree/master/sdk/appconfiguration/azure-spring-cloud-starter-appconfiguration-config#client-builder-customization

[my3sons]

Thanks @mrm9084, will check this out!

[mrm9084]

@my3sons did this solve your issue?

[ghost]

Hi, we're sending this friendly reminder because we haven't heard back from you in a while. We need more information about this issue to help address it. Please be sure to give us your input within the next 7 days. If we don't hear back from you within 14 days of this comment the issue will be automatically closed. Thank you!