[Controller] Protect the Controller remoting management endpoint with authentication and authorization

[Aias00]

Problem

The Controller remoting server registers privileged operations such as UPDATE_CONTROLLER_CONFIG, GET_CONTROLLER_CONFIG, CLEAN_BROKER_DATA, broker registration, and broker ID allocation without an authentication/authorization request pipeline or credential-verifying RPC hook. The default Netty bind address is 0.0.0.0.

A reachable network peer can therefore invoke Controller management and state-changing requests without credentials.

Impact

In Controller-mode deployments this can expose Controller configuration and allow unauthorized changes to Controller configuration and Broker failover metadata, affecting cluster integrity and availability.

Proposed fix

• Parse and initialize AuthConfig for standalone and embedded Controller startup paths.
• Install the existing authentication and authorization request pipelines on the Controller remoting server.
• Map Controller request codes to cluster-level authorization contexts.
• Add regression coverage that unauthenticated Controller management requests are rejected when authentication is enabled and signed inner-client requests remain accepted.

Temporary mitigation

Bind the Controller to a private interface and restrict network access to intended Brokers and Controller nodes.

[RockteMQ-AI]

🔍 Automated Assessment

Type: Security Enhancement
Severity: HIGH
Status: ✅ Verified against develop branch

Analysis

Code-level verification confirms the Controller remoting server lacks authentication and authorization entirely:

Aspect	Controller	Broker (for comparison)
AuthConfig initialization	❌ Not present	✅ Constructor parameter
AuthenticationPipeline	❌ Not present	✅ Applied to all remoting servers
AuthorizationPipeline	❌ Not present	✅ Applied to all remoting servers
RPCHook registration	❌ None	✅ Supported
Default bind address	0.0.0.0	Configurable

All 12 Controller request codes (UPDATE_CONTROLLER_CONFIG, GET_CONTROLLER_CONFIG, CLEAN_BROKER_DATA, CONTROLLER_REGISTER_BROKER, CONTROLLER_GET_NEXT_BROKER_ID, CONTROLLER_APPLY_BROKER_ID, etc.) are registered via registerProcessor() with no auth checks.

The only existing "protection" is a config-key blacklist in ControllerRequestProcessor that prevents updating certain sensitive config keys — this is a property filter, not authentication.

Proposed Fix Alignment

The proposed fix is well-scoped and aligns with the existing Broker auth architecture:

1. Parse and initialize AuthConfig for standalone and embedded Controller startup paths
2. Install the existing AuthenticationPipeline → AuthorizationPipeline chain on the Controller remoting server
3. Map Controller request codes to cluster-level authorization contexts
4. Add regression tests for unauthenticated request rejection

Temporary Mitigation

Bind the Controller to a private interface and restrict network access via firewall rules.

---

🤖 Evaluated by github-manager | Code verified via static analysis on develop branch

[RockteMQ-AI]

Hi @Aias00! 👋

Thanks for your contribution. This issue has been noted and flagged for maintainer triage.

---

🤖 Automated issue analysis by github-manager

[RockteMQ-AI]

Issue Evaluation

Category: enhancement | Status: Evaluated

Feasibility: Feasible
Scope: Controller module (remoting server, auth pipeline)
Compatibility: Non-breaking when authentication is disabled by default; new auth pipeline only activates when AuthConfig is enabled.

Well-structured report. The Controller remoting server indeed lacks the authentication/authorization request pipeline that exists for Broker and Proxy. The proposed fix aligns with the existing auth architecture.

Key considerations:

• Ensure signed inner-client requests from Brokers to Controller continue working without user-facing credentials.
• The CLEAN_BROKER_DATA and broker ID allocation request codes are high-impact — auth coverage here is important for cluster integrity.
• Regression tests should cover both standalone and embedded Controller startup paths.

---

Automated evaluation by github-manager