-
Notifications
You must be signed in to change notification settings - Fork 65
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
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** | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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? There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 | ||
pjlast marked this conversation as resolved.
Show resolved
Hide resolved
|
||
- 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) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ugh, why do these docs live under |
||
- [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. |
Uh oh!
There was an error while loading. Please reload this page.