search

moby / buildkit

concurrent, cache-efficient, and Dockerfile-agnostic builder toolkit
https://github.com/moby/moby/issues/34227
Apache License 2.0
8.23k stars 1.17k forks source link

Allow scoping registry auth to inner gateway Solve call, or llb #2472

Open shykes opened 3 years ago

shykes commented 3 years ago

Currently registry authentication is scoped to the top-level Solve call, via session/auth.AuthServer. I believe it’s not currently possible to scope it to inner frontend/gateway/client.Solve: all those calls implicitly inherit the global auth state from the current session. Would it be possible to add support for such finer-grained scoping of registry auth? This would solve a headache for us on Dagger…

The headache in a nutshell: in a typical Dagger configuration, registry credentials are not necessarily loaded from the client machine. For all registries that require auth helpers (ECR, GCR, etc.), those helpers are executed in containers inside the buildkit DAG. In other words, the registry credentials are produced dynamically via llb/gateway solve calls, and therefore it would be more natural (and less surprising to developers) if those credentials could be either attached to the llb state, or resolved by a callback passed in gateway/client.Solve, so that different parts of the DAG could be solved with different credentials. Those 2 solutions would be equivalent in practice.

I believe this would be a valid (and pretty cool) use case not limited to Dagger. Why limit ourselves to executing auth helpers on the client machine, when we could execute them in containers? :)

Sorry if this is not clear.

tonistiigi commented 3 years ago

I think adding the credentials to LLB should be fine for this case. They should probably not count for the digest though(you can try to change my mind on it) and that means that parallel pull with the same image would reuse the credentials from another build.

So design-wise I don't see big problems. Depends if this can be implemented relatively cleanly without adding lots of complexity everywhere.

or resolved by a callback passed in gateway/client.Solve,

That seems quite complicated as there is no callback channel there. The session code does not connect to gateway/client.Solve,, only client.Solve/Build.