feat(grounds-velocity): mount the floodgate key for a bedrock proxy - #161
Merged
Conversation
Floodgate is what lets an online-mode proxy accept a player who has an Xbox Live account and no Mojang one: Geyser signs the Bedrock player's data with a shared key and Floodgate verifies the signature. Both sides have to see byte-identical keys, so the Secret is referenced and never generated — the same reason velocity-forwarding-secret is provisioned out of band. Mounted somewhere neutral rather than onto plugins/floodgate. Floodgate also creates a config.yml in its data directory on first start, and a read-only mount there stops the plugin initialising — the same trap Geyser has with its own config, found by running the image rather than rendering it. The velocity image's start.sh copies the key in from FLOODGATE_KEY_FILE. Off by default and inert when off: no env, no volume, no mount, so nothing changes for a proxy that has no Bedrock players. Enabling it also means setting VELOCITY_FORCE_KEY_AUTHENTICATION=false, which is not something to do on a proxy serving Java players — hence a separate release for Bedrock rather than a flag on the shared ones.
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
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.
Completes the proxy half of Bedrock support. Geyser terminates the Bedrock session and connects to a Velocity proxy as a Java client; Floodgate on that proxy is what actually admits the player.
Why the key is mounted somewhere neutral
Floodgate reads its key from its own plugin data directory — and also creates a
config.ymlthere on first start. Mounting the Secret straight ontoplugins/floodgatemakes that directory read-only and the plugin fails to initialise.That is the same trap Geyser has with its own config (#160), and it was only visible by running the image. So the Secret lands at
/var/run/secrets/floodgateand the velocity image'sstart.shcopies it in, leaving the directory writable. Requires groundsgg/containers#223.Why it is referenced, never generated
Geyser signs the Bedrock player's data with this key and Floodgate verifies the signature. Both sides must see byte-identical keys — a chart that generated its own would produce a key the Geyser side does not have, and every Bedrock login would fail its signature check. Same reason
velocity-forwarding-secretis provisioned out of band.Inert when off
Default
enabled: falserenders no env, no volume and no mount, so nothing changes for any existing release.Enabling it also means setting
VELOCITY_FORCE_KEY_AUTHENTICATION=false, because Bedrock players carry no Mojang profile key and are kicked at login while it is enforced. That is not something to do on a proxy serving Java players — which is why Bedrock gets its own release (velocity-bedrockin groundsgg/deploy#135) rather than a flag on the shared ones.Verified
helm lintcleanfloodgateKey.enabled=false→ zero floodgate referencesFLOODGATE_KEY_FILE, the volume and the mount all presentkubeconform -summary -stricton both renders: 2/2 valid each