Using KingswaySoft to Secure and Use Secrets from Azure Key Vault

21 December 2023
KingswaySoft Team

Your ETL processes often involve saving sensitive connection information in your SSIS packages in order to make connections or facilitate service calls. Such sensitive information includes user passwords, client secrets, API tokens, etc. Generally speaking, you would want such information to be saved securely. In our SSIS development practice, you can leverage the SSIS package's ProtectionLevel setting to protect such information. When the ETL packages are ready for unattended executions, you would need to deploy the packages to a runtime integration server. Depending on the chosen ProtectionLevel setting, your SSIS deployment might require you to specify the connection details in your job definition for the job to work. If your organization has a high-security standard, you might be asked to store such sensitive information in a central location for better security and centralized management. With that being said, Azure Key Vault by Microsoft can be the perfect solution for such a key storage or repository, it allows you to read and create key secrets in your Azure Key Vault when it is needed for your integration authentication in your SSIS jobs. In a nutshell, the following are some of the benefits when leveraging Azure Key Vault for your ETL connection configuration:

  • A centralized repository for sensitive credentials
  • Lower chances of secrets/keys being leaked
  • Eliminate the need to store such sensitive data within the code level
  • Easy to use and access by authorized users and processes
  • Re-use encrypted connection properties throughout your package or process.

In this blog post, we will explore how KingswaySoft can be used to extract stored secrets from Azure Key Vault and utilize them within a D365 Dataverse/CRM ConnectionString in an SSIS package to establish a successful connection. The components that we will be using for this are as follows:

Azure Key Vault Setup

The first thing to do is to create a Key Vault within Azure. For this, log into https://portal.azure.com using your tenant. From there, search for Key Vaults and click on it. If you do not find it as shown below, click on "More Services" and you should find it there.

Azure portal.png

On this page, click the "+ Create" button to create your own Key Vault, and provide the required information.

CreateKeyVault.png

Once created, open the KeyVault by clicking on the name, and on the tab that opens up, you will find various objects, such as Keys, Secrets, and Certificates. Please note that depending on what type of credential you are trying to store in your Key Vault, you could choose the respective option. In our example, we selected "Secret" in order to store the Client Secret from our D365 CRM registered App for its authentication.

AzureKeyVaultSelectObject.png

On the page that opens up, provide a name, enter the client secret, and fill in the other required and optional fields. The name is what you would need to keep unique if you have multiple secrets for multiple processes, as it should be recognizable to be able to configure it in your SSIS package.

CreateSecretinAzure.png

Design

In your SSIS package, the first step would be to create an Azure Key Vault connection manager. For this, you can enter your authentication details for your Azure instance, as shown below. For information on how to configure the Azure Key Vault connection manager, please refer to our Online Help Manual from here.

AzureKeyVaultCM.png

Then, in the Control Flow, add the Azure Key Vault Task from the SSIS toolbox, then open it, and choose the connection manager. As you can see below, four types of actions are supported in the task. From those, we will be using the "Get Secret" task.

Azure Key Vault Type of actions.png

The remaining actions, "Set Secret," "Delete Secret," and "Purge Secret," are utilized to set or delete secrets within the Key Vault, which are not the focus of this blog post, but they can be useful in some other integration scenarios. After selecting the "Get Secret" action, click on the drop-down for Secret Name and choose the secret that you stored in the Azure Key Vault from the list.

Azure Key Vault Secret Name.png

Once done, this can now be stored as an SSIS variable. Please note that in the list, you will see both variables and project parameters, and you could use either depending on the use case. However, since our case involves setting the secret dynamically at runtime for the connection manager, we choose a variable, as shown below.

Azure Key Vault Output variable.png

With the above, the task will retrieve the secret value from the Azure Key Vault and have it stored in the @[User::ClientSecret] variable during runtime. The next step is to parameterize the D365 CRM connection manager. To achieve this, we work with the ConnectionString and the Client Secret property separately. We have a blog post that provides detailed information on how to parameterize the connection manager; please find the link here. When parameterizing, the same variable @[User::ClientSecret] can be assigned to the ClientSecret property.

CRM Connection manager parameterization.png

Now it is time to finish up the design. The Azure Key Vault Task can be connected in series using precedence constraints to any data flow that uses the D365 CRM components. 

ControlFlow.png

When the package is executed, the Azure Key Vault task will get the secret "mySecret" from the KeyVault and assign it to the variable @[User::ClientSecret] at runtime. This variable is used in the connection parameterization, thereby authenticating the Dataverse/CRM connection manager when it starts its execution. Once the package execution is complete, the variable value will be flushed out, and the secret value is not stored anywhere in the code/design.

Conclusion

By using such a design, you can ensure that your secrets and keys are stored securely and centrally within Azure Key Vault, and won't be leaked without proper authentication. You can also use this to reuse and parameterize connection managers and eliminate the need to store sensitive credentials within the package or your infrastructure.

We hope this has been helpful!


Archive

Tags