lei.chen/myxce
1
0
Fork 1
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

docs: add future work items 6-8 and clarify design doc safety gate

Browse source 
- Future Work §6: validate_host() implementation plan (CN allowlist,
  admin-cn flag, reject/log unauthorised OP_upgradeConfig requests)
- Future Work §7: OP_replConfig access control hardening (peer
  validation, rate-limiting, minimum_role check)
- Future Work §8: lost_and_found reserved-name validation in admin
  config tool, with migration path for pre-existing clusters
- config-replication-design.md: expand CONF_ENABLE_UPGRADE_CONFIG
  safety gate section with gating prerequisites
This commit is contained in:
Rongsong Shen 2026-05-13 18:21:44 +00:00
parent 5ef14a2717
commit 40c7a93951
2 changed files with 86 additions and 8 deletions
Download patch file Download diff file Expand all files Collapse all files

58
src/docs/FUTURE_WORK.md
View file

@ -49,4 +49,60 @@ at election time rather than silently producing dual-primary split-brain.
Test that a standby correctly returns an error reply with the primary's address
when an admin tool sends `OP_upgradeConfig` to a standby, and the admin tool
retries against the primary.
retries against the primary.
---
## 6. validate_host() Implementation Plan
`validate_host()` is currently a stub that returns success for all peers. Before
`CONF_ENABLE_UPGRADE_CONFIG` can be set to 1, it MUST be enhanced with a real
authorisation check. Minimum viable implementation:
- Verify the peer's X.509 certificate Common Name (CN) against a configured
allowlist of authorised admin hosts.
- Add `--admin-cn` CLI flag or `admin_cn_list` config field to specify allowed CNs.
- Reject `OP_upgradeConfig` requests from peers whose CN is not in the allowlist
with a clear error message.
- Log all rejected attempts at WARN level with peer CN and IP.
Future extensions (not required for gate removal): IP allowlist, role-based
access, mutual-TLS with admin-specific CA.
---
## 7. OP_replConfig Access Control Hardening
`OP_replConfig` currently serves the full cluster config blob to any peer that
completes an SSL handshake with a CA-signed cert (trusted-LAN model, §5.3).
Enhancements to consider:
- Verify the requesting peer is a known controller (listed in `--peers`) before
serving the config blob.
- Rate-limit `OP_replConfig` requests per peer to prevent repeated disk I/O on
the primary.
- Add a `minimum_role` check (e.g., only serve to `HostRole_controller` peers,
not arbitrary SSL clients).
---
## 8. Lost-and-Found Internal Keyword Validation
The name `"lost_and_found"` is an internal controller keyword for synthetic
queue and host entries created during WAL recovery (§6.5). The controller
rejects this name at both `load_primary_config()` and `OP_upgradeConfig` entry
points.
**Config tool responsibility**: The admin config tool (Future Work §1) MUST
validate that user-authored config files do not use the reserved names
`"lost_and_found"` for any queue or host. The tool should emit a clear error
and refuse to encode the config blob. This provides defence-in-depth: the
controller enforces at runtime, and the tool prevents at authoring time.
**Migration path for pre-existing clusters**: If a cluster already has a
user-defined queue or host named `"lost_and_found"` before upgrading to this
controller version, the operator must rename it in the cluster config YAML
before the upgrade. The admin config tool will validate this; if bypassing
the tool and hand-crafting a Cap'n Proto blob, the controller's
`load_primary_config()` will FATAL with a message identifying the reserved
name. See `config-replication-design.md` §6.5 and §7.1.