Gitlab authentication with glab | Dagger | Page 1

turbid crane Jun 20, 2025, 10:38 AM

#

Hey, next step in getting Dagger running alongside our Gitlab runners. Used glab for auth on the instance that the Dagger engine is running on. If I exec into that instance and run sudo glab auth status I get:

gitlab.com
  ✓ Logged in to gitlab.com as <name> (/root/.config/glab-cli/config.yml)
  ✓ Git operations for gitlab.com configured to use https protocol.
  ✓ API calls for gitlab.com are made over https protocol.
  ✓ REST API Endpoint: https://gitlab.com/api/v4/
  ✓ GraphQL Endpoint: https://gitlab.com/api/graphql/
  ✓ Token: **************************

I can double-check that with sudo glab api user which returns a json object of my user as expected.

Dagger however doesn't seem to have access to that authentication:

▼ detect module: https://gitlab.com/path/to/module.git 1.1s ERROR
! failed to resolve git src: failed to resolve git src: select: cannot resolve "https://gitlab.com/path/to/module.git": git error: exit status 128
  stderr:
  remote: HTTP Basic: Access denied. If a password was provided for Git authentication, the password was incorrect or you're required to use a token instead of a password. If a token was
  provided, it was either incorrect, expired, or improperly scoped. See https://gitlab.com/help/topics/git/troubleshooting_git.md#error-on-git-fetch-http-basic-access-denied
  fatal: Authentication failed for 'https://gitlab.com/path/to/module.git/'

These docs (https://docs.dagger.io/api/remote-repositories/#https-authentication) are a little slim, but I think I've followed them as intended?

Note: I'm on an EC2 using Session Manager (which is why I'm using sudo). The Dagger Engine (and all setup steps beforehand) are run as part of userdata as root, and do not use sudo. Dagger is running on the instance and accessible:

#

(I think I need to rethink where Dagger (on the instance) is installed... The glab config file is owned by root but I'm running the Dagger CLI as ssm-user)

#

If I sudo Dagger and try to use a private repository module I get the same git error, so that doesn't seem like the issue here

stone hull Jun 20, 2025, 7:44 PM

#

turbid crane Hey, next step in getting Dagger running alongside our Gitlab runners. Used `gla...

the credential manager (https://docs.dagger.io/api/remote-repositories/#credential-manager-configuration) section apply when you're calling dagger from the client side. The fact that you're running those commands in the dagger engine server doesn't have any effect.

turbid crane Jun 20, 2025, 10:16 PM

#

Is my understanding of that page incorrect? I took that to mean that if the instance the engine is running on is authenticated with Gitlab that the engine would be too?

stone hull Jun 20, 2025, 10:34 PM

#

turbid crane Is my understanding of that page incorrect? I took that to mean that if the inst...

so when the page mentions "Dagger uses your system's configured Git credential manager. This means if you're already authenticated with your Git provider, Dagger will automatically use these credentials when needed.", it doesn't specify if it's the client or the server.

As I've clarified above, all the information on that page applies only to the client (where the dagger call is being made)

#

We'll make sure to improve that. Thx for bringing that up

#

cc @river veldt

turbid crane Jun 20, 2025, 10:36 PM

#

So if I want to run dagger -m <module in private repository> -c 'function' the gitlab runner needs to be authenticated with Gitlab via ssh or https, not the dagger engine instance.

stone hull Jun 20, 2025, 10:36 PM

#

turbid crane So if I want to run `dagger -m <module in private repository> -c 'function'` the...

yes, exactly

turbid crane Jun 20, 2025, 10:41 PM

#

I'll test it further on Monday, though for Dagger to be seamless is there not a way I can authenticate the engine instance so that users don't have to care about this and can just call any Dagger modules in their pipelines?

#

It also doesn't answer why the engine instance, in a user session authenticated with glab auth login, couldn't dagger call a private module. I'll retest that on Monday and summarise my results

stone hull Jun 20, 2025, 10:47 PM

#

not a way I can authenticate the engine instance so that users don't have to care about this and can just call any Dagger modules in their pipelines?

No, not currently. This is the same approach as other tools like Docker uses with Dockerfiles for example. There's currently no way to setup Docker so the engine is automatically authenticated against a private repo.

Setting a global auth at the engine side has a lot of drawbacks and side-effects. We decided to go with the usual approach where clients are the one who provide the right credentials for each of the pipelines that they need to run

#

It also doesn't answer why the engine instance, in a user session authenticated with glab auth login, couldn't dagger call a private module. I'll retest that on Monday and summarise my results

this is simply not supported

river veldt Jun 21, 2025, 2:49 PM

#

stone hull cc <@1013436980249505882>

Thanks Marcos - I'm away for the next couple of weeks, could you please open an issue and assign to me and I'll fix on return? Thanks!

turbid crane Jun 22, 2025, 9:03 AM

#

Not sure I explained that one well Marcos. If I session manager into the ec2 running the engine (and exposed with the _EXPERIMENTAL.. env var = tcp:...) and I glab auth then use the Dagger cli to run dagger -m <private repository> -c <function> it sounds like that should work? I'm authed with gitlab, I'm the client calling the engine... Perhaps I still don't understand how this works

turbid crane Jun 23, 2025, 9:40 AM

#

Progress on private repos, could do with some details on PAT / job token usage.

SSH auth locally: I can clone the repo with git clone, I can dagger -m git@gitlab.com:<org>/path/to/repo.git -c '<>' all fine ✅

HTTPS auth locally: glab auth status all good, I can dagger -m https://gitlab.com/<org>/path/to/module.git -c '<>' all fine ✅

First question: Now here is where it gets weird. I've logged out of glab, deleted the config.yml file it generates, and can still dagger -m https://gitlab.com/<org>/path/to/module.git -c '<>' and it works? I expected this to fail - I've not provided any auth now?

I'd like to avoid users having to glab auth login in every job that requires Dagger however. Our current setup requires users to use CI_JOB_TOKEN to clone anything else they need in their pipeline - this is by design, the job token gets the permissions of triggering user, so we don't have to blanket allow other permissions anywhere. This would also remove the need to install the glab-cli in the image and provide some template with the login command.

Testing that:

HTTPS auth locally with token: glab auth status shows I'm logged out which is good for this test. dagger -m https://gitlab.com/<org>/path/to/module -c '<>' succeeded which I expected to fail, so I think the previous auth is somehow still available to the Dagger engine?

HTTPS auth in runner worker with token fails: Neither https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.com or https://oauth2:${CI_JOB_TOKEN}@gitlab.com allows access to the private repository.

Second question: Is PAT/Job token auth just not possible ~~yet~~ without git credential manager?

turbid crane Jun 23, 2025, 1:38 PM

#

To follow-up on this, the Dagger engine apk isn't playing at all, so to have the glab-cli available in my gitlab pipelines I've got to create an image of my own based on the Dagger engine image and maintain that?

turbid crane Jun 24, 2025, 10:01 AM

#

@stone hull I've reached a point where, in the gitlab runner, this part from your docs is false:

To verify if your credentials are properly configured, try cloning a private repository (replace the placeholders below with valid values):

git clone https://github.com/USER/PRIVATE_REPOSITORY.git

If this works, Dagger will be able to use the same credentials to access your private repositories.

#

  before_script:
    - git config --global credential.helper store
    - echo "https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.com" > ~/.git-credentials
    - cat ~/.git-credentials
  script:
    - git clone https://gitlab.com/path/to/dagger-module.git # Test if git can clone it
    - ls dagger-module/
    - dagger -m https://gitlab.com/path/to/dagger-module.git -c 'container-echo hello | stdout'

The git clone works, the ls shows the contents of the module. The dagger -m fails with an auth error.

#

I've also tried this (which is how we typically clone other repositories in pipelines). Same outcome: git clone works, dagger -m does not

- git clone https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.com/path/to/dagger-module.git # Test if git can clone it
- dagger -m https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.com/path/to/dagger-module.git -c 'container-echo hello | stdout'

unreal veldt Jun 24, 2025, 12:45 PM

#

@turbid crane moved answer here to avoid spamming general.

CI_JOB_TOKEN has limitted permissions, especially accessing other repositories. What I'm doing, cloneing repo using gitlab runner and only allow ssh access to internal daggerverse repo and use ssh socker to reach modules.

turbid crane Jun 24, 2025, 12:45 PM

#

The CI_JOB_TOKEN has been granted permission to clone that repository

#

git clone works fine, dagger -m does not

unreal veldt Jun 24, 2025, 12:47 PM

#

I think you need to look Git Credential Manager since dagger using it for auth. Probably it can't parse your url correctly

turbid crane Jun 24, 2025, 12:47 PM

#

I'm using GCM in the above. git config --global credential.helper store + echo "https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.com" > ~/.git-credentials

#

This works... with git clone, but not dagger -m

#

If I change the echo line to echo "https://gitlab-ci-token:${MY_PAT_TOKEN}@gitlab.com" > ~/.git-credentials this works for both git clone and dagger -m

#

So the sole difference is PAT vs CI_JOB_TOKEN

#

I'm guessing Dagger doesn't understand the difference

stone hull Jun 24, 2025, 3:22 PM

#

turbid crane If I change the `echo` line to `echo "https://gitlab-ci-token:${MY_PAT_TOKEN}@gi...

@turbid crane are you sure git clone is effectively using the CI_JOB_TOKEN when it works? I'm mostly asking this because from the engine perspective, the fact that you're using a CI_JOB_TOKEN or a MY_PAT_TOKEN shouldn't matter. The underlying mechanism to clone the repo should ultimately be the same

turbid crane Jun 24, 2025, 3:23 PM

#

I can quickly test further

turbid crane Jun 24, 2025, 3:43 PM

#

I'm quite sure it's working because this is how we clone repositories in all pipelines (albeit inline with https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.com). A quick search for that term in our org results in 138 instances of cloning this way.

Tested the Dagger job with no auth provided in the job (commented out before_script, no inline creds):

# before_script:
    # - git config --global credential.helper store
    # - echo "https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.com" > ~/.git-credentials
    # - cat ~/.git-credentials
  script:
    # - git clone https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.com/path/to/dagger-module.git 
    - git clone https://gitlab.com/path/to/dagger-module.git
    - ls dagger-module
    - dagger -m https://gitlab.com/path/to/dagger-module.git -c 'container-echo hello | stdout'

Results in:

$ git clone https://gitlab.com/path/to/dagger-module.git
Cloning into 'dagger-module'...
fatal: could not read Username for 'https://gitlab.com': No such device or address

Re-adding the before_script:

before_script:
    - git config --global credential.helper store
    - echo "https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.com" > ~/.git-credentials
    - cat ~/.git-credentials
  script:
    # - git clone https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.com/path/to/dagger-module.git # Test if git can clone it
    - git clone https://gitlab.com/path/to/dagger-module.git
    - ls dagger-module
    - dagger -m https://gitlab.com/path/to/dagger-module.git -c 'container-echo hello | stdout'

Results in:

$ git clone https://gitlab.com/path/to/dagger-module.git
Cloning into 'dagger-module'...
$ ls dagger-module
LICENSE
README.md
dagger.json
go.mod
go.sum
main.go

Then the Dagger job fails:

remote: HTTP Basic: Access denied. If a password was provided for Git authentication, the password was incorrect or you're required to use a token instead of a password.

#

For completeness sake, inline creds, commented out before_script:

# before_script:
  #   - git config --global credential.helper store
  #   - echo "https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.com" > ~/.git-credentials
  #   - cat ~/.git-credentials
  script:
    - git clone https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.com/path/to/dagger-module.git
    - ls dagger-module
    - dagger -m https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.com/path/to/dagger-module.git -c 'container-echo hello | stdout'

Results in:

$ git clone https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.com/path/to/dagger-module.git
Cloning into 'dagger-module'...
$ ls dagger-module
LICENSE
README.md
dagger.json
go.mod
go.sum
main.go

And the Dagger command fails again:

12  : ┆ ┆ ┆ ┆ git ls-remote --symref https://gitlab-ci-token@gitlab.com/path/to/dagger-module.git HEAD HEAD^{} ERROR [1.2s]
12  : ┆ ┆ ┆ ┆ ! git error: exit status 128
stderr:
remote: HTTP Basic: Access denied.

#

Git clone accepts both ~/.git-credentials and inline https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.com, Dagger accepts neither

#

@stone hull 👆 That's about as comprehensive as I can test, not sure what else I can do at this point... Feels like there's a Dagger bug somewhere?

stone hull Jun 24, 2025, 4:18 PM

#

cc @pulsar gate might have a better understanding about what could be happening here 🙌

turbid crane Jun 24, 2025, 8:37 PM

#

I'm happy to get on a screenshare if it helps figure out what's going wrong here, let me know!

wispy ore Jun 25, 2025, 7:29 PM

#

Hi @turbid crane
TL;DR: upgrade to v0.18.11
Long answer: In v0.18.11, an issue was fixed where the username for HTTP authentication was hard-coded to x-access-token. This was problematic because when using CI_JOB_TOKEN to access a repository, GitLab specifically requires gitlab-ci-token as the username. With v0.18.11, Dagger now supports passing the username from the git credential helper. Additionally, Dagger requires a credential helper—any inline authentication in the module's URL will be removed when the CLI passes the URL to the engine to prevent leaking secrets.

turbid crane Jun 25, 2025, 8:04 PM

#

I'll try it tomorrow morning and get back to you @wispy ore. I'm ok with credential helper being a requirement over inline creds if it's to keep secrets secret

#Gitlab authentication with glab