docs(spiffe-edge): edge guide + cross-mode compatibility e2e (proposal 012 PR-4) - #90
Merged
Merged
Conversation
Fourth and final PR of proposal 012 — the operator-facing edge
documentation + the crypto-level cross-mode compatibility e2e.
* docs/spiffe-edge.md (new) — the edge SPIFFE guide:
- why edge is its own problem (topology, partitions, exposure)
- the topology decision tree (nested / federated / ed25519)
- per-topology config + setup pointers
- offline survival + the offline_action behaviour table
- the ed25519 -> spiffe migration path
- a troubleshooting table
- the six-direction bi-directional compatibility matrix
* docs/howto-edge.md — SPIFFE optional section + pointer.
* docs/spiffe.md — an edge-interoperability section.
* tests/integration/test_spiffe_edge_e2e.py (new) — a crypto-level
e2e that needs no cluster. Models each trust topology with
synthetic SPIRE keypairs, mints JWT-SVIDs exactly as a SPIRE
workload API would, and verifies them through the production
acc.spiffe_verify path. 13 tests:
- nested: all five shared-root directions (rhoai<->rhoai,
rhoai<->edge, edge<->rhoai, edge<->edge same + different
nested sites) + strict-subject-binding rejection
- federated: cross-trust after bundle exchange, the negative
control (federation IS required), both directions
- offline: fresh-within-window, degrade + rotate past the
window, partition->recovery without restart
Runs unattended — no SPIRE, no network, milliseconds.
Proposal 012 status with this PR: all four PRs landed. The
SPIFFE arc (proposals 011 + 012) is feature-complete — workload
identity ships as opt-in via security.signing_mode; every
existing deployment is unchanged.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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.
Summary
Fourth and final PR of proposal 012 — the operator-facing edge documentation + the crypto-level cross-mode compatibility e2e. Closes the SPIFFE arc (proposals 011 + 012).
docs/spiffe-edge.md(new) — the edge SPIFFE guide: topology decision tree (nested / federated / ed25519), per-topology config, offline survival + theoffline_actiontable, the ed25519→spiffe migration path, troubleshooting, and the six-direction bi-directional compatibility matrix.docs/howto-edge.md— SPIFFE optional section + pointer.docs/spiffe.md— an edge-interoperability section.The cross-mode e2e
tests/integration/test_spiffe_edge_e2e.py— a crypto-level e2e that needs no cluster. It models each trust topology with synthetic SPIRE keypairs, mints JWT-SVIDs exactly as a SPIRE workload API would, and verifies them through the productionacc.spiffe_verifypath.A true two-cluster nested/federated SPIRE test stays the operator's manual acceptance step; this gives CI unattended coverage of the locked "bi-directional compatibility" requirement.
13 tests:
degrade+rotatepast the window, partition→recovery without restartTest plan
pytest tests/integration/test_spiffe_edge_e2e.py— 13/13 greenacc/oroperator/— docs + a new test file onlydocs/spiffe-edge.mdProposal 012 — complete
SpiffeConfigedge fieldsThe SPIFFE arc (011 + 012) is feature-complete — workload identity ships as opt-in via
security.signing_mode; every existing deployment is unchanged.🤖 Generated with Claude Code