Here.

I was baffled by this as well. Does the workaround I provided below work for you?

If you're using self-hosted runners, use the container.hooks to pre-auth yourself.

https://github.com/orgs/community/discussions/45981#discussioncomment-8025062

If you're using GitHub-hosted runners, this model can still work you just have to build the composite action in such a way that you can authorize to the docker registry before the image is pulled. See the same linked comment for insights into that with an example.

I know, and thanks for investigating and documenting the workarounds!

But my point is, this feature must be provided by GH out-of-the-box

Especially now that I had a look a the runner and hook code + ADR.

The implementation is 90% there, the only thing missing is adding fields for username and password in the action metadata syntax.

Let's look at the runner first

• Internal DTOs for container-based actions already have fields username and password of the registry
• Before pulling the image, login if fields are set
  • to a temporary/throwaway config.json
• pull image using temp config.json
  • which explains why a regular docker login to the private registry as a step in the job doesn't work. The runner doesn't use the default docker comfig.json to pull the image.
• delete temp comfig

But here comes the rub:

Because MSFT is being MSFT, username and password are only ever set for ghcr.io, with some GH-internal credentials (?) to make it work seamlessly and increase vendor lock-in.

I guess thats also the reason for using a temp config.json to pull: to prevent leaking those credentials. But why not do something like

IF credentials_provided(registry) THEN
 temp-config.json = docker_login(registry) 
 docker ---config temp-config.json pull ...
ELSE
 docker pull ....

instead?
At least then the behaviour would be consistent with using a Dockerfile for your action. Runner and hook simply execute docker build , without flag --config

Next, hooks:

• Schema for container hooks already defines fields for username/password
• Reference hook implementation performs the same logic I described above for pulling the image of the action
• but: same limitation applies: the fields are only populated for ghcr.io

Seriously, how hard can it be to add optional fields for user/pass of the registry to the action schema. They did it for jobs and services already.

Many great points here. My opinion is that requiring authentication for private registry Actions may be a slippery slope, at least from an open-source perspective. It would probably only work behind a paid GitHub tier. You wouldn't want to attempt to consume a public Action and find out there's an auth barrier to even attempt to run it.

Agreed, if your action is open source and/or on the action marketplace, it must "just work".

But my focus is on paid tiers like you mentioned, specifically GH Enterprise. Here I see it as missing "table stakes".

It would have to be a public ghcr image. Assuming yours is private, you would have to do one of the workarounds mentioned here to provide authentication.

TLDR, to provide authentication, you can:

1. pre-auth in self-hosted runner environment ahead of time
2. use a pre-step job/task in Actions to run logic before every job
3. use a composite action to hide the docker action and pre-auth before it runs - this would work with github-hosted runners

From an open source / marketplace perspective, having public actions gated around requiring docker creds would be somewhat of a slipper slope, but I do agree for enterprise customers it makes things a touch trickier.

<vent><rant>

Thanks for the reply, @joshjohanning , I appreciate the documentation you've provided in this thread. It is very helpful. Authentication is a hard problem and I definitely see how it's even harder at GitHub scale.

Unfortunately the reality of the user experience for a quick and dirty proof of concept is that it's bad. I'm trying to get something working to show the team it is possible. My use case is a pre-alpha-v0.0.1 candidate throw-away hello world example. I don't have the time to set up the authentication scaffolding for self-hosted runners. I have to tip-toe around new things because my team is very skeptical of changing things that already work. I have not built the necessary consensus with the team to put it on the roadmap as a solution to issues that the team is happy to ignore for now but have been and will continue to be nagging problems.

One would think a GitHub git repo could have an easy path to authenticate with a GitHub ghcr.io package repo that's created by the same user under the same account with the same credentials.

"Just make it public" is not a reasonable default for users doing work for an employer. I'd even argue it is a bad default for users working on their own but that's besides the point.

Maybe I'll try for option 3. Or use my personal GitHub account. Neither option compares well with what would be the path of least surprise which would be for my git repo to auth with its eponymous ghcr.io package repo.

</vent></rant>

permissions are just what types of resources inside of a repository that a particular workflow can access. The permissions on the package could potentially work, but there are still no "docker login" running ahead of time to authenticate to the container registry in order for the container to be pulled.

See another response here https://github.com/orgs/community/discussions/45981#discussioncomment-10163954

Awesome! No, sadly you cannot set it from the workflow side :(. That's why the solution only supports self-hosted runners, you have to set it on the .env file on the runner such that the environment variable exists before the job starts.

@joshjohanning are there any plans to build a feature to pull private package repos in workflow job steps? Particularly from GHCR?

@zachspar sadly nothing on the public roadmap for this :(

Having same issue , when I call same action from market place action it pulls image from docker hub and working , when I clone the same repo to org goin account and point to jfrog image it’s failing with authentication needed though I am passing the auth step any one found fix ?

Workaround are ok, but in the end GitHub Actions should support it natively to be able to use a private regsitry requiring authentication.

I have two more workarounds / solutions to share:

7. Using a composite Action you can sort of bury the Docker action by making it a local action (cloning the docker action repo and running it from a local directory). Then, it won't auth to Docker at the beginning of the job and you can auth to docker yourself before that action runs. There are 2 examples of this in this repo.
8. Use Container Hooks
   • Example code
   • Example action being ran
   • Using container hooks with self-hosted runners would allow you to customize how docker actions are referenced, therefore being able to inject docker auth logic without the end-user having to do it themselves in the action workflow.

For those finding this comment later, I wrote on points 7 and 8 in a blog post here.

Your point 7 could work with an image already built but it will not work with a Dockerfile (when the param image is like image: "Dockerfile").

I tried # 4, and it was a terrible experience (because GH handles so much out of the box vs calling docker run ourselves).

I ended up accidentally discovering this workaround (just run a docker pull ahead of time), which was much simpler.

@tremblaysimon: I think it might work for you too (with a Dockerfile). 🤞

Still an issue.