Introduction

In Kubernetes, the usual pattern is to store only the sensitive part of a database connection, such as the password, in a Secret, then let the .NET application assemble the full connection string at runtime. This keeps credentials out of source control and avoids baking them into container images or plain configuration files.

Create the Secret

You can define a secret with stringData so Kubernetes handles the encoding for you.

1apiVersion: v1
2kind: Secret
3metadata:
4  name: db-secret
5type: Opaque
6stringData:
7  DB_PASSWORD: SuperSecretPassword123

Apply it:

kubectl apply -f db-secret.yaml

That creates a secret with one key named DB_PASSWORD.

Inject the Secret into the Pod

The most common way is an environment variable:

1apiVersion: apps/v1
2kind: Deployment
3metadata:
4  name: my-dotnet-app
5spec:
6  replicas: 1
7  selector:
8    matchLabels:
9      app: my-dotnet-app
10  template:
11    metadata:
12      labels:
13        app: my-dotnet-app
14    spec:
15      containers:
16        - name: app
17          image: myregistry/my-dotnet-app:1.0.0
18          env:
19            - name: DB_PASSWORD
20              valueFrom:
21                secretKeyRef:
22                  name: db-secret
23                  key: DB_PASSWORD

Now the container process can read DB_PASSWORD at runtime.

Build the Connection String in .NET

Modern .NET reads environment variables through the default configuration pipeline, so you can access the secret with builder.Configuration.

1using Microsoft.Data.SqlClient;
2using Microsoft.EntityFrameworkCore;
3
4var builder = WebApplication.CreateBuilder(args);
5
6string? password = builder.Configuration["DB_PASSWORD"];
7if (string.IsNullOrWhiteSpace(password))
8{
9    throw new InvalidOperationException("DB_PASSWORD is missing.");
10}
11
12var csb = new SqlConnectionStringBuilder
13{
14    DataSource = "sqlserver.default.svc.cluster.local",
15    InitialCatalog = "AppDb",
16    UserID = "appuser",
17    Password = password,
18    TrustServerCertificate = true
19};
20
21builder.Services.AddDbContext<AppDbContext>(options =>
22    options.UseSqlServer(csb.ConnectionString));
23
24var app = builder.Build();
25app.Run();

Using a connection-string builder is safer than manual string concatenation because it handles formatting and escaping correctly.

Keep Secret and Non-Secret Settings Separate

A practical split is:

• keep host, database name, and username in normal config
• keep only the password in the Kubernetes secret

Example appsettings.json:

1{
2  "Database": {
3    "Server": "sqlserver.default.svc.cluster.local",
4    "Name": "AppDb",
5    "User": "appuser"
6  }
7}

Then read those values together with DB_PASSWORD and build the final connection string at startup. This keeps secret rotation and environment configuration easier to manage.

Secret Files Are Another Option

Kubernetes can also mount secrets as files instead of environment variables:

1volumeMounts:
2  - name: db-secret-volume
3    mountPath: /app/secrets
4    readOnly: true
5volumes:
6  - name: db-secret-volume
7    secret:
8      secretName: db-secret

Then the application can read /app/secrets/DB_PASSWORD. This is useful when a library expects file-based secrets or when you prefer not to expose them as environment variables.

Security Notes

Kubernetes secrets are sensitive operational data, but they are not magically secure just because they are called secrets. Access control, cluster configuration, and secret rotation still matter.

Also avoid logging the full connection string. A single debug statement can undo the point of storing the password safely.

Common Pitfalls

One common mistake is storing the entire connection string in the secret even though only the password is sensitive. That makes normal environment configuration harder.

Another issue is building the connection string with raw string concatenation instead of a connection-string builder.

A third pitfall is assuming updated environment-variable secrets appear live in a running process. In many deployments, pods need to be restarted for the change to take effect cleanly.

Summary

• Store the database password in a Kubernetes Secret.
• Inject it into the pod as an environment variable or mounted file.
• Build the final connection string in .NET at runtime.
• Keep non-secret settings in normal application configuration.
• Avoid logging or hard-coding the final credential-bearing connection string.