Kubernetes
PostgreSQL
Deployment
Configuration
DevOps

Pass postgres parameter into Kubernetes deployment

Master System Design with Codemia

Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.

Introduction

When an application in Kubernetes needs to connect to PostgreSQL, the usual “parameters” are host, port, database name, username, and password. In Kubernetes, you normally pass non-sensitive values with a ConfigMap and sensitive values with a Secret, then expose them to the container as environment variables or mounted files. The goal is to keep the deployment portable while avoiding hardcoded credentials in the manifest.

Use a Secret for Credentials

Passwords should not live directly in the Deployment YAML. Put them in a Secret.

yaml
1apiVersion: v1
2kind: Secret
3metadata:
4  name: postgres-secret
5type: Opaque
6stringData:
7  POSTGRES_USER: appuser
8  POSTGRES_PASSWORD: s3cr3t

stringData is convenient because Kubernetes encodes it for you when the object is created.

Use a ConfigMap for Non-Sensitive Settings

Hostnames, ports, and database names are usually fine in a ConfigMap.

yaml
1apiVersion: v1
2kind: ConfigMap
3metadata:
4  name: postgres-config
5data:
6  POSTGRES_HOST: postgres.default.svc.cluster.local
7  POSTGRES_PORT: "5432"
8  POSTGRES_DB: appdb

This keeps the split between secret and non-secret data clear.

Inject the Values into the Deployment

Reference both objects from the pod spec.

yaml
1apiVersion: apps/v1
2kind: Deployment
3metadata:
4  name: api
5spec:
6  replicas: 1
7  selector:
8    matchLabels:
9      app: api
10  template:
11    metadata:
12      labels:
13        app: api
14    spec:
15      containers:
16        - name: api
17          image: myorg/api:1.0
18          envFrom:
19            - configMapRef:
20                name: postgres-config
21            - secretRef:
22                name: postgres-secret

Then the application can read standard environment variables such as POSTGRES_HOST and POSTGRES_PASSWORD.

Build a Connection String in the Application

Most applications should assemble the final connection string at runtime instead of storing one giant prebuilt string in the manifest.

python
1import os
2
3host = os.environ["POSTGRES_HOST"]
4port = os.environ["POSTGRES_PORT"]
5db = os.environ["POSTGRES_DB"]
6user = os.environ["POSTGRES_USER"]
7password = os.environ["POSTGRES_PASSWORD"]
8
9url = f"postgresql://{user}:{password}@{host}:{port}/{db}"
10print(url)

That makes it easier to rotate credentials or move the database without changing application code.

Use Helm or Kustomize for Environment Differences

If dev, staging, and prod use different PostgreSQL endpoints, template those values with Helm or another deployment tool instead of copying and editing raw YAML by hand.

That way the deployment logic stays the same while the environment-specific values change.

Files Work Too When the App Expects Them

Not every application reads connection settings from environment variables. Some frameworks or legacy apps prefer config files. In that case, mount the Secret or ConfigMap as files instead of envFrom. The underlying recommendation stays the same: secrets for credentials, config objects for non-sensitive values, and no hardcoded database settings in the container image.

Remember Rollout Behavior

Updating a Secret or ConfigMap does not always mean your application process will immediately pick up the new PostgreSQL settings. Many applications read connection parameters only at startup. In those cases, roll the deployment after the config change so new pods start with the updated values.

That detail matters during password rotation, because the secret update alone is often not enough to restore connectivity.

Common Pitfalls

  • Putting database passwords directly into a Deployment manifest.
  • Mixing sensitive and non-sensitive values in one object without a reason.
  • Hardcoding a full connection string when separate variables would be easier to rotate.
  • Assuming base64 in a Secret is encryption. It is only encoding.
  • Forgetting to restart or roll out the deployment after changing externally consumed config.

Summary

  • Use a Secret for PostgreSQL credentials.
  • Use a ConfigMap for host, port, and database name.
  • Inject both into the pod as environment variables or files.
  • Build the connection string inside the application.
  • Template environment-specific values instead of editing manifests manually.

Course illustration
Course illustration

All Rights Reserved.