Buildkite-agent oidc request-token --lifetime maximum too short

From this page OIDC in Buildkite Package Registries | Buildkite Documentation token max lifetime is 300 seconds.

For a token that is going to be used to upload large files (including docker images) to a package registry this is too short in a lot of scenarios.

A 300 second OIDC token is on the very short end of the reasonable expectation of best practice for OIDC tokens - and in this particular scenario is often technically unworkable.

Ironically this is likely to hit users when they are first experimenting with packages and there is no existing layers uploaded - potentially blocking adoption of this pretty cool feature entirely.

Suggestion - set 300 as a default (seems like it already is from experimentation) and allow a max lifetime of up to 1800 seconds (or higher) and clearly document the security trade off to allow teams to make their own decision on this. For a well scoped token this is a pretty well mitigated risk.

Cheers

Hi @chris-at-metacosm , welcome to our Buildkite Support Community! :waving_hand:

Thanks for raising this to our attention. This limit of 300 seconds only applies to our Package Registries product. Our pipelines can manage a longer lifetime as you can see in our platform / organization limits - Limits | Buildkite Documentation . The recommended approach at the moment if your upload or publish process is running longer than 5 minutes, is to request the OIDC token immediately before authenticating/publishing to the registry, rather than generating it earlier in the job and reusing it later. Is the 5-minute limit blocking a specific use-case for you? Or are you alright with the suggested workaround?

Cheers!

I’m aware that the limit is only on package registries - that’s actually the root of the problem. Uploading large files is one of the things during a CI/CD process that can reliably potentially exceed 5 minutes and is also usually very hard to re-authenticate mid upload. This problem bites mainly BECAUSE it is a limit that applies to package registries, not an issue that is mitigated because it only applies here. The five minute limit is a hard blocker here. There is no workaround (your proposal is just basic best practice). 300 seconds is also a very non-standard limit here in general - there’s very little reason for a time this tight - I’d suspect that somewhere along the way during product design a default got changed to a maximum.

I see. Thanks for sharing your thoughts and for letting us know that this is a blocker for you. I’ll raise this as a feedback to our product team to assess if this limit can be lifted.

Cheers!

The tone in that message came out harsher than intended on re-read. Thanks for raising the ticket - I’m moving our packages to ECR in the meantime as this can’t be worked around. I would like to see the buildkite platform continue to succeed though so the feature request still stands.

No worries! I’ve raised this already to our product team as a feature request. Thanks for the kind words on Buildkite! :green_heart: