Cap Secrets Manager user CEL token TTL to 5 minutes

What does this MR do and why?

The userPermissions capabilities check in !240596 (merged) introduced the first non-inline login for Secrets Manager: it logs in against the user_jwt CEL role to mint a real, persisted OpenBao token, calls sys/capabilities-self, then revokes the token best-effort.

The user_jwt CEL role set no token TTL, so a token whose revoke-self fails would live for OpenBao's default lifetime (~32 days). That is far too long for a token whose only job is a single capabilities check.

This MR caps that token's TTL. For a CEL role the token TTL cannot be set with the classic token_ttl / token_max_ttl params (the cel/role endpoint rejects them), so it is set inside the CEL program's returned pb.Auth via lease_options.

The TTL is read from an optional secrets_manager_token_ttl claim (seconds) and defaults to 5 minutes when the claim is absent. Nothing sets that claim today, so every token gets the 5 minute default. Reading it from a claim means we can retune the lifetime later from Rails (for example via an application setting that populates the claim) without re-provisioning or backfilling the OpenBao role.

A non-positive claim falls back to the 5 minute default, so a stray 0 is not read by OpenBao as "use the default" (which would revert to its ~32-day max). The upper bound is left to OpenBao itself, which caps any token at its max_lease_ttl (32 days), so we do not duplicate that limit in the CEL program.

Only the user_jwt CEL role is affected. The pipeline role authenticates over inline auth (ephemeral, request-scoped tokens that ignore the role TTL), so it does not need this. The new api_jwt mount has the same gap and is being handled in !240364 (merged).

Affected databases

None. No migration. This only changes the CEL program written to OpenBao when a secrets manager is provisioned.

References

• Blocks !240596 (merged) (the capabilities check that mints the persisted token).
• Follow-up to backfill the TTL onto existing user_jwt roles is tracked in #604545 (closed).
• The same token TTL on the new api_jwt mount is handled in !240364 (merged).

How to set up and validate locally

The behaviour is covered by an integration spec that provisions the CEL role, performs a real (non-inline) login, and asserts the minted token's lifetime:

bundle exec rspec ee/spec/lib/secrets_management/secrets_manager_client_spec.rb -e "CEL mounted requests"

• With no claim, the minted token's lease_duration is 300 (5 minutes).
• With a secrets_manager_token_ttl claim of 600, it is 600.
• With a non-positive claim, it falls back to 300.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.