fleetdm
Shorter sessions for API-only users
-
customer-cisneros:- Gong snippet: https://us-65885.app.gong.io/call?id=6376091481911195710&highlights=%5B%7B%22type%22%3A%22SHARE%22%2C%22from%22%3A3068%2C%22to%22%3A3187%7D%5D
- Slack thread: https://fleetdm.slack.com/archives/C072L58U878/p1741106313240399
- @noahtalerman: User requested this because they want to create an automation for lock/wipe. They want the API token that can perform these actions to only be valid for 24 hours.
- @noahtalerman: What does that automation look like? Why is the API token so short lived? Is this automation only running one time? Or will, the IT admin "refresh" the API token token every time the automation needs to run.
- @allenhouchins: In the interim users can manage the session duration at the automation level. Some third-party automation tools support a time-to-live (TTL) duration for automations.
- @noahtalerman: Eventually Fleet could allow the user to configure the session duration for API-only users. Separately from the session duration for the user accounts humans use to log in to Fleet.
customer-cisneros wants to have per user or per role control over how long Fleet API tokens are valid for. Currently, this is a server-wide configuration option that applies to all accounts that are not API-only users.
For example, there is no way to specify that admin users should get a session duration of 5 days, but Maintainers only get API tokens valid for 4 hours.
What have you tried?
This can be partially managed today by building a custom workflow that uses the Fleet API to get all sessions for a defined set of users, finding sessions that are older than the desired timeframe, and using the API to delete the session.
For native support, Cisneros looked for ways to configure duration on a per-user or per-role basis, but that feature does not exist.
Potential solutions
Cisneros would like to be able to specify a session duration on a per-user or per-role basis.
What is the expected workflow as a result of your proposal?
Cisneros would grant a user the ability the ability to perform a lock or wipe action on their host via the API. They would issue an API token and specify a very short session duration (5 minutes or so). The user would receive the API token, perform the action, then the token would expire and could not be used anymore.
Given that we don't really have the concept of session expiration in the database (beyond "expires X time after creation")...just revocation...thinking the way to handle this would be to add a JWT auth method with some creative uses of parameters.
kid on the JWT would be the PK of the session that created the JWT (which allows revoking all JWTs created by that session by deleting the session), probably prefixed by fleet_session_id_; this can be pulled from /users/{id}/sessions (might need to expand the existing /sessions/{id} endpoint to accept a session key and get a PK back). Signing mechanism would be HS256, with the key as the first 32 bytes of the session ID (JWT validation should fail if the session key isn't long enough). nbf and iat claims would be verified against the session creation time, and exp claim would be verified against created_at + session length. iss claim would be the configured server URL. sub claim would be the verb and URL of the endpoint to scope the JWT to. aud claim would be the ID of the user associated with the session (API or otherwise). If all validation succeeded (including URL match), the JWT would behave the same as the session that it's attached to.
A side effect of the above structure is that a consumer of the API would have all of the pieces needed to sign their own JWTs, given a session, with validity as long/short as needed (subject to the underlying session length), so all we'd be implementing is verification and maybe tweaks to the existing session endpoint to unblock this request. The customer could then build a JWT for "lock X host, valid for the next 5 minutes" client-side (as long as they had a valid long-lived session ID) or any other endpoint they had access to, with a bit less effort than e.g. a signed URL would take.
Spitballing here a bit, but potentially a way to solve this anyway.
Update:
customer-cisneros: Only a few people will have admin access, and help desk does not have it. Need a way to hand out API tokens for use --> A standard user who needs to take an action through the API for a one off. This is done via automation which will call the API. Prefer not to have that ability permanently live. This is a compensating control for missing RBAC.
(These are regular users who happen to only use the API, not API only users)
I've been trying to figure this out from documentation and issues like this one. What is the actual default session time of an API only user's token? It seems almost infinite.
In most tools that have API tokens, there's a server-wide maximum lifetime (90d, 60d, 30d, 1d), but during token creation/retrieval, you can specify a shorter lifetime (24h, 8h, 1h).
When do API only tokens actually expire?
