Keeping Connection Strings Safe in .NET Apps with Azure Key Vault

Most .NET developers reach for the web.config or appsettings.json file the moment they need to point a SqlConnection somewhere, and honestly, that habit is hard to shake. It works, it is familiar, and it survives a redeploy without complaint. The trouble starts the moment the file leaves your laptop. Connection strings, SAS tokens and API keys get pasted into source control, dropped into chat windows, or copied into deployment pipelines that nobody reviews properly. In a small team this might feel harmless, but it is exactly the kind of slow leak that auditors flag and attackers love.

Azure Key Vault offers a cleaner home for these strings. Instead of scattering secrets across every environment file, you store them once in a vault, control access with policies and identities, and let your .NET application fetch what it needs at runtime. For teams working from Sydney, Melbourne or a Brisbane office, this also aligns nicely with Australian data sovereignty expectations and the local regulatory landscape, which we will get to shortly.

There is a fair dinkum shift happening in how we treat configuration. The old model treated secrets as code; the new model treats them as data that lives outside the binary. Once you make that mental switch, the tooling around Azure Key Vault stops looking like overkill and starts looking like the obvious choice. If you want to see how this approach is being discussed by Australian developers in person, the C# Corner Conference is a good place to start.

Why connection strings deserve better than appsettings.json

The appsettings.json file is brilliant for non-sensitive configuration. Logging levels, feature flags, pagination defaults — all fair game. Connection strings are a different beast. They often contain usernames, sometimes inline passwords, and frequently grant far more access than the calling code actually needs. Putting a production database credential into a file that gets bundled into a container image means anyone with read access to that image can read the credential.

Beyond the accidental leak, there is a versioning problem. Every change to a connection string becomes a code change, which means a pull request, a code review, and a deployment. That is fine when you tweak a development setting once a quarter, but it slows you down when security asks you to rotate a database password tomorrow morning. Keeping the string in Key Vault separates the cadence of code changes from the cadence of credential changes, and that separation is where the real productivity gain lives.

A quick comparison helps frame the trade-offs. Here is how the two approaches stack up for typical .NET scenarios.

The last row matters more in Australia than in many other markets. The Australian Prudential Regulation Authority's CPS 234 standard expects financial organisations to keep tight control over information assets, and storing production database strings in a JSON file checked into Git is a finding waiting to happen.

Spinning up a vault in an Australian region

Before your application can read anything, you need a vault. The portal makes this painless, but a few choices deserve a thought. Region selection is the first. If your application and database live in Australia East or Australia Southeast, put the vault in the same region. Latency stays low, and you sidestep cross-border data movement questions that legal teams love to ask. Azure exposes both regions, with Australia Southeast in Victoria sometimes preferred by organisations in Melbourne because of the proximity and the way peering works with on-premises integrations.

Next, decide between access policies and Azure RBAC. For smaller teams, access policies are quicker to configure and easier to reason about. For larger enterprises that already standardise on RBAC across subscriptions, role-based authorisation gives a familiar model and integrates with Privileged Identity Management. Either approach works; mixing them in a single vault leads to confusion, so pick one and stick with it.

Soft delete and purge protection are non-negotiable in a regulated environment. Turn both on during creation rather than after, because enabling purge protection later requires a fresh vault. With those settings in place, even an accidental deletion by a well-meaning developer on a Friday arvo will not take your secrets with it.

Authenticating without storing credentials

The classic chicken-and-egg problem with Key Vault is this: your app needs a credential to read the credential store. The fix is managed identity, and it is the single biggest reason developers stop rolling their own solutions. When you enable a system-assigned managed identity on an App Service, Function App or VM, Azure creates a service principal behind the scenes and rotates its secret automatically. Your code simply calls DefaultAzureCredential and lets the Azure SDK work out which identity to use.

In a local development environment, DefaultAzureCredential falls back to your Azure CLI login, which is convenient when you are bouncing between cafes in Surry Hills and the office. In CI pipelines, swap in a workload identity federation so that your build agent never needs a long-lived client secret. The point is that the application code stays identical across environments, while the identity mechanism changes underneath.

If your application runs on something that does not yet support managed identities, such as an older on-premises server, fall back to a service principal with a certificate rather than a secret. Certificates are easier to rotate and harder to leak in a build log, and they fit comfortably inside an Azure DevOps library or a GitHub Actions secret. Whatever you do, avoid putting a client secret back into appsettings.json; you have just moved the problem rather than solved it.

Reading secrets at startup and refreshing them safely

The simplest pattern is to read all required secrets during application startup and cache them in memory. ASP.NET Core's AddAzureKeyVault extension wires this up with a few lines in Program.cs, and the IConfiguration provider transparently exposes each secret as a configuration value. For a connection string, you might retrieve it with Configuration.GetConnectionString("PrimaryDb") and pass it straight into your DbContext options.

Caching has trade-offs. A cached secret means your app does not make a network call on every database query, which is good for performance and good for hitting the Key Vault throttling limits. The downside is that a rotation does not take effect until the next restart. For most line-of-business applications this is acceptable, but for systems handling payments or patient records, you may want a shorter refresh window.

A more advanced pattern uses IConfigurationRoot.Reload() on a timer, or wires up Azure Key Vault's event grid notifications to invalidate a cache when a secret changes. This is a small amount of extra code but a big operational win, especially when the security team in your Sydney CBD office insists on monthly rotation without any downtime.

Rotating secrets without redeploying

Rotation is the moment of truth for any secret management strategy. With Key Vault, the workflow is straightforward. Update the secret value in the portal or through the CLI, optionally set an activation date if you are using staged rotation, and let consumers pick up the new value on their next read. No application redeploy, no config push, no emergency change window.

For database credentials, consider pairing Key Vault with Azure SQL's own automatic rotation features where supported. The pattern is usually a dual-credential model: the application presents both the old and the new password during a transition window, and the database accepts either. Once the transition window closes, you remove the old credential from Key Vault entirely.

Australian organisations under APRA oversight often tie rotation cadences to documented control testing. Having the rotation runbook living alongside the vault, with audit logs in Log Analytics, makes the next CPS 234 assessment noticeably less painful. It is also a good conversation starter when comparing notes with peers at local .NET user groups in Melbourne or Brisbane.

Compliance habits and the Australian context

A vault is only as trustworthy as the habits around it. Treat secret values as write-only from a developer perspective. If someone on your team needs to read a production connection string, that is a smell; build a deployment pipeline that injects the secret directly into the application instead. Audit the access policies quarterly, and prune any service principal that no longer needs access.

Australian privacy law adds a few wrinkles. The Privacy Act and the Australian Privacy Principles expect organisations to protect personal information, and connection strings that grant access to a customer database sit squarely in scope. Hosting your vault in an Australian region, keeping the activity log in Australia, and restricting access via Conditional Access policies are all practical steps that map cleanly to those obligations.

Finally, do not forget the boring parts. Backups, disaster recovery drills, and a documented runbook for what to do if the vault becomes unavailable. A cached fallback configuration, even a stripped-down one, can keep a checkout flow alive while the platform team investigates. Pair that with sensible alerts on vault health in Application Insights, and you have a setup that survives both a bad Tuesday morning and a regulator's questionnaire on a quiet Friday arvo.