Ran into this publishing an open source image (rsync-crypt) to Docker Hub. The project
already publishes to GHCR under a per-repo GitHub token. Wanted the same on Docker Hub:
a CI credential that can only touch one repository.
Turns out that's not possible without an organization, and creating an org now routes
through a billing screen even for a project that would qualify as free/OSS. #2180
asked for this back in 2021 and got closed a few days ago pointing to Organization
Access Tokens, but OATs need an org, so personal accounts are still stuck with a
single account-wide token.
Two ways this could get fixed:
- Extend the new GitHub Actions OIDC connections to personal accounts, at least when
both the GitHub repo and the Docker Hub repo are public. That's no extra risk for
Docker since the content is already public, and it's the more secure fix: no
long-lived token sitting in a secret at all, versus a scoped-but-still-static one.
- Let personal accounts create scoped tokens for one repo, without requiring an org.
Second-best if OIDC parity isn't feasible, but still just a smaller blast radius,
not the removal of a long-lived credential.
Also worth flagging: the permission model itself is stacked, not fine-grained. It's
read-only, read+write, or read+write+delete. There's no way to grant "push only"
without also granting read. A CI job that just publishes shouldn't need read access as
a side effect.
Happy to help test this if it moves.
Related: #2180, #2314
Ran into this publishing an open source image (rsync-crypt) to Docker Hub. The project
already publishes to GHCR under a per-repo GitHub token. Wanted the same on Docker Hub:
a CI credential that can only touch one repository.
Turns out that's not possible without an organization, and creating an org now routes
through a billing screen even for a project that would qualify as free/OSS. #2180
asked for this back in 2021 and got closed a few days ago pointing to Organization
Access Tokens, but OATs need an org, so personal accounts are still stuck with a
single account-wide token.
Two ways this could get fixed:
both the GitHub repo and the Docker Hub repo are public. That's no extra risk for
Docker since the content is already public, and it's the more secure fix: no
long-lived token sitting in a secret at all, versus a scoped-but-still-static one.
Second-best if OIDC parity isn't feasible, but still just a smaller blast radius,
not the removal of a long-lived credential.
Also worth flagging: the permission model itself is stacked, not fine-grained. It's
read-only, read+write, or read+write+delete. There's no way to grant "push only"
without also granting read. A CI job that just publishes shouldn't need read access as
a side effect.
Happy to help test this if it moves.
Related: #2180, #2314