Downstream spire-server does not honour ca_ttl configurable.

[sorindumitru]

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.

• Version: probably all of them since the introduction of the spire upstream authority
• Platform: any
• Subsystem: server

[azdagron]

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.

[azdagron]

We have consensus to move forward on this change. Here is a rough plan of action:

1. Update the NewDownstreamX509CA RPC to provide the preferred_ttl value passed to the spire UA plugin to the upstream server
2. Update the NewDownstreamX509CA implementation to pass this as the TTL parameter into the CA subsystem when minting the downstream intermediate CA instead of the downstream entry TTL (if any) This step should be conditional for now, see step (3)
3. Add a configuration value honor_downstream_ca_ttl, which defaults to false. This configuration value controls whether or not we do (2).

Then, on the next deprecation boundary
4. Deprecate the honor_downstream_ca_ttl configuration value and default to true

Then, on the next deprecation boundary after that
5. Remove the honor_downstream_ca_ttl configuration value

I will raise my hand to implement (1)-(3) and then create issues for (4) and (5) based on whichever release (1)-(3) land in.