A Free Alternative to Azure Key Vault for Non-Azure Clouds

Storing connection strings securely is important to protect your applications, especially when working with cloud services like Azure SQL Server.

Below, we’ll show examples of how to use Azure Key Vault to store connection strings, an open-source alternative called Infisical (which supports self-hosting), and examples of using appsettings.json and secrets.json.

Using Azure Key Vault to Store Connection Strings

Azure Key Vault is a cloud service that allows you to securely store and manage sensitive information like connection strings, keys, and certificates. In the Azure portal, create a new Key Vault. Once it’s created, add a connection string to the Key Vault using the command:

Code to retrieve the connection string:

Advantages:

• Centralized management of secrets.

• High level of security with integration into Azure Active Directory.

Disadvantages:

• Tied to the Azure ecosystem, which can be more expensive and complex for smaller projects.

Open-Source Alternative Infisical

Infisical is an open-source platform that allows you to securely manage secrets and configuration data for your applications. It provides similar functionality to commercial solutions like Azure Key Vault, but with a focus on openness and simplicity.

One key feature of Infisical is the option for self-hosting, which allows you to deploy and manage your own instances without relying on cloud providers.

Infisical offers a self-hosting option, allowing you to run Infisical on your own infrastructure. This is useful for organizations that want full control over their data and security settings.

Learn more about self-hosting here: Infisical Self-Hosting.

Example of using Infisical in C#

First, install the Infisical SDK for C# using the NuGet package.

After installation, you can retrieve the connection string from Infisical directly in your application.

Replace <YourInfisicalToken> with your actual access token.

Advantages of Infisical:

• Open-source and free to use.

• Self-hosting allows full control over your data.

• Supports multiple environments (dev, staging, prod).

• Easy integration with CI/CD tools and applications through the SDK.

Disadvantages of Infisical:

• Less known compared to Azure Key Vault, so it may require more research and adaptation.

• Not directly integrated with cloud providers like Azure or AWS.

Using appsettings.json and secrets.json

appsettings.json is a file commonly used to store configuration data in .NET applications, including connection strings. While it's convenient to use this file for configuration, storing sensitive data like connection strings in appsettings.json has significant security risks.

Why it’s not good to use appsettings.json for connection strings:

• Data exposure: appsettings.json is often stored in the repository along with the code, meaning anyone with access to the repository can see the connection strings and other sensitive data.

• Lack of encryption: Data in appsettings.json is stored in plain text, making it easily accessible if the server is compromised.

secrets.json is an alternative for development environments. This file is stored outside the source code and is not included in the repository, reducing the risk of exposure.

Advantages of secrets.json:

• Isolates secrets: Secrets are stored outside the source code, reducing the risk of exposure.

• Easy integration with local development environments.

Disadvantages of secrets.json:

• Only for development environments: secrets.json is not intended for production environments, where more robust security measures are needed.

For the end

When it comes to securely storing connection strings, it’s best to avoid storing sensitive data in appsettings.json due to the risk of exposure. Instead, consider using Azure Key Vault or open-source solutions like Infisical for centralized and secure secret management.

Infisical offers additional flexibility with its self-hosting option, allowing you full control over your data. For development environments, secrets.json provides a good way to isolate secrets outside the source code, but it’s not suitable for production.

Depending on your specific needs, choose the solution that best balances security and ease of management.