vscode-docker
vscode-docker copied to clipboard
microsoft
Support third-party registries
Specifically requested (but goal is generic support), in no particular order:
Open:
- [ ] goharbor.io (see #878, #3449)
- [ ] ECR (Amazon, see #3202, #3604)
- [ ] GCR (Google) (+3 see #394, #2890)
- [ ] quay.io (+4 see #390)
- [ ] DTR (Enterprise Docker trusted registry) (see #3325)
- [ ] Cloudsmith (see #1887)
- [ ] Aliyun (see #1964)
- [ ] Portus (see #2735)
- [ ] Digital Ocean (see #2879)
Blocked on no/partial Registry V2 support:
- [ ] V2 registries that don't use
/v2/endpoint (see #3562) - [ ] GitHub (see #1525, #1938)
- [ ] GitLab self-hosted (+5 see #1832, #2457, #2735, #3119, #3271)
- [ ]
harbor.korporate.org(see #1927) - [ ] GitLab Groups (see #1970)
Done:
- [x] DockerHub
- [x] Azure
- [x] GitLab (+25-ish see #162)
- [x] Generic V2 registry (+2)
while connecting using private registry option, is private Docker DTR (Enterprise Docker trusted registry) supported at all?
@gauravlakhani Support for registries beyond Docker Hub is fairly new, we haven't tested on DTR. I've added it to the list.
This could potentially require and/or take advantage of https://github.com/microsoft/vscode/issues/88309
I've spent a lot of time researching in the past few days. Unfortunately this is going to be extremely difficult, due to two main issues:
-
No / incomplete Registry V2 API support
- GitHub, Docker Hub lack the
_catalogendpoint - GitLab has no V2 API support at all, but instead a custom API
- ~~DTR has no V2 API; or at least I can't find any docs suggesting it does~~ Looks like DTR might: https://success.docker.com/article/how-do-i-use-api-v2-with-dtr
- GitHub, Docker Hub lack the
-
OAuth flows totally inconsistent with each other and with the spec
- Azure and Quay require a web page sign-in
- Docker Hub has a hilariously broken auth flow--it issues tokens regardless of anything (though the tokens will not work), and does not issue refresh tokens even when asked for them, and does not accept
POST's for OAuth tokens like the spec says - GCR and ECR use credential helpers--not something we can use easily
- Quay requires the users to create a client application, and provide its ID to any clients (e.g. this extension). Possible, but onerously difficult.
- goharbor.io might be the only one with a proper implementation that also permits password auth? At least, their docs sound like it.
Implementing support for each registry with their own custom APIs is a non-starter. Dealing with the OAuth flows is possible, but guaranteed to result in a lot of bad user experiences, due to the complexity and prerequisite setup that most of them demand.
I stumbled upon this in our company. Our setup is basic docker registry instance as container via image registry:2 image id 708bc6af7e5e while Oauth2 authentication is handled by second container via cesanta/docker_auth:latest image id dd1aae63f028 with some kind of OpenLdap in background.
Most of tools which I have used can handle this combination well as it implements basic Oauth2 flow without redirects to web UI or other magical stuff. For us standard Oauth2 support would be enough.
@kautkata I'd love to learn more about your setup and see if we can get support added. registry:2 OAuth is a starting point that would help a lot of folks.
Do you have any setup guides on what you have? When doing docker login from the command line, what do you use for username/password? I've seen options of actual password, PAT, OAuth token, and more...
@bwateratmsft Here you go.
Registry and auth endpoint configuration files are modified (you know I'm not supposed to expose our internal details and stuff) but in general they still should work. TLS certificates are pretty basic, they where generated via openssl command line tools.
From docker container perspective it looks like this: dockerps.txt
Registry container gets started via: /usr/bin/docker run --name registry --mount type=bind,source=/etc/docker-registry,destination=/cfg,readonly --mount type=bind,source=/mnt1/docker/registry,destination=/var/lib/registry -p 443:443 registry:2 /cfg/config-registry.yml
Auth endpoint gets started via: /usr/bin/docker run --name registry-auth --mount type=bind,source=/etc/docker-registry,destination=/cfg,readonly -p 442:442 cesanta/docker_auth:latest -logtostderr /cfg/config-auth.yml
Registry configuration file: config-registry.yml
Auth endpoints configuration file: config-auth.yml
On server /etc/docker-registry directory contains following files: config-auth.yml config-registry.yml ldap_password server-cert.pem server-key.pem
From ldap users perspective using docker daemon running on Linux it works as a charm via:
docker login -u <ldap username> docker.internaldomain.lv
Password:
WARNING! Your password will be stored unencrypted in /home/<os user>/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store
Login Succeeded
Afterwards specified OpenLDAP user can push images to registry, example: docker.internaldomain.lv/user/<ldap user name>/test:latest
PS. Auth endpoints project https://github.com/cesanta/docker_auth
This is great info, thanks a ton @kautkata. I'll be spending some time in the 1.1 release looking into this to see what we can do.
@fathom-matthew @Nhimself @imkhairulikhwan (I @'d you all since you have commented recently :smile:):
GCR, ECR, and Quay all require some extra setup (each needs work done in their respective portals; GCR and ECR also require installing their respective command-line utilities). What do you guys think would be the best user experience to enable these registries but still set users up for success by getting them through the necessary setup?
@bwateratmsft how does the new GitHub registry fit into the picture?
I was looking for some details esp. around RegistryV2 support, but from what GitHub has on their website I can't really say if full V2 protocol is supported...
Pretty sure the "new" GitHub registry is just the existing GitHub registry but "relaunched" to draw more attention and with a few additional features not relevant to us. It's V2 compliant minus the _catalog endpoint. In the new extensibility model I'm making such monolith registries possible to connect to but it will require adding each repository manually since there's no way to list repositories.
@bwateratmsft Any update on GCR? They have a bit more documentation and are at least Docker CLI compatible. https://docs.github.com/en/free-pro-team@latest/packages/guides/connecting-a-repository-to-a-container-image
@JustinGrote We had been underway on a more generic and extensible registry provider model but it got shelved. I'm not sure what priorities will be coming up this year so I can't say what to expect.
Any update for the ECR and GCR?
@vivekrp We're working on a proposal for registry extensibility that would make it simple to add providers: #2033
We'd definitely be interested in your feedback on it!
+1 Github Container Registry,
the github contact @Phanatic in #1525 seems to have moved on with no response, the thread locked (only for contributors)
I've posted requesting an update here (is there a github issue for this?) https://github.community/t/ghcr-io-docker-http-api/130121/2
I would like to add that the docker image registry built into Gitea: Gitea Container Registry also does not contain endpoint /v2/.
