Add integration test for assuming an API Key Role using a Buildkite OIDC token #5416
Conversation
| runner_environment | ||
| ] | ||
| } | ||
| end |
There was a problem hiding this comment.
This config was created based on https://agent.buildkite.com/.well-known/openid-configuration
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #5416 +/- ##
==========================================
- Coverage 97.06% 94.26% -2.80%
==========================================
Files 451 451
Lines 9391 9450 +59
==========================================
- Hits 9115 8908 -207
- Misses 276 542 +266 ☔ View full report in Codecov by Sentry. |
yob
force-pushed
the
test-api-key-roles-with-buildkite
branch
from
262e057 to
0098d67
Compare
…IDC token Until recently, Buildkite OIDC tokens did not contain a `jti` claim. At some point in early 2024 it was possible to assume an API Key Role using Buildkite OIDC tokens, but when testing in January 2025 we found the assume role request was failing with an error: > Missing/invalid jti Buildkite has addressed that by adding a `jti` claim to tokens - it's a good claim to include. However, to reduce the risk of regressions in the future, this proposes adding an integration test with a Buildkite-shaped OIDC token. The trait added to the OIDC::Provider factory is based on a real token that I generated then anonymized. I only test the happy path with this token - there's a buncha existing tests for various unhappy paths (expired token, etc) using the Github Actions shaped OIDC token and there's little value in replicating them. Most of the added test is copy-pasted from the happy-path Github Actions test further up the file. Fixes rubygems#5412
yob
force-pushed
the
test-api-key-roles-with-buildkite
branch
from
0098d67 to
7e2c2ef
Compare
|
@simi I think this is ready for another look. I've tidied the test setup, and there's a single test failure in CI but it seems unrelated |
Thanks for the info, looks good to me. 💪 |
|
Sounds good. Since opening this PR, we've also published a Buildkite plugin for pushing to rubygems.org using OIDC API Key Roles, and started using it for one of our own open source gems. Hopefully that dogfooding will also help us build familiarity with the feature and notice if any issues arise (from either end) ❤️ |
Until recently, Buildkite OIDC tokens did not contain a
jticlaim. At some point in early 2024 it was possible to assume an API Key Role using Buildkite OIDC tokens, but when testing in January 2025 we found the assume role request was failing with an error:Buildkite has addressed that by adding a
jticlaim to tokens - it's a good claim to include. However, to reduce the risk of regressions in the future, this PR proposes adding an integration test with a Buildkite-shaped OIDC token.The trait added to the OIDC::Provider factory is based on a real token that I generated then anonymized. I only test the happy path with this token - there's a buncha existing tests for various unhappy paths (expired token, etc) using the Github Actions shaped OIDC token and there's little value in replicating them.
Most of the added test is copy-pasted from the happy-path Github Actions test further up the file.
Fixes #5412