Using Key-Vault services from Azure Public cloud:

Introduction: The previous article introduced one aspect of using secrets from Azure public cloud. It showed the use of proxy for secret management to add whitelists to folders specified by path.  With folder specified for different categories and subscriptionIds added to each folder, the whitelisting provided a way to complement the role-based access control. This article introduces another aspect of key-vault via the use of its SecretClient to get access to the resource directly.

Description. While DSMSProxy usage shown earlier provided categories for organizing whitelists based on SubscriptionId, ServiceId and ServiceTreeId, the use of SecretClient is primarily for the purpose of getting and setting secrets in the vault. These secrets can be credentials, passwords, keys, certificates and other forms of identity that can be persisted safely.  A sample of using this client involves the following:

        DefaultAzureCredential credential = new DefaultAzureCredential(

            new DefaultAzureCredentialOptions

            {

                ExcludeEnvironmentCredential = true,

                ExcludeManagedIdentityCredential = true,

            });

 

      SecretClient secretClient = new SecretClient(vaultUri, credential, options);

      KeyVaultSecret sasToken = await secretClient.GetSecretAsync($"{storageAccountName}-{sasDefinitionName}", cancellationToken: s_cancellationTokenSource.Token);

 

Since the secrets can vary, their scope and lifetime can also vary, a new secret can be used for granular purpose as long as the naming convention for the secrets are maintained so it is easy to locate a secret or use the name to know identify the secret and its intended use.