Skip to content

Release Bot: determine Concourse authentication strategy for API job triggering #4491

Description

@blarghmatey

Description/Context

The release bot (ol-infrastructure#4485) needs to trigger Concourse jobs programmatically via the Concourse REST API:

POST /api/v1/teams/{team}/pipelines/{pipeline}/jobs/{job}/builds
Authorization: Bearer {token}

The correct authentication strategy depends on how Concourse is configured for the mitodl team. This issue tracks resolving that question and provisioning the appropriate credentials.

The two paths forward:

Option A — Concourse local service account
If local users are enabled (i.e., Concourse is not configured as SSO-only), create a dedicated local user release-bot with scoped permissions (trigger jobs; no pipeline configuration access). Store credentials in Vault; the release bot exchanges username+password for a bearer token on startup.

fly -t mitodl set-team --team-name main   --local-user release-bot   --role member

Option B — Concourse webhook token (fallback)
If local accounts are unavailable, use Concourse's webhook token mechanism to trigger resource checks, which in turn trigger jobs:

POST /api/v1/teams/{team}/pipelines/{pipeline}/resources/{resource}/check/webhook?webhook_token={token}

The webhook token is set per-resource in the pipeline YAML (webhook_token: ((release_webhook_token))) and stored in Vault. This is simpler but less flexible — it triggers a resource check rather than a job directly, which means the pipeline must be structured so that the release job is triggered by a resource check (which is already the intended design for the resources/release resource).

Option C — GitHub Actions OIDC / Concourse OIDC
If Concourse is configured with an OIDC provider, a short-lived token could be issued for the release bot's service account. This is the most secure option long-term but requires OIDC support to be confirmed and configured.

Plan/Design

  1. Confirm which auth mechanisms are enabled on the mitodl Concourse instance (check docker-compose.yml or Helm values in ol-infrastructure)
  2. If Option A is viable: provision a release-bot local user; store credentials in Vault at the agreed path; update release_bot/__main__.py to read and use them
  3. If Option B is required: document the webhook token approach; ensure all release pipelines include webhook_token: ((release_webhook_token)) on the release resource; update the release bot's /release [app] handler to POST to the check webhook endpoint instead of the jobs endpoint
  4. Update ol-infrastructure#4486 (release bot scaffolding) with the chosen approach once resolved

Resolves open question #12 from the release management plan.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions