docker
Support OIDC identities for docker login
Tell us about your request
Currently dockerhub requires a static token or password. These tokens are easily lost and hard to track and replace. It would be much better for dockerhub to support an oidc identity that can be created by a pipeline as opposed to a static token. These tokens can be validated by either a public well-known oidc discovery document or via a pinned certificate for private pipelines.
Which service(s) is this request for? dockerhub
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard? I want to be able to securely publish containers from my GitHub actions pipeline with the pipeline's identity, rather then a static account stored as a secret.
Are you currently working around the issue? Not yet, though planning to
Additional context Add any other context or screenshots about the feature request here.
Hi, any update on this? We're using OIDC for integrations with the cloud platforms, would be great to have that for pushing to Docker Hub as well.
Apologies if there is another way of doing this that I have missed!
Hey friends, I realize this is a very old ticket and we have been wanting to do this for quite a while now. Happy to say that we are starting planning and scoping out what an OIDC type of provider would look like for registry and hub. Nothing solid yet, but just an update 😄
Hello all! Just an update here. We have our first system design and are underway on this!
We hear ya on the "Bring my own auth for OIDC" and we'll get there, but the first implementation of this will be GitHub Actions OIDC to start. A lot of what we are designing is a more broad implementation so this can branch into whatever customers want to use.
Thanks for the patience and expect more updates in Q1 of this year. 🎉
It would be great to have OIDC available from GitHub Actions and Terraform Cloud, so we can terraform our Docker repos and teams etc, and not just push images.
Hi all! We're currently working on offering GitHub OIDC and will release it internally first. For BETA, were targeting somewhere mid July. Once we have more concrete dates, I'll post here.
I'm assuming once it works for GitHub, then adding Terraform Cloud would be relatively simple and so could follow fairly soon after.
@etugarinova if we want to participate in the beta, should we just subscribe to this issue or is there another way to submit?
I'm assuming once it works for GitHub, then adding Terraform Cloud would be relatively simple and so could follow fairly soon after.
You are correct in your assumption. We plan long-term to integrate with other providers. Would be great to understand the most wanted for sure.
@JonZeolla We will be releasing as "Beta" to everyone.
I can update here: We are starting full internal testing here in the next week or so. Beta will start shortly after!
CircleCI please. They already support OIDC with AWS
https://circleci.com/docs/guides/permissions-authentication/openid-connect-tokens.html
CircleCI please. They already support OIDC with AWS
Yup! Definitely on our list to check out :) We've built this to be pretty generic in authentication so any future OIDC providers should be way less work to set up for us.
Appreciate the call out.
Support for GitLab CI would be welcome. It already supports OIDC with PyPI.
Sounds like this has been progressing - any ideas on the timeline for a public release yet?
NPM put their OIDC feature to GA a couple of months ago. We've had a renewed focus on moving everything onto OIDC following Shal Halud.
I'm wondering the available date of this feature too. Really appreciate it if we can get it earlier!
Would be a great use-case to support Google Artifact Registry as Remote Repository / Pull-through Cache.
Very interested in this feature too, if there`s a beta test possible, my FOSS organization can participate: https://github.com/sablierapp
CircleCI please. They already support OIDC with AWS
Yup! Definitely on our list to check out :) We've built this to be pretty generic in authentication so any future OIDC providers should be way less work to set up for us.
Appreciate the call out.
I'm curious. Is there anything against letting the user decide which JWT token iss, aud, sub to allow specified access to a repository?
Yup! Definitely on our list to check out :) We've built this to be pretty generic in authentication so any future OIDC providers should be way less work to set up for us.
You shouldn’t be setting up providers at all beyond a nice UI for configuring one or two of the most popular ones. We need to be able to configure any OIDC issuer. I know the current trend is for registries to support “trusted providers” but enterprises very often don’t use popular cloud providers for CI/CD. They need the capability to configure any OIDC issuer, like Hashicorp Vault, Azure Managed Identities, AWS IAM roles, or an issuer backed by an on-prem HSM. We happen to use Azure DevOps for CI/CD, which while a SaaS offering with OIDC tokens, registries haven’t supported it and get stuck still using legacy authentication methods and managing an inane number of tokens. Azure has a really good generic OIDC implementation in Workload Identity Federation that could be a good reference example. JFrog has a good OIDC implementation as well. AWS’s is workable ( like most of the IAM design it’s a bit wonky and doesn’t support standard endpoints 🤦♂️)
