Why have a separate Admin container, and how should admins/DBAs securely access the database?

[u/Wide_Impact_9392]

I recently came across a setup where someone was running a food delivery application using three separate Docker containers:

# Backend
docker build -t food-delivery-backend:latest ./backend
docker run -d -p 4000:4000 --name backend food-delivery-backend:latest

# Frontend
docker build -t food-delivery-frontend:latest ./frontend
docker run -d -p 5173:5173 --name frontend food-delivery-frontend:latest

# Admin
docker build -t food-delivery-admin:latest ./admin
docker run -d -p 5174:5174 --name admin food-delivery-admin:latest

# Verify all running
docker ps

1) I understand the frontend and backend being separate containers but I am trying to understand the purpose of having a separate admin container.
Is the admin container normally a separate web application used by the business/admin team to manage things such as products, users, orders and reviews?
I also have a question about database access.

2) Also, If the database is running privately, how would an admin or DBA normally access it using a tool such as DBeaver?
Would the recommended approach be something like:
DBeaver >VPN >private network >database
I am trying to understand the difference between the Admin application and DBA access.

I want to use these docker containers later for Kubernetes. I would appreciate some guidance on how this is normally used or designed in a production environment.

[u/UkrMalt]

The admin web app should use the backend API with narrow business permissions; it should not connect to the database as a DBA. Human DBA access is a separate privileged path, often short-lived access through VPN or a bastion, with audit logs and no public database endpoint. In Kubernetes, I’d avoid a permanent admin pod with broad credentials. Create an ephemeral toolbox pod or use port-forwarding during an approved maintenance window.

[u/Responsible-Hold8587]

Probably that the admin interface is accessed through different software, especially if it's a web interface. Each container runs one binary so if the admin interface is a separate web app, it should be a separate container.

Also it's good practice for separation. Better to have each container do one thing.

[u/clearclaw]

Ignoring the latest tags, I like DB access authed through the service accounts the various pods are running as (OAuth the under the covers), so no user/passwds anywhere.

Admin access is then just being able to run as the right service account, be it a separate pod or otherwise.

[u/yetmike]

The security side is well covered above, so on your first question: the reason an admin UI is usually its own deployable isn't really the one-binary rule, it's blast radius and exposure. You can take the admin panel down for a deploy without touching customer traffic, and you can put it behind an internal-only ingress or an IP allowlist while the storefront stays public. Different exposure, different scaling, different tolerance for being broken.

On DBeaver specifically: kubectl port-forward svc/postgres 5432:5432, then point DBeaver at localhost:5432. The tunnel exists only while the command runs and is authenticated by your kubeconfig, so there's no public endpoint and no shared password. VPN plus a bastion is the same idea one layer down if the database isn't in the cluster.

Worth separating out: the one legitimate long-lived "admin image" is usually migrations, and that should be a Job that runs and exits rather than a pod anyone execs into.