Use dd-sts for Datadog API keys in workflows - #501
Open
yoannmoinet wants to merge 1 commit into
Open
Conversation
Replace every secrets.DATADOG_API_KEY usage with a short-lived API key federated from dd-sts (DataDog/dd-sts-action@v1.0.5, OIDC). Env var names are unchanged downstream so no source code needs to change. - ci.yaml: top-level permissions (contents: read, id-token: write), dd-sts steps before Datadog Test Optimization (unit-test, e2e) and a cache-gated one before Build all plugins (lint). - publish.yaml: dd-sts step before Publish to NPM, feeding both the publish and Log version published steps. - bump.yaml: dd-sts step before Log bump. All credential steps are continue-on-error so that telemetry stays best effort and fork PRs, which can't federate a token, keep passing. Requires the build-plugins-ci, build-plugins-publish and build-plugins-bump policies to be deployed in dd-source first.
sdkennedy2
approved these changes
Sep 2, 2026
There was a problem hiding this comment.
🟢 Approval recommended
Workflow changes are narrowly scoped to credential acquisition and key wiring, and all secrets.DATADOG_API_KEY usages in workflows have been removed as intended.
Pull request overview
This PR updates the repository’s GitHub Actions workflows to stop using the long-lived secrets.DATADOG_API_KEY and instead obtain short-lived Datadog API keys via GitHub OIDC using DataDog/dd-sts-action@v1.0.5 (pinned by SHA). This aligns CI/release telemetry with the SDLC security goal of removing org-wide static secrets from automation.
Changes:
- Add “Get Datadog credentials” (
dd-sts) steps to CI, publish, and bump workflows and wire theirapi_keyoutput into existingDATADOG_API_KEY/api_keyinputs. - Add top-level workflow permissions in
ci.yaml(contents: read,id-token: write) to enable OIDC federation. - Replace all remaining
secrets.DATADOG_API_KEYreferences in workflows (verified none remain under.github/workflows/).
File summaries
| File | Description |
|---|---|
| .github/workflows/ci.yaml | Adds OIDC permissions + dd-sts credential steps and routes api_key into Datadog test visibility and build telemetry env. |
| .github/workflows/publish.yaml | Adds dd-sts step and uses its api_key output for publish and log-intake telemetry. |
| .github/workflows/bump.yaml | Adds dd-sts step and uses its api_key output for bump log-intake telemetry. |
Review details
- Files reviewed: 3/3 changed files
- Comments generated: 0
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
tyffical
approved these changes
Sep 2, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What and why?
Replace every
secrets.DATADOG_API_KEYusage in our workflows with a short-lived API key federated from dd-sts (DataDog/dd-sts-action@v1.0.5, GitHub OIDC), removing the long-lived org-wide GitHub secret from CI (SDLC Security initiative). Env var and input names are unchanged (DATADOG_API_KEY/api_key), so no source code changes.Follow-up once CI is green (repo admin, outside this PR): delete the
DATADOG_API_KEYrepo secret.How?
permissions(contents: read,id-token: write) — this workflow previously had no permissions block at any level, and its checkout needscontents: read— plus aGet Datadog credentialsstep (id: dd-sts,continue-on-error: true) in each job: before Configure Datadog Test Optimization inunit-testande2e(fed viaapi_key), and cache-gated before Build all plugins inlint(sameifas the consuming step, so no pointless exchange on a cache hit).id-token: writepermission dd-sts needs at job level (it was there for npm provenance / octo-sts respectively), so only thedd-stsstep is added — publish before Publish to NPM (feeding it and Log version published), bump before Log bump.Every credential step is
continue-on-error: true: Datadog telemetry is best-effort, and fork PRs cannot federate an OIDC token, so they keep passing exactly as today. Nothing here can break a build — an empty key makessendMetricsa no-op, the log-intakecurlhas no-f, andtest-visibility-github-actionjust exports an emptyDD_API_KEY. Security-wise there is no new exposure onpull_request: same-repo PRs already receivesecrets.DATADOG_API_KEYtoday, and dd-sts swaps a static org-wide secret for a short-lived, policy-scoped, audited credential.Policies validated locally with
dd-sts check(schema) and a synthetic claim matrix: each policy accepts only its own event shape (PR / release tag or branch dispatch / master-v2dispatch) and rejects the other two plus a wrong-workflow claim. Workflows validated withactionlint(no new findings) andyarn cli integrity.