Private Registries & Registry Authentication

The plain-language idea

A registry is a server that stores and serves image layers by name and tag — docker push/docker pull talk to one. Docker Hub is the default registry Docker's CLI points at if you never say otherwise, and it's genuinely fine for public, open-source images. But a real team's application images are proprietary, and Docker Hub's free tier also imposes pull-rate limits that can throttle a busy CI pipeline pulling base images all day. Almost every real deployment ends up using a private registry instead: a self-hosted one (the open-source Docker Registry image, or Harbor), or — far more commonly — the registry built into whatever cloud a team already deploys to: AWS's ECR, Google's GCR/Artifact Registry, Azure's ACR, or GitHub's GHCR (Container Registry, tied to a GitHub org).

Whichever registry a team lands on, the deciding factors are the same: who can push, who can pull, how close the registry sits to the deployment target (pulling from ECR into an ECS task in the same AWS region is faster and doesn't cross the public internet), and whether it integrates with the cloud's existing IAM rather than needing a separate credential system.

See it in a real thing: logging in, and where the credential actually lives

# Docker Hub or a self-hosted registry — username + password/token
docker login registry.example.com

# AWS ECR — no long-lived password; exchange an IAM identity for a short-lived token
aws ecr get-login-password --region us-east-1 \
  | docker login --username AWS --password-stdin \
    123456789012.dkr.ecr.us-east-1.amazonaws.com

docker login doesn't just authenticate one command — it writes credentials to ~/.docker/config.json (or hands them to a credential helper) so every subsequent docker push/docker pull against that registry is already authenticated. That persistence is exactly why the kind of credential stored there matters: a personal Docker Hub password sitting in that file on a laptop is a very different risk than a token that expires in twelve hours.

What people usually miss

Watch out

• A CI pipeline should never use a personal login. A registry token embedded in a pipeline config that's actually a developer's own Docker Hub password is a shared secret that's expensive to rotate (it breaks that person's local Docker too) and impossible to audit per-pipeline. CI should authenticate as its own identity — a machine user, a CI-provider-issued OIDC token exchanged for cloud credentials, or a registry-specific service account — scoped to exactly the push/pull it needs.
• Cloud registry tokens are short-lived by design, not by accident. ECR's token from get-login-password expires in hours; this is a deliberate tradeoff (a compromised CI log leaking that token is a much smaller window of exposure than a leaked long-lived password) and pipelines are expected to re-fetch one per run, not cache it.
• docker login's stored credential is only as safe as the machine it's on. Without a credential helper (docker-credential-desktop, docker-credential-ecr-login, etc.), Docker falls back to storing the auth token in ~/.docker/config.json in a lightly-obscured but not encrypted form — a credential helper backed by the OS keychain is the safer default on a real workstation.
• Public-pull rate limits apply even to images you don't own. A CI pipeline pulling node:20-alpine from Docker Hub on every run can get throttled once anonymous or free-tier pull limits are hit — mirroring commonly-used base images into a private registry the team controls is a common fix, not just a private-image concern.

Why this matters in interviews

"How does your CI pipeline authenticate to push images without a developer's personal credentials sitting in a config file?" is a real, senior-leaning question, and naming the specific mechanism — a scoped machine identity or IAM-role-based short-lived token, not a shared password — is what separates an answer that's actually been through a security review from one that hasn't.