Secure a Container Registry with Authentication and TLS
A container registry without authentication is rarely useful outside of a local context. Once other machines and services can reach it, you usually need to decide who is allowed to push and pull images.
The common (for registries) way to implement authentication is HTTP Basic Auth. But Basic Auth is only secure over HTTPS - the username and password are sent unencrypted, so using it without TLS would make the credentials leak rather quickly.
In this challenge, you'll set up a registry that requires a username and password, and serves traffic over TLS.
Given
The TLS certificate and key for the registry-1.corp hostname (trusted in the challenge's environment):
~/certs/
The username and password for authenticated access:
username: iximiuzlabs
password: rules!
The task
Expose an OCI Distribution compatible registry at:
https://registry-1.corp
It must listen on port 443 on the registry-1 (current) host.
The endpoint must:
- Serve HTTPS using the provided
registry-1.corpcertificate (in~/certs/) - Reject anonymous requests with
HTTP 401orHTTP 403 - Allow
iximiuzlabs/rules!to push an image - Allow the same user to pull the image back
The implementation is up to you. You can use the registry's built-in TLS and auth support,
put a reverse proxy in front, or use another setup entirely.
The verifier only checks the behavior of the https://registry-1.corp endpoint (as a black box).
Hint 1
A registry is just an HTTP server speaking the OCI Distribution Spec API. "Authenticated and served over HTTPS" adds two orthogonal concerns on top of that:
- Authentication
- TLS termination
Those two jobs can be handled by the registry itself, or by a reverse proxy in front of it.
Hint 2
Two common approaches:
- Run the
distribution/distribution'sregistryimage with its built-in TLS andhtpasswdauth support. - Run the registry on a private port, then put a reverse proxy in front of it to handle HTTPS and authentication. The Distribution docs have an Nginx recipe for this setup.