Open sorindumitru opened 2 weeks ago
I agree that it would be less surprising. Further, it's even more strange that the default TTL applied to the downstream CA, if the registration entry does not set one, is the default workload SVID TTL. This behavior is historic and somewhat unintentional but it shipped that way originally and we've maintained it due to backcompat.
The upstream authority plugin interface already provides a preferred_ttl field to plugins. The spire
upstream authority plugin could be taught about that field, and the NewDownstreamX509CA RPC extended to support it.
The biggest question here is backwards compatibility... I'd personally be for this change on a minor release boundary, provided we include a configuration value that allows folks to revert to the old behavior, at least for a time. I'm curious to hear other maintainers thoughts.
We have consensus to move forward on this change. Here is a rough plan of action:
spire
UA plugin to the upstream serverhonor_downstream_ca_ttl
, which defaults to false
. This configuration value controls whether or not we do (2).Then, on the next deprecation boundary
honor_downstream_ca_ttl
configuration value and default to true
Then, on the next deprecation boundary after that
honor_downstream_ca_ttl
configuration valueI will raise my hand to implement (1)-(3) and then create issues for (4) and (5) based on whichever release (1)-(3) land in.
When running a nested SPIRE deployment, it can be surprising that the TTL on the CA used by the downstream server does not come from the
ca_ttl
in the configuration file, but is taken from the registration entry of the downstream spire-server instance.Would it be possible to have the downstream spire-server specify the TTL it requires for the CA when requesting one? It would still need to be bounded by the TTL of the upstream CA, but that's less surprising to me.
Alternatively, this could be documented to make it less of a surprise.