Skip to content

feat: introduce non-personalized service accounts#2456

Draft
pmig wants to merge 1 commit into
pmig/dev-425-account-rolefrom
pmig/dev-425-service-account
Draft

feat: introduce non-personalized service accounts#2456
pmig wants to merge 1 commit into
pmig/dev-425-account-rolefrom
pmig/dev-425-service-account

Conversation

@pmig
Copy link
Copy Markdown
Member

@pmig pmig commented May 21, 2026

Adds a ServiceAccount principal type that lives alongside UserAccount. Service accounts are non-interactive identities admins create within a vendor org (and optionally scoped to a customer org). Each can hold any number of access tokens that authenticate against the existing "AccessToken: distr-..." header path, so SDK and client code do not change.

Backend

  • New ServiceAccount and ServiceAccountAccessToken tables (migration 100) with vendor/customer-org scoping.
  • internal/types/service_account.go, internal/db/service_account*.go, internal/mapping/service_account.go, api/service_account.go.
  • AuthInfo gains CurrentServiceAccountID. SimpleAuthInfo carries a serviceAccountID, DbAuthInfo a *ServiceAccount.
  • FromServiceAccountAuthKey + UnifiedAuthKeyAuthenticator try user-PAT lookup first, fall back to SA-token lookup. Wired into both Authentication and ArtifactsAuthentication so OCI registry works.
  • BlockServiceAccount middleware for routes that must reject SA tokens.
  • /api/v1/service-accounts CRUD + per-SA /tokens, admin-only via RequireAdmin + BlockSuperAdmin + BlockServiceAccount. Customer-org scoping enforced in handlers and middleware.

Frontend

  • SDK ServiceAccount types.
  • ServiceAccountsService + ServiceAccountsComponent (table below users on both vendor and customer-users pages, admin-only).
  • ServiceAccountDetailComponent at /users/service-accounts/:id for inline name/role edit and token management.
  • Extracted AccessTokensTableComponent shared between the personal PAT page and the SA detail page (removes duplication).

Docs

  • website/.../integrations/service-account.md describing creation, admin gating, customer scoping, and curl/OCI usage.

Adds a ServiceAccount principal type that lives alongside UserAccount.
Service accounts are non-interactive identities admins create within a
vendor org (and optionally scoped to a customer org). Each can hold any
number of access tokens that authenticate against the existing
"AccessToken: distr-..." header path, so SDK and client code do not
change.

Backend
- New ServiceAccount and ServiceAccountAccessToken tables (migration
  100) with vendor/customer-org scoping.
- internal/types/service_account.go, internal/db/service_account*.go,
  internal/mapping/service_account.go, api/service_account.go.
- AuthInfo gains CurrentServiceAccountID. SimpleAuthInfo carries a
  serviceAccountID, DbAuthInfo a *ServiceAccount.
- FromServiceAccountAuthKey + UnifiedAuthKeyAuthenticator try user-PAT
  lookup first, fall back to SA-token lookup. Wired into both
  Authentication and ArtifactsAuthentication so OCI registry works.
- BlockServiceAccount middleware for routes that must reject SA tokens.
- /api/v1/service-accounts CRUD + per-SA /tokens, admin-only via
  RequireAdmin + BlockSuperAdmin + BlockServiceAccount. Customer-org
  scoping enforced in handlers and middleware.

Frontend
- SDK ServiceAccount types.
- ServiceAccountsService + ServiceAccountsComponent (table below users
  on both vendor and customer-users pages, admin-only).
- ServiceAccountDetailComponent at /users/service-accounts/:id for
  inline name/role edit and token management.
- Extracted AccessTokensTableComponent shared between the personal PAT
  page and the SA detail page (removes duplication).

Docs
- website/.../integrations/service-account.md describing creation,
  admin gating, customer scoping, and curl/OCI usage.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant