feat(ol-analytics-api): deliver the MITx Online OAuth2 client credentials

[blarghmatey]

What are the relevant tickets?

Related: https://github.com/mitodl/hq/issues/10594 (this wiring is deleted once that lands)

Description (What does it do?)

Delivers the MITx Online OAuth2 client-credentials pair to the ol-analytics-api pod, so its org-manager check can authenticate with its own service token rather than forwarding the caller's identity (mitodl/ol-analytics-api#22, against the new endpoint in mitodl/mitxonline#3807).

Unlike SENTRY_DSN — which the sentry stack owns end to end — no Pulumi stack owns these values. The OAuth2 Application record is created by hand in MITx Online's Django admin.

So the vault-secrets-operator reads secret-operations directly at runtime and templates the values into the env var names the app expects, exactly as applications/marimo_data does for its OIDC client pair:

mitxonline_oauth_secrets = OLVaultK8SSecret(
    resource_config=OLVaultK8SStaticSecretConfig(
        mount="secret-operations",
        mount_type="kv-v1",
        path="ol-analytics-api/mitxonline-oauth",
        includes=["client_id", "client_secret"],
        templates={
            "OL_ANALYTICS_API_B2B_DASHBOARD_MITXONLINE_CLIENT_ID": '{{ get .Secrets "client_id" }}',
            "OL_ANALYTICS_API_B2B_DASHBOARD_MITXONLINE_CLIENT_SECRET": '{{ get .Secrets "client_secret" }}',
        },
        ...

The resulting Secret is added to the Deployment's env_from_secret_names alongside the existing static-secrets one.

The credential never passes through Pulumi state, and rotating it is just a new value in Vault — the operator picks it up on its own refresh, with no pulumi up in the loop.

One consequence worth a reviewer's attention: VSO reads that path using the application's Vault role, not the deploying operator's credentials, so ol_analytics_api_policy.hcl now grants read on it. secret-operations is kv-v1, so there's no /data/ sub-path to grant alongside.

How can this be tested?

pulumi preview on CI/QA. Expected: one new VaultStaticSecret, one new K8s Secret, an added envFrom entry on the Deployment, and the policy change. ol-analytics-api-secrets-<env> is untouched — it still carries only SENTRY_DSN.

The Vault entry must exist before the pods can start, or VSO renders empty values and the app fails at MITx Online's token endpoint:

vault kv put secret-operations/ol-analytics-api/mitxonline-oauth \
  client_id=<from MITx Online Django admin> \
  client_secret=<from MITx Online Django admin>

Pre-commit passes, including ruff and mypy. I confirmed this change adds no new mypy findings by diffing the error set against main — the file has 19 pre-existing errors, unchanged.

Not verified: no pulumi preview against the live stack (no AWS credentials in the authoring environment), and the secret-operations entry doesn't exist yet, so VSO's read and template rendering are unexercised. Both want checking before deploy.

Additional Context

Third of three PRs, and the ordering is load-bearing:

1. feat(b2b): add a service-scoped org-manager check endpoint mitxonline#3807 — the service endpoint + b2b:manager-check scope
2. this PR — credentials delivery
3. fix(b2b): authenticate the org-manager check with OAuth2 client credentials ol-analytics-api#22 — the consumer

Suggested order: merge the mitxonline endpoint, create the Application and write the Vault entry, merge this, then merge the app PR.

An earlier revision of this PR read the secret with vault.generic.get_secret_output and merged it into the existing Pulumi-managed Vault path. That was wrong for the two reasons above (secret in state; rotation requires a deploy) and has been replaced with the VSO templating shown here.

Checklist:

• Create the OAuth2 Application in MITx Online (confidential, client-credentials, b2b:manager-check scope) for each environment
• vault kv put secret-operations/ol-analytics-api/mitxonline-oauth client_id=… client_secret=… in CI, QA, and Production Vault before applying

[Copilot]

Pull request overview

Delivers MITx Online OAuth2 client-credentials (client ID + secret) into the existing ol-analytics-api Vault static secrets path so the ol-analytics-api pod can authenticate to MITx Online using a service token for its org-manager check.

Changes:

• Read MITx Online OAuth2 client credentials from secret-operations/ol-analytics-api/mitxonline-oauth via vault.generic.get_secret_output.
• Merge those credentials into the existing secret-ol-analytics-api/secrets kv-v2 secret alongside SENTRY_DSN by switching to Output.all(...).apply(...).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.