Machine ID: Per-ouput certificate_ttl and renewal_interval

[boxofrad]

Implements #51560 by adding certificate_ttl and renewal_interval options to all tbot services/outputs, allowing you to control their certificate lifecycles separately from tbot's internal identity.

This is useful when you use tbot in one-shot mode to authenticate a cron job, because it enables you to set a long enough TTL on tbot's internal identity to survive until the next run, but a suitable short TTL on the workload's identity.

Example config:

# Controls `tbot`s internal identity certificate.
certificate_ttl: 1h
renewal_interval: 30m

services:
  - type: identity
    roles:
      - my-cron-job

    # Controls the output's certificate.
    certificate_ttl: 2m
    renewal_interval: 1m

changelog: tbot: support overriding certificate_ttl and renewal_interval on most outputs and services

[boxofrad]

I re-homed these warnings from BotConfig.CheckAndSetDefaults.

Ideally, we'd return an error (so they'd get wrapped with the service[%d] prefix) but decided not to as making this a "hard fail" would be a breaking change.

[tigrato]

I would expect validate to return the error, a specific kind and the caller decides what to do with it.

There might be cases where an hard error is required

[github-actions]

Amplify deployment status

Branch	Commit	Job ID	Status	Preview	Updated (UTC)
boxofrad/tbot-per-service-cert-lifetimes	599c8d7	2	✅SUCCEED	boxofrad-tbot-per-service-cert-lifetimes	2025-02-10 12:53:37

[boxofrad]

I didn't add it for this output because although there is a TTL, it felt wrong referring to it as the "certificate TTL" because it's really the JWT TTL.

[strideynet]

What if we renamed certificate -> credential? That might make more sense in regards to both JWTs and X509? Imho, this is actually one of the more useful outputs to use this on since I'd expect a JWT to require a very short TTL (e.g 5 minutes).

[boxofrad]

Good point! Rename it just on this output, or on them all?

[strideynet]

Probably better to be consistent and rename on them all - but I can see how that creates a problem with the fields on the root configuration resource. I assume supporting both names on the root config would be challenging? We could deprecate the usage of certificate_ttl and encourage migration to credential_ttl. WDYT?

[tigrato]

+1 on renaming to be consistent

[strideynet]

Most of these outputs/services will have a test named something like TestApplicationOutput_YAML. That test usually has a "full" case where we try and set all of the possible config values. It'd be great to see the CertificateLifetime fields added to this. I've witnessed some really weird behaviour from our YAML marshal/unmarshaling libraries before, and those tests are fairly good at identifying when this happens.