Support multi-cluster deployments (Central + SecuredCluster on separate clusters)

[AlexVulaj]

Summary

Roxie currently assumes Central and SecuredCluster are deployed on the same Kubernetes cluster. Many ACS customers and internal teams run a hub + spoke architecture where Central lives on one cluster and one or more SecuredClusters are deployed to separate clusters. This PR adds multi-cluster support so that roxie can deploy a SecuredCluster that points to a Central running on a different cluster.

Users set the SecuredCluster CR's centralEndpoint directly via config file:

# spoke-config.yaml
securedCluster:
  spec:
    centralEndpoint: "central.example.com:443"

ROX_ADMIN_PASSWORD=<admin-password> \
ROX_CA_CERT_FILE=<path-to-ca-cert> \
roxie deploy secured-cluster -t 4.9.2 -c spoke-config.yaml

When spec.centralEndpoint is provided, roxie preserves it. When it is not set, roxie defaults to the internal central.<namespace>.svc:443 endpoint, preserving full backward compatibility. Authentication to Central for CRS generation uses the existing ROX_ADMIN_PASSWORD and ROX_CA_CERT_FILE environment variables.

Testing

• Single-cluster deploy on GKE (regression test): verified default behavior is unchanged
• Multi-cluster deploy on GKE (new feature): Central on cluster A, SecuredCluster on cluster B with spec.centralEndpoint pointing to cluster A — both deployed and connected successfully, sensor logs confirmed connection to remote Central

Closes #99

Summary by CodeRabbit

Release Notes

• Documentation

  • Added multi-cluster deployment guide covering hub-and-spoke setup with step-by-step instructions for Central and SecuredCluster configuration.

• Improvements

  • Enhanced handling of custom central endpoint configuration to preserve user-provided values and display them in deployment summaries.

[davdhacs]

This will be very helpful for Infra and e2e testing. In Infra/Automation, we've had a long-term todo of adding multi-cluster capability to the demo (ansible scripts) and repeated asks/investigations on various teams have looked at multi-cluster deploys for automated testing.
+1

[AlexVulaj]

Holding this PR until we can have further discussions around the UX of the feature.

[AlexVulaj]

Ready for re-review @porridge @mclasmeier

[porridge]

FTR I don't have anything to add over what @mclasmeier wrote.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yml

Review profile: CHILL

Plan: Enterprise

Run ID: 5b1bd8d3-20e9-4602-8436-1f99deced4f3

📥 Commits

Reviewing files that changed from the base of the PR and between c80aa1d and 3ee5f42.

📒 Files selected for processing (1)

• internal/deployer/central_endpoint_test.go

🚧 Files skipped from review as they are similar to previous changes (1)

• internal/deployer/central_endpoint_test.go

---

📝 Walkthrough

Walkthrough

This PR enables hub-and-spoke multi-cluster deployments by allowing an explicit centralEndpoint to be specified when deploying SecuredCluster to a separate cluster. The configuration logic respects user-provided values while supplying internal defaults, test coverage validates the precedence rules, and user documentation explains the deployment pattern.

Changes

Multi-cluster deployment support

Layer / File(s)	Summary
Central endpoint configuration and validation internal/deployer/config.go, internal/deployer/central_endpoint_test.go	SecuredClusterConfig.ConfigureSpec now sets spec.centralEndpoint only when absent, preserving any user-provided value; added table-driven tests validating default construction from CentralConfig.Namespace, namespace customization, explicit preservation, and user-value precedence.
Summary display and user documentation internal/deployer/deployer.go, README.md	Deployment summary conditionally prints the Central Endpoint when a non-default value is configured; README adds a "Multi-cluster deployments" section with hub-and-spoke deployment steps and an automation tip.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Poem

🐰 A hub speaks to spokes across the lands so far,
Where Central shines bright like a guiding star.
Config keeps your endpoint if you set it by hand,
Tests prove the defaults, and docs lend a hand.
Hooray for clusters talking near and far!

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately summarizes the main change: enabling multi-cluster deployments where Central and SecuredCluster can run on separate clusters.
Linked Issues check	✅ Passed	The pull request successfully addresses all coding requirements from issue #99: enabling multi-cluster deployments by allowing SecuredCluster to point to external Central endpoints while maintaining backward compatibility.
Out of Scope Changes check	✅ Passed	All changes align with the scope of issue #99: README documentation for multi-cluster setup, implementation of centralEndpoint configuration, tests for the feature, and summary display logic.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch multi-cluster-support

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[mclasmeier]

looking good, thank you, just a few nits for the test.