fix(router): support key rotation in mutual auth handshake - #337
Merged
Conversation
performMutualAuth verified the remote biscuit against all trusted control plane keys but then built the role authorizer from trustedKeys[0]. A biscuit signed by a rotated key passed verification and then failed authorization, breaking router-to-router auth for the whole rotation window. Build the authorizer from the key that actually verified, via identity.VerifyBiscuitAndGetKey. Same bug class as the node-side fix in google#334.
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Code Review
This pull request updates the mutual authentication process in the router to support key rotation. Instead of always using the first trusted key to instantiate the biscuit authorizer, it now retrieves and uses the specific key that successfully verified the biscuit. A new unit test, TestPerformMutualAuthAcceptsRotatedKey, has been added to verify this behavior. There are no review comments to address.
aojea
added a commit
to aojea/sam
that referenced
this pull request
Aug 31, 2026
performRouterAuthHandshake verified the router biscuit against all trusted control plane keys but built the role authorizer from trustedKeys[0]. With a single key loaded this was harmless, which is why it survived until now: once the node holds the full valid key set (rotation grace), any router biscuit not signed by the first key fails with 'authorizer instantiation failed: biscuit: invalid signature' — exactly the kind-mesh e2e failure on this PR, and the node-side twin of the router bug fixed in google#337. The recovery test now seeds a decoy trusted key ahead of the real one to pin this: verified red (reproduces the CI failure), green with the fix.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
While reviewing #334 we swept for other instances of the same bug class and found one in the router:
performMutualAuthverifies the remote biscuit against all trusted control plane keys, but then builds the role authorizer fromtrustedKeys[0]. A biscuit signed by a rotated key passes verification and then fails authorization (biscuit: invalid signature), breaking router-to-router mutual auth for the entire rotation window.This is the router-side twin of the node-side issue flagged in the #334 review; #334 doesn't touch this file.
Changes:
identity.VerifyBiscuitAndGetKeyand build the authorizer from the key that actually verified.TestPerformMutualAuthAcceptsRotatedKey: remote biscuit signed by the second trusted key must authenticate. Verified red against the old code (fails withauthorizer instantiation failed: biscuit: invalid signature) and green with the fix.