jcreek/CosmicClash
1
0
Fork 0
mirror of https://github.com/jcreek/CosmicClash.git synced 2026-09-10 16:04:04 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs(multiplayer): align workload authentication model

Browse Source
This commit is contained in:
Josh Creek
2026-09-03 21:08:52 +01:00
parent 25cf1e0cfa
commit 854d160f27
2 changed files with 13 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/MATCHMAKING.md
+12 -11
View File
@@ -101,7 +101,7 @@ roles rather than independently designed microservices:
| API | HTTPS/WebSocket auth, profile, queue commands, status resync |
| Matcher | Atomic proposal formation from queue state |
| Allocator | Agones allocation, server registration, assignment delivery |
| Maintenance worker | Outbox delivery, season rollover, expiry, reconciliation |
| Maintenance worker | Season rollover, initial-connect/no-show expiry, live reconnect-abandonment reconciliation, and other durable lifecycle recovery |
API replicas are stateless. Redis sorted sets provide the fast candidate
index, but Redis is never the durable allocation fence: asynchronous failover
@@ -356,16 +356,17 @@ public-IP/unsolicited-UDP reachability, provider firewall/NAT validation,
per-location certificates and coordinator trust. Use an Agones dynamic or
passthrough mapping whose externally reported port is the `SDR_IP` port while
the process binds `SDR_LISTEN_PORT`; test SDR and ENet mappings separately.
Credentials arrive through runtime secret mounts, never allocation metadata,
arguments, logs or images.
Result authentication uses a projected, pod-bound service-account token with
a dedicated audience and one service account per workload class. The backend
validates the configured cluster issuer/JWKS, audience, expiry, namespace,
service account, bound pod UID and allocator-recorded GameServer UID, then
checks that GameServer/match binding in PostgreSQL. Issuers and trust roots are
allowlisted and rotated explicitly for every cluster/provider. A one-match
server credential issued after this attestation is an acceptable equivalent.
The control plane's HMAC signing secret arrives through a runtime Secret mount;
it never reaches the game pod, command line, logs, or image. For each
allocation, the allocator signs a short-lived bearer token containing only the
allocation ID and requests Agones to attach it to the selected GameServer's
metadata. The allocated pod's local SDK sidecar is the delivery boundary: the
supervisor reads that annotation and supplies it only as a child-process
environment variable. The backend verifies the HMAC and expiry, then resolves
the allocation ID to the durable allocation/match/server tuple in PostgreSQL;
the game server cannot choose that binding. A future projected-service-account
attestation may replace this delivery mechanism, but it is not a current
security claim.
### Warm capacity and density