Add foundational support for API key expiration #5341
Conversation
jinnovation
changed the title
expires_at col to API key table
jinnovation
changed the title
| You can optionally set an expiration date and time for the new API key by providing the UTC timestamp as an argument, like so: | ||
|
|
||
| ```bash | ||
| docker compose run --rm gateway --create-api-key "2025-12-20 23:00:00.000000 UTC" |
There was a problem hiding this comment.
Could you make the argument an independent flag? We'll likely want to add additional arguments in the future (e.g. RBAC).
... --create-api-key --expiration "2025-12-20 23:00:00.000000 UTC"
There was a problem hiding this comment.
Let me know what you think of the approach I took here. Basically: --expiration is on the same level as --create-api-key and --disable-api-key, but requires the former to be present as well if it's set.
This is a little inelegant since --expiration is now a separate entry in the EarlyExitCommands collection. That said, this feels like simplest path forward, short of creating a new sub-command entirely for --expiration to live under, e.g. gateway create-api-key --expiration blablabla.
| "my_org", | ||
| "my_workspace", | ||
| None, | ||
| Some(Utc::now() - Duration::seconds(2)), |
There was a problem hiding this comment.
Let's do something like now + 10ms and sleep 10ms to account for the error check above.
There was a problem hiding this comment.
Done elsewhere, i.e. at the gateway-auth integration test level. Had to do a 2s wait for some reason.
I think we can leave this specific test as-is, since our ability to inject directly into the test database means we can bypass the CLI-level checks for an expiration timestamp that's in the future. That said, I'm happy to take the same wait-based approach here if you'd prefer, for consistency.
``` > ./target/debug/gateway --expiration "2025-12-20 23:00:00.000000 UTC" error: the following required arguments were not provided: --create-api-key ``` ``` > ./target/debug/gateway --create-api-key --expiration "2025-12-20 23:00:00.000000 UTC" 2025-12-30T00:34:59.998179Z ERROR gateway: Failed to create API key: Expiration datetime needs to be in the future ```
…ation' into 4365/optional-api-key-expiration
|
@GabrielBianconi: This is ready for your team's review again whenever convenient. |
3 participants
Contributes to #4365.
This PR adds an optional column
expires_at TIMESTAMPTZto thetensorzero_auth_api_keytable. When authenticating, if the API key hasexpires_atset, the key is rejected if the current time exceeds the expiration time.At the same time, we extend the
gatewayCLI such that we can optionally provide a datetime argument to--create-api-keyto set the expiration time for the created API key; if not provided, this defaults to "infinite" expiration.Follow-up tasks:
Important
Add support for API key expiration, including database changes, CLI updates, middleware adjustments, and tests.
expires_at TIMESTAMPTZcolumn totensorzero_auth_api_keytable.query-4cf7253a341ad5783871470cfda9cbe56d7b2b225359837ed4dfb08771eb53e7.json,query-6a67bd25a67a31bddb65330de2b21ae20fb4d201300d2e56ed8c0f1de2d490ae.json, andquery-97c1ae769f9c03c5eda14cde29d338153023b36becd12a4a1c708b2058e7462a.jsonto handleexpires_at.--expirationoption to--create-api-keycommand incli.rsandmain.rs.handle_create_api_key()inmain.rs.tensorzero_auth_middleware()inmiddleware.rsto check for expired API keys.auth.rsanddb/mod.rs.set-up-auth-for-tensorzero.mdxto include instructions for setting API key expiration.This description was created by
for 29e5e71. You can customize this summary. It will automatically update as commits are pushed.