A safe tunnel to PostgreSQL | Labs | DevOps in Practice

A developer needs to inspect a private PostgreSQL database. The database has no public endpoint, and creating one would widen the attack surface.

Confirm the Service and its database port before opening a tunnel.

Try: kubectl get service orders-postgres

Terminal command

The private database is reachable.

The session connects through localhost while PostgreSQL remains private inside the cluster.

Lesson

Prefer temporary, authenticated access paths for investigation. Port-forwarding is convenient, but it should still use least-privilege credentials and be closed when the work is done.

No editor required

This editor is not used in this lab.

Key concepts

ClusterIP keeps the database private

The Service is reachable inside the cluster only.

What it is

ClusterIP is the default Kubernetes Service type and provides an internal virtual address.

In this incident

orders-postgres intentionally has no external IP.

Why it matters

Private-by-default database access avoids a permanent public entry point.

Port-forward is a temporary tunnel

A local port is proxied through the Kubernetes API.

What it is

kubectl port-forward creates a temporary connection from localhost to a Pod or Service target.

In this incident

Local port 15432 maps to PostgreSQL port 5432 for this troubleshooting session.

Why it matters

It preserves the private Service and disappears when the command stops.

Use least-privilege database credentials

Network access and database authorization are separate controls.

What it is

A read-only role can connect and query permitted objects without changing data.

In this incident

The verification uses the readonly role for a harmless SELECT.

Why it matters

A tunnel should not grant more database power than the task requires.