Skip to content

Documentation for service accounts #1184

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 5 commits into from
Jun 23, 2025
Merged
Show file tree
Hide file tree
Changes from all 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
1 change: 1 addition & 0 deletions docs/admin/access_control/index.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -42,6 +42,7 @@ You can read about the specific permission types available for each RBAC-enabled

- [Batch Changes](/admin/access_control/batch_changes)
- [Ownership](/admin/access_control/ownership)
- [Service accounts](/admin/access_control/service_accounts)

### Deleting a role

Expand Down
51 changes: 51 additions & 0 deletions docs/admin/access_control/service_accounts.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,51 @@
# Service Accounts

Service accounts are specialized user accounts designed for automation, API integrations, and programmatic access to Sourcegraph, as opposed to using access tokens from regular users. Unlike regular user accounts, service accounts don't require an email address or password, cannot access the Sourcegraph UI, don't count towards a license's user limit and won't be part of any billing cycles.

## Creating Service Accounts

Service accounts are created like regular user accounts, but with a few key differences.

- Go to **Site admin** → **Users & auth** → **Users**
- Click **Create User**
- Enter a descriptive **Username** (e.g., `ci-bot-scip-uploads`, `api-search-jobs`)
- Check the **Service account** checkbox
- Click **Create service account**

Choose a reason for hiding this comment

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

Not a judgement but do our users need that level of detail? Or is our user creation flow that bad?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't think our user creation flow is particularly bad, it's pretty straightforward. This has just kinda been the default mode of docs writing 🤷‍♂️ perhaps it's a bad practice, and just saying "you can create them here" is good enough


You'll be presented with some next steps you might want to take, like creating an access token, managing and assigning roles, and managing repository permissions.

- Service accounts are automatically assigned the "Service Account" system role
- They appear in the user list with "Service account" type designation
- By default, service accounts can only access public and unrestricted repositories

## Managing Access Tokens

Service accounts authenticate using access tokens rather than passwords. For detailed information about creating, managing, and using access tokens, see:

- [Creating an access token](/cli/how-tos/creating_an_access_token)
Copy link
Member

Choose a reason for hiding this comment

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

ugh, why do these docs live under cli 😆 is that the only access token documentation we have? (sigh)

- [Managing access tokens](/cli/how-tos/managing_access_tokens)
- [Revoking an access token](/cli/how-tos/revoking_an_access_token)

Use service account access tokens to access Sourcegraph's [GraphQL API](/api/graphql).

## Role-Based Access Control (RBAC)

Service accounts integrate with Sourcegraph's [role-based access control](/admin/access_control) to provide fine-grained permission control.

### System Roles

Service accounts are automatically assigned the **Service Account** system role, which provides basic API access permissions and standard search capabilities. The **Service Account** system role is applied to all service accounts and can be used to provide service accounts with a default set of permissions. For more specialized service accounts, it is recommended to create custom roles and assign them to service accounts as needed.

### Managing Roles

Administrators can assign additional roles to service accounts through the user management interface. For detailed information on managing roles and permissions, see:

- [Managing roles and permissions](/admin/access_control#managing-roles-and-permissions)
- [Managing user roles](/admin/access_control#managing-user-roles)
- [Creating custom roles](/admin/access_control#creating-a-new-role-and-assigning-it-permissions)

## Repository Permissions

Service accounts respect repository permissions and access controls. For comprehensive information about repository permissions, see the [Repository permissions](/admin/permissions) documentation.

Service accounts by default can only access public and unrestricted repositories in Sourcegraph. You may explicitly grant fine-grained access to private repositories from the service account's user settings page, under the **Repo permissions** tab, or via [the GraphQL API](/admin/permissions/api#explicit-permissions-api). In the **Repo permissions** tab, you can also grant service accounts access to all current and future repositories on Sourcegraph, regardless of their visibility, which is useful for service accounts that need to do things like perform search jobs, but admins should take care to ensure that the access tokens for these accounts are not shared with unauthorized users.
4 changes: 4 additions & 0 deletions docs/admin/auth/index.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -29,6 +29,10 @@ The following methods are supported for sign up and sign in:

The authentication providers are configured in the [`auth.providers`](/admin/config/site_config#authentication-providers) site configuration option.

## Programmatic authentication

For automated systems, CI/CD pipelines, and API integrations that need to authenticate without human interaction, use [service accounts](/admin/access_control/service_accounts). Service accounts are specialized user accounts designed for automation that authenticate using access tokens rather than passwords.

## Login form configuration

To configure the presentation of the login form, see the [login form configuration page](/admin/auth/login_form).
Expand Down
2 changes: 2 additions & 0 deletions docs/api/graphql/index.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -32,6 +32,8 @@ You should see a response like this:
{ "data": { "currentUser": { "username": "YOUR_USERNAME" } } }
```

For automated scripts, CI/CD pipelines, and production integrations, use [service accounts](/admin/access_control/service_accounts) instead of personal access tokens. Service accounts are designed specifically for programmatic API access and provide better security and audit capabilities.

## Documentation & tooling

### API Console
Expand Down