What would you like to be added
Per-peer identity for the mesh, replacing the single shared AES-256-GCM key as the trust boundary.
Why is this needed
The shared key is both admission control and the only credential, and it is neither per-peer nor a sender identity. Admission is all or nothing, the key cannot authenticate a sender, and revoking one site means re-keying every site. The key is a Secret replicated into every cluster's etcd, so one cluster's compromise exposes the grid.
It is also optional. spec.tls.swimKeyRef unset returns Ok(()) silently, so the mesh runs unencrypted and the trust boundary defaults to whoever can reach UDP 7946.
Grid already issues per-site certificates for gateway mTLS and never applies them to the mesh.
A shared key is defensible inside one trust domain. Grid's peers are separate clusters under separate administrative control, which is the case it does not cover.
On the Consul precedent
The design cites Consul's gossip encryption, but Consul argues the other way. Its gossip key is confidentiality only, scoped to one datacenter, and it authenticates with mTLS and authorizes with ACLs. Across datacenters it either federates, sharing WAN gossip and one root CA, or peers, where each cluster keeps its own CA and exchanges a trust bundle with no shared gossip. It ties the choice to the administrative model. Grid's peers are independently managed, which is the peering case, yet Grid shares one key, the coupling peering exists to avoid.
Related: #75 covers the specific case where a same-key peer can impersonate another site.
From the Grid review, Identity.
What would you like to be added
Per-peer identity for the mesh, replacing the single shared AES-256-GCM key as the trust boundary.
Why is this needed
The shared key is both admission control and the only credential, and it is neither per-peer nor a sender identity. Admission is all or nothing, the key cannot authenticate a sender, and revoking one site means re-keying every site. The key is a Secret replicated into every cluster's etcd, so one cluster's compromise exposes the grid.
It is also optional.
spec.tls.swimKeyRefunset returnsOk(())silently, so the mesh runs unencrypted and the trust boundary defaults to whoever can reach UDP 7946.Grid already issues per-site certificates for gateway mTLS and never applies them to the mesh.
A shared key is defensible inside one trust domain. Grid's peers are separate clusters under separate administrative control, which is the case it does not cover.
On the Consul precedent
The design cites Consul's gossip encryption, but Consul argues the other way. Its gossip key is confidentiality only, scoped to one datacenter, and it authenticates with mTLS and authorizes with ACLs. Across datacenters it either federates, sharing WAN gossip and one root CA, or peers, where each cluster keeps its own CA and exchanges a trust bundle with no shared gossip. It ties the choice to the administrative model. Grid's peers are independently managed, which is the peering case, yet Grid shares one key, the coupling peering exists to avoid.
Related: #75 covers the specific case where a same-key peer can impersonate another site.
From the Grid review, Identity.