Skip to content
Merged
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
88 changes: 88 additions & 0 deletions docs/docs/run_minder_server/config_gitlab_oauth.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,88 @@
---
title: Create a GitLab OAuth application
sidebar_position: 75
---

## Prerequisites

- [GitLab](https://gitlab.com) account
- A [local Minder server](run_the_server) running with the `gitlab_provider`
feature flag enabled (see [Using feature flags](../developer_guide/feature_flags))

## Steps

1. Create a GitLab OAuth application. GitLab supports three ownership levels —
choose the one that fits your setup:

- **User-owned:** Go to [User Settings > Applications](https://gitlab.com/-/user_settings/applications)
- **Group-owned:** Go to your GitLab group → **Settings** → **Applications**
- **Instance-wide:** Go to **Admin Area** → **Applications** (self-managed only)

2. Click **Add new application** and enter the following details:
- **Name:** `Minder` (or any name you prefer)
- **Redirect URI** (add both URIs, one per line):
```
http://localhost:8080/api/v1/auth/callback/gitlab/cli
http://localhost:8080/api/v1/auth/callback/gitlab/web
```
- **Confidential:** Yes (checked)
- **Scopes:** Check `api`, `read_user`, and `read_repository`

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need write_repository to be able to create branches for PR remediations?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about read_registry for artifacts? I'm guessing the GitLab provider doesn't yet support the container / artifact provider facet...

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need write_repository to be able to create branches for PR remediations?

Not needed currently — the GitLab provider doesn't yet implement PR remediation or branch creation. I'll leave it out for now and it can be added when that's implemented.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about read_registry for artifacts? I'm guessing the GitLab provider doesn't yet support the container / artifact provider facet...

Correct — artifact/container registry support isn't implemented in the GitLab provider yet. Leaving it out of the minimum required scopes

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should read_user be openid or profile?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

("profile") worked for me for registering a repository using the OAuth flow. As mentioned, the service account flow seems to be broken for GitLab, so we'll need a separate PR for that (which may also want to add user documentation for registering a GitLab repository, with best practices).

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch — updating to profile as you confirmed it works. read_user gives broader access than needed.


3. Click **Save application**. Copy the **Application ID** and **Secret** — the
secret is only shown once.

4. Add the following to your `server-config.yaml` under the `provider:` section:

```yaml
provider:
gitlab:
client_id: "YOUR_APPLICATION_ID"
client_secret: "YOUR_SECRET"
redirect_uri: "http://localhost:8080/api/v1/auth/callback/gitlab"
webhook_secret: "a-random-secret-string"
scopes:
- "api"
- "read_user"
- "read_repository"
```

The `redirect_uri` should be the base path without `/cli` or `/web` — Minder
appends the correct suffix automatically.

5. Enable the `gitlab_provider` feature flag by creating `flags-config.yaml` in
the root of your Minder directory:

```yaml
gitlab_provider:
variations:
enabled: true
disabled: false
defaultRule:
variation: enabled
```

6. (Re)start the Minder server:

```bash
make run-docker
```

7. Enroll the GitLab provider using the CLI:

```bash
minder provider enroll --class gitlab
```

A browser window will open to GitLab's OAuth authorization page. After
authorizing, the browser will show **Minder enrollment complete** and the CLI
will print `Provider enrolled successfully`.

## Known limitations

- GitLab support is currently only available on self-hosted Minder instances.
The hosted instance at `api.custcodian.dev` does not yet support GitLab
enrollment.
- Webhook-based event delivery requires an externally reachable URL. For local
development, tools like [ngrok](https://ngrok.com) can expose your local
server.
- Token identity verification after enrollment is not yet implemented.