You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I worked through this with @mweissbacher a couple weeks ago. IIRC, the bundle grew to this size due to a couple reasons: an aggressive ca_ttl (coupled with memory diskmanager and server restarts), and a version of SPIRE prior to #859.
Prior to #859 (and v0.8.0), SPIRE included intermediate servers in the bundle as a backwards compatibility measure for 0.6.x agents. In this particular case, it caused the bundle to grow large as short-lived intermediates rotated. Moving to 0.8.0 alleviates the situation, but management of a large bundle remains problematic (see #921).
@azdagron looked into this particular error further, I believe. Go x509 library will halt validation if it hits 100 signature checks. Even if there are 100+ members in the bundle though, we still thought that the validator should be able to use AKID/SKID to reduce the number of candidates and avoid this problem. I don't recall exactly what he found there, I'll leave it to him to fill in the rest of the details.
In terms of managing bundle growth generally, I am not quite sure what the ideal behavior would be. We could certainly log warnings about it... but I don't think we can just stop rotation. Practically speaking, this would also place an upper limit on the horizontal scaling of SPIRE server.
We adapted our configuration and haven't run into this issue since. The original configuration was purposefully aggressive - apparently too aggressive!
For context, here's the reasoning for the limit: golang/go#29233
This was a while ago (as the timestamps suggest), but I didn't want to forget about it.
One thing we noticed was the bundle has 108 entries in it - We suspect it's related to that. But I haven't made a minimal repro yet.
The text was updated successfully, but these errors were encountered: