GitLab connector

Lets a workload reach the GitLab API without the token ever entering the sandbox.

lns connector install lenshq/gitlab

What it serves

gitlab.com — GitLab SaaS, whose REST API lives at gitlab.com/api/v4 and whose GraphQL endpoint is on the same host.

Self-managed GitLab is not served. Its API is on the customer's own hostname, so it needs its own connector with that host in serves.

How you sign in

Three methods. Pick one when lns asks.

GitLab account — browser sign-in. lns opens GitLab, you approve, and the token comes back to a loopback listener on 127.0.0.1. This is the default choice when a browser can reach this machine.

GitLab account, by code — lns shows a short code, you enter it at https://gitlab.com/oauth/device, and GitLab hands the token back. Nothing listens on a port, so this works over SSH and on a headless host.

Personal access token — create one at https://gitlab.com/-/user_settings/personal_access_tokens and paste it.

Both sign-in methods offer read-only (read_api) or read and write (api).

What the workload sees

The value is a marker, not a credential: lns substitutes the real token into the Authorization: Bearer header of requests to gitlab.com and nowhere else.

GitLab's own documentation prefers a PRIVATE-TOKEN header, but the same page confirms a personal access token also works as a bearer token, which is the form this connector uses.

The variable is lent to a sandbox that declares it, so a sandbox asking for nothing receives nothing.

What it grants

Requests to gitlab.com only. Installing the connector grants nothing on its own — the destination still has to be allowed, and connecting the account is what allows it.

Note that gitlab.com is the web host as well as the API host, so allowing it allows more than the API.

A pasted token's scope is its own business — lns does not narrow a token it was handed. Either sign-in method is narrower, because the scope you pick is the scope GitLab issues.