#Auth token expiration and refresh in longer pipelines

1 messages · Page 1 of 1 (latest)

leaden cargo
#

Wanted to re-up this topic. We are still facing this issue. It's not a roadblock per se, but I think it may be the straw that breaks the camel's back when we try to pitch this to the broader team.

Context: #1313575783721078847 message

tired drift
leaden cargo
#

I figured something like that. I'm in the process of writing up our "sales" pitch to the broader team. There is a workaround, but it goes against what we are proposing

tired drift
#

one thing that might work as a stopgap is to use the dag.Container().WithRegistryAuth call just before calling publish so you can re-authenticate to the registry. Any chance you can use that API?

leaden cargo
#

I believe that is something I can try. Does that work on the From side as well?

#

we hit pull errors as well for base images we host internally

tired drift
#

so you can say dag.Container().WithRegistryAuth().From()

leaden cargo
#

cool, I'll give this a try and report back

tired drift
#

🙏 thx. Apologies for the delay

leaden cargo
#

no worries, y'all are very above average on support

tired drift
#

we need an AI bot to automatically open GH issues based on Discord threads 😄 cc @drowsy plover @rotund bluff

leaden cargo
#

We currently use the credsHelper setting and service account based keyless IAM on GCP, so we don't really have a username, or more so secret, to pass to WithRegistryAuth()

#

Is there a GraphQL query we could send to the engine to force refresh auth?

tired drift
#

so you can use the IAM SA and get a token for that account

#

I'd assume it's similar to what the credHelper is doing

tired drift
leaden cargo
#

I should just need the gcloud part in the exec, and the WithRegistryAuth is the docker part after the pipe. Does that sound right?

tired drift
leaden cargo
#

and if I do this before Publish, then I probably won't need to before From because I will be refreshing often enough

#

I can probably use Go exec and make the call outside of the Dagger context, then turn the output into a Dagger secret

tired drift
leaden cargo
#

I'm not seeing the publish logs in the trace, nor the images in the registry. Not getting an error (as of yet in the logs)

Should "address" argument be us.gcr.io, us.gcr.io/<repo>, or the full image URI?

tired drift
#

haven't tried it myself but according to the docs it should be https://$location.gcr.io?

#

LMK if it doesn't work and I can check really quick 🙏

leaden cargo
#

will do, just pushed a commit that should ideally be correct according to docs and such

leaden cargo
#

FYI for anyone else that may come along, this only works for GAR, not GCS (:whispers: which we still have yet to migrate...)

leaden cargo
tired drift
#

yes, this works:

func (m *Lala) Test(ctx context.Context, src *dagger.Directory) *dagger.Container {
    token := dag.SetSecret("foo", "$TOKEN")
    dag.Container().WithRegistryAuth("registry.docker.io", "$USER", token).Sync(ctx)
    return src.DockerBuild()
}
leaden cargo
#

oh, you just do it as an out-of-band kind of thing with sync?

#

it might also be that I need to auth multiple registries

tired drift
tired drift
leaden cargo
#

It seems the issue is that GCP is no longer accepting this auth setup with GCR, only GAR

I'm still getting the failed to authorize: failed to fetch oauth token: unexpected status from POST request to https://us.gcr.io/v2/token: 404 Not Found for GCR pulls, while the pushes to GAR now work as expected

small nebula
#

Hi @leaden cargo I'm excavating an old thread, did you end up writing the sales pitch ? I'm currently writing one focused on solving pain points and the business outcome of using dagger for a software company

leaden cargo
#

It encompasses a lot more than Dagger

#

Generally the problem is that we have accrued a lot of little tech debt and are suffering from thousands of paper cuts, the proposal is a single-source-of-truth (CUE) and shared implementation (GoCLI+DaggerSDK)

#

(glossing over a lot of stuff)

#

I would refer to it more as a Proposal & RFC than what one might thing of as a sales pitch. I have to convince the developers this is a good idea, mainly by reminding them of the little pains they experience a few times a year and end up pinging devops in slack about

#

Dagger is a big piece of the solution, but because of framework burnout, we are emphasizing the problem more than the implementation details, and painting a vision for what could be (which is more where Dagger comes in)

#

I am happy to talk about the wins we have seen and specific places I'm planning to use Dagger. Maybe we should start a new post?

#

I'll do that now

small nebula
#

thanks !

#

please tag me in the new thread

leaden cargo
leaden cargo
#

@tired drift I finally got back to this and am seeing 405 for Google Artifact Registry from Dagger

container.from.withFile.withFile.withExec.withFile.withDirectory.withFile.withEntrypoint.withAnnotation.withAnnotation.withRegistryAuth.publish resolve: failed to export: failed to push us-central1-docker.pkg.dev/<registry>/<image>:<tag>: failed to authorize: failed to fetch oauth token: unexpected status from POST request to https://us-central1-docker.pkg.dev/v2/token: 405 Method Not Allowed
#

I can get you trace ids from the Dagger UI it that helps as well

leaden cargo
#

It is also known that the underlying host can push images with docker to the same registry