How Do You Manage Secrets and Connection Strings Securely?

Secrets and connection strings should never be hard-coded in application source code or committed to source control. In ASP.NET Core, they should be stored outside the application and loaded through the configuration system.

1. What Are Secrets?

Secrets are sensitive values that should not be exposed publicly.

Examples:

Database Password
Connection String with Credentials
API Key
JWT Signing Key
OAuth Client Secret
Storage Account Key
Service Bus Credentials
Certificates

For example, avoid hard-coding:

var connectionString =
    "Server=prod;Database=OrderDB;User Id=sa;Password=MyPassword123;";

If this reaches Git, logs, screenshots, or build artifacts, the credentials may be exposed.

2. Why Do We Need Secret Management?

In microservices, you may have:

Product Service
Order Service
Payment Service
Inventory Service
Notification Service

Each service can require different credentials.

Without proper management:

Source Code
    ↓
Connection Strings
API Keys
Passwords
JWT Keys
    ↓
Git Repository

Anyone with repository access may potentially see sensitive credentials.

Instead:

Application
     ↓
Secure Secret Store
     ↓
Secret

3. Local Development – .NET User Secrets

For local development, ASP.NET Core provides User Secrets.

Initialize:

dotnet user-secrets init

Store a connection string:

dotnet user-secrets set \
"ConnectionStrings:DefaultConnection" \
"Server=localhost;Database=OrderDB;User Id=devuser;Password=xxxx;"

Then access it normally:

var connectionString =
    builder.Configuration.GetConnectionString(
        "DefaultConnection");

The application does not need to know whether the value came from appsettings.json, User Secrets, environment variables, or another configuration provider.

Important

User Secrets are intended for development convenience. They are not an encrypted enterprise production secret-management system.

4. Production – Use a Secret Manager

For production, use a secure secret-management service.

Examples:

Azure       → Azure Key Vault
AWS         → AWS Secrets Manager
Kubernetes  → Kubernetes Secrets
Other       → Enterprise secret-management platform

For an Azure-hosted ASP.NET Core application, Azure Key Vault is a common choice.

ASP.NET Core Microservice
          |
          ↓
     Azure Key Vault
          |
   ┌──────┼────────┐
   ↓      ↓        ↓
 DB     API Key   Secret
Password

5. Azure Key Vault

Azure Key Vault can securely store:

• Secrets
• Passwords
• API keys
• Certificates
• Cryptographic keys
• Connection strings containing credentials

Instead of:

{
  "ConnectionStrings": {
    "DefaultConnection":
      "Server=prod;Database=OrderDB;User Id=sa;Password=Secret123;"
  }
}

you can keep the sensitive value outside the application.

Conceptually:

Azure Key Vault

ConnectionStrings--DefaultConnection
             ↓
Server=...;Database=...;Password=...

The application retrieves it through its configuration/security setup.

6. Required NuGet Packages for Azure Key Vault

For an ASP.NET Core application using Key Vault configuration:

dotnet add package Azure.Extensions.AspNetCore.Configuration.Secrets
dotnet add package Azure.Identity

Azure.Identity provides authentication mechanisms such as DefaultAzureCredential.

7. Configure Azure Key Vault

Example:

using Azure.Identity;

var builder = WebApplication.CreateBuilder(args);

var keyVaultUri =
    new Uri(builder.Configuration["KeyVault:VaultUri"]!);

builder.Configuration.AddAzureKeyVault(
    keyVaultUri,
    new DefaultAzureCredential());

Then retrieve the connection string normally:

var connectionString =
    builder.Configuration.GetConnectionString(
        "DefaultConnection");

Your application code remains configuration-provider independent.

8. How Does the Application Authenticate to Key Vault?

A common Azure production approach is Managed Identity.

Instead of storing:

Key Vault Username
Key Vault Password
Client Secret

inside the application, Azure provides an identity to the workload.

ASP.NET Core App
      |
      | Managed Identity
      ↓
Azure Key Vault
      |
      ↓
Authorized Secrets

This avoids the classic problem:

"Where do I securely store the password required to access my secret store?"

9. Managed Identity

For example:

Azure App Service
       |
       | Managed Identity
       ↓
Azure Key Vault
       |
       ↓
Database Secret

You grant the application's identity only the permissions it needs.

This follows the Principle of Least Privilege.

For example:

Order Service
     ↓
Can read Order-related secrets

Payment Service
     ↓
Can read Payment-related secrets

The Order Service should not automatically receive access to every Payment secret.

10. Even Better – Passwordless Database Authentication

Where supported, an even stronger design is to avoid database passwords entirely.

Instead of:

Application
     ↓
Key Vault
     ↓
DB Username + Password
     ↓
SQL Database

you can use identity-based authentication:

Application
     |
     | Managed Identity
     ↓
Azure SQL

For example, a connection string can use managed identity authentication rather than embedding a password.

This reduces the number of secrets you need to manage and rotate.

11. Environment Variables

Secrets can also be supplied using environment variables.

For example:

ConnectionStrings__DefaultConnection

ASP.NET Core converts __ into :.

Therefore:

ConnectionStrings__DefaultConnection

maps to:

ConnectionStrings:DefaultConnection

Environment variables are commonly injected by:

• CI/CD pipelines
• Container platforms
• Azure App Service
• Kubernetes
• Deployment systems

However, for highly sensitive production secrets, a dedicated secret manager usually provides stronger capabilities such as centralized access control, auditing, and rotation.

12. appsettings.json

It is fine to store non-sensitive configuration in appsettings.json.

For example:

{
  "Logging": {
    "LogLevel": {
      "Default": "Information"
    }
  },

  "PaymentService": {
    "TimeoutSeconds": 30
  }
}

But avoid committing production credentials such as:

{
  "ConnectionStrings": {
    "DefaultConnection":
      "Server=prod;User Id=admin;Password=RealPassword;"
  },

  "Jwt": {
    "SecretKey": "RealProductionSecret"
  }
}

13. Secret Rotation

Secrets should also be rotatable.

Suppose a database password is compromised.

Without centralized secret management:

Change Password
      ↓
Modify Configuration
      ↓
Rebuild?
      ↓
Redeploy Multiple Services

With proper secret management:

Rotate Secret
      ↓
Update Secret Store
      ↓
Application receives/reloads value

The exact refresh behavior depends on the configuration provider and application design.

This is another reason centralized secret management is valuable.

14. Don't Log Secrets

Even if secrets are stored correctly, they can accidentally be exposed through logging.

Avoid:

_logger.LogInformation(
    "Connection string: {ConnectionString}",
    connectionString);

Also be careful with:

Request Headers
Authorization Tokens
API Keys
Passwords
Connection Strings
Personal/Sensitive Data

Logging systems are often accessible to many people, so secret redaction is important.

15. CI/CD Pipeline

Don't hard-code production passwords directly into pipeline files.

Bad:

connectionString: "Server=prod;Password=Secret123"

Prefer:

CI/CD Pipeline
       ↓
Secure identity / protected secret
       ↓
Secret Manager
       ↓
Application

Also ensure secrets are not accidentally printed into pipeline logs.

16. Microservices Secret Management

In microservices, each service should receive only the secrets it requires.

                 Secret Store
                      |
       ┌──────────────┼──────────────┐
       ↓              ↓              ↓
 Product Service  Order Service  Payment Service
       |              |              |
 Product Secrets  Order Secrets  Payment Secrets

Avoid giving every service unrestricted access to every secret.

This improves isolation and limits the impact if one service is compromised.

17. Recommended Environment Strategy

A practical ASP.NET Core approach is:

18. Advantages

Proper secret management provides:

• No secrets in source code.
• Better security.
• Centralized secret management.
• Fine-grained access control.
• Easier secret rotation.
• Better auditing.
• Environment separation.
• Reduced credential exposure.
• Better microservice isolation.
• Easier compliance and governance.

19. Disadvantages / Challenges

There are also challenges:

• Additional infrastructure.
• Secret-store availability must be considered.
• Access permissions must be configured correctly.
• Secret rotation needs application support.
• Local and cloud authentication differ.
• Misconfigured identities can prevent application startup.
• Centralized secret management requires monitoring and governance.

20. Key Points

• Never hard-code secrets.
• Never commit production credentials to Git.
• Use .NET User Secrets for local development.
• Use Azure Key Vault or another secret manager for production.
• Prefer Managed Identity in Azure.
• Prefer passwordless authentication where supported.
• Use environment variables for deployment-specific configuration where appropriate.
• Apply least privilege to each microservice.
• Never log passwords, tokens, API keys, or full sensitive connection strings.
• Rotate secrets periodically and after suspected exposure.
• Protect secrets in CI/CD pipelines.
• Each microservice should access only the secrets it needs.

21. Interview Questions & Answers

Q1. How do you securely manage secrets in ASP.NET Core?

I keep secrets outside source code. For local development I use .NET User Secrets, and in production I use a secure secret store such as Azure Key Vault, preferably accessed using Managed Identity.

Q2. Should connection strings be stored in appsettings.json?

Non-sensitive connection information can be, but connection strings containing production credentials should generally be stored in a secure external source rather than committed to source control.

Q3. What is .NET User Secrets?

It is an ASP.NET Core/.NET development feature that stores sensitive development configuration outside the project directory so it isn't committed with the source code.

Q4. Is .NET User Secrets suitable for production?

No. It is intended primarily for local development.

Q5. What is Azure Key Vault?

Azure Key Vault is an Azure service for securely storing and controlling access to secrets, cryptographic keys, and certificates.

Q6. What is Managed Identity?

Managed Identity gives an Azure resource an Azure-managed identity that can authenticate to supported Azure services without storing application credentials.

Q7. Which is better: storing the SQL password in Key Vault or Managed Identity?

Where supported, Managed Identity/passwordless authentication reduces the need to maintain a database password at all. Key Vault remains useful for secrets that cannot be eliminated.

Q8. How should secrets be handled across multiple microservices?

Each microservice should have least-privilege access only to the secrets it requires, rather than sharing one set of credentials across all services.

Interview One-Line Answer

Manage secrets by keeping them outside source code, using User Secrets locally, secure secret stores such as Azure Key Vault in production, least-privilege access, secret rotation, and passwordless identities such as Managed Identity wherever possible.