Description
Verify both authentication methods against real SPIRE infrastructure and
ToolHive's deployed configuration, and document the threat model and
operational failure modes.
Unit tests with hand-rolled certificates and self-signed JWTs will not catch
the failures that matter here. The interesting bugs live in the gap between what
SPIRE actually issues and what the validator assumes — SAN shapes, key usage,
bundle rotation timing, audience handling — so the positive paths must run
against credentials SPIRE minted.
Scope
- Add table-driven parser, validator, policy and client-authentication tests.
- Add real TLS and JWT-SVID integration tests.
- Add an end-to-end SPIRE deployment and test matrix.
- Document the threat model, supported configuration, rotation behaviour and
operational failure modes.
Acceptance criteria
Positive paths, against real SPIRE-issued credentials:
- X.509-SVID and JWT-SVID authentication both succeed.
- Both methods produce equivalent grants and Cedar authorization decisions for
the same SPIFFE ID.
Negative and boundary coverage:
- Malformed and additional URI SANs
- Invalid X.509 chains and wrong key usage
- Wrong trust domains
- Missing or mismatched client IDs
- Expired JWT assertions
- Incorrect or multiple JWT audiences
- Wrong JWT keys, key IDs and algorithms
- OIDC token / JWT-SVID type confusion
- Bundle rotation, key removal, and cross-trust-domain mix-up
- Exact and wildcard client-association boundaries
- All four client shapes: public, secret-confidential, X.509-SVID, JWT-SVID
client_credentials and RFC 8693 token exchange
- Restart and persisted-association behaviour
Discovery:
- Metadata verified for X.509-only, JWT-only and combined configurations.
- Public-only deployments' metadata is unchanged.
Documentation:
- Threat model covers CA or signing-key compromise, Bundle Endpoint compromise,
assertion replay, TLS termination, and Workload API socket access.
- Production deployment and troubleshooting documentation is complete.
Dependencies
- Sub-issue 6 (SPIRE and operator deployment integration) — the E2E matrix needs
the deployable path
Related
- Part of the SPIFFE client-authentication epic
Description
Verify both authentication methods against real SPIRE infrastructure and
ToolHive's deployed configuration, and document the threat model and
operational failure modes.
Unit tests with hand-rolled certificates and self-signed JWTs will not catch
the failures that matter here. The interesting bugs live in the gap between what
SPIRE actually issues and what the validator assumes — SAN shapes, key usage,
bundle rotation timing, audience handling — so the positive paths must run
against credentials SPIRE minted.
Scope
operational failure modes.
Acceptance criteria
Positive paths, against real SPIRE-issued credentials:
the same SPIFFE ID.
Negative and boundary coverage:
client_credentialsand RFC 8693 token exchangeDiscovery:
Documentation:
assertion replay, TLS termination, and Workload API socket access.
Dependencies
the deployable path
Related