All case studiesLab project
Private Container Registry
A Harbor registry for versioned, access-controlled container images, integrated with the build pipeline and deployment workflow.
- Harbor
- Docker
- CI/CD
- TLS
This is a personal lab build used to practise and demonstrate the approach. It describes architecture and decisions, not results from a client engagement.
Problem
Images were built ad hoc and pulled from mixed sources, making it hard to know exactly what was running and who could publish it.
Architecture
- Build
- CI pipeline
- Docker build
- Registry
- Harbor projects
- Robot accounts
- Deploy
- Deployment hosts
- Pinned image tags
Technical decisions
- Immutable, traceable tags
- Images are tagged with the commit SHA (plus a release tag when applicable), so any running container maps back to exact source.
- Robot accounts per purpose
- The pipeline uses a push-capable robot account; deployment hosts use pull-only credentials.
- Project-level access control
- Harbor projects separate teams and environments so permissions follow the principle of least privilege.
Implementation
- Installed Harbor with TLS and persistent storage.
- Created projects and role-based access for teams and automation.
- Connected the CI pipeline to build, tag, and push images.
- Updated deployments to pull pinned tags from the private registry.
Security considerations
- Separate push and pull credentials with minimal scope.
- Registry served only over HTTPS.
- Credentials stored as CI secrets, never in pipeline files.
Operational benefits
- Every deployed image is traceable to a commit.
- Clear control over who can publish images.
- Rollbacks are a matter of redeploying a previous tag.
Lessons learned
- Plan image retention and garbage collection early; registries grow quickly.
- Pinning tags in deployments is what makes rollbacks reliable.