Guide to Cluster Landing Zone for Hybrid and Multi-cloud Architecture (Part 3)
July 11, 2023 | by
Release 2.8 of the Red Hat Advanced Cluster Management (RHACM) introduces support for multi-hub federation via a Technology Preview feature named Global Hub. You can leverage this capability to enable more advanced multi-tenancy patterns for the cluster fleet, in addition to those introduced previously in parts 1 and 2 of this series.
Addressing complex multi-tenancy requirements
Prior to the introduction of Global Hub, it was possible to segment a fleet of clusters from a single site-local hub, but this required making a choice early on in the design phase as to whether the concerns of operators (segregation by environment) or those of developers (segregation by teams) became the primary decision driver when defining managed cluster sets. One solution to this problem is establishing multiple site-local hubs (environment-aligned), which are then partitioned into managed cluster sets (team-aligned). However, doing so meant the loss of a single pane-of-glass view across the cluster fleet.
With the introduction of Global Hub, it is now possible to implement this multi-tenancy pattern properly along with a global view of the cluster fleet (initially with respect to policy and compliance). This approach is depicted in the following diagram.
Note that similar to previous multi-tenancy patterns, appropriate guardrails should be put in place to ensure that application teams are able to deploy only authorized resources to authorized namespaces in managed clusters from the set of managed clusters to which their team-based ArgoCD instance is bound. This requires administrators to define AppProject restrictions and enforce these either via Gatekeeper (included with RHACM) or Kyverno policies. Examples of these policies can be found here.
In addition to addressing organizational multi-tenancy requirements, other reasons for considering a multi-hub topology include support for business continuity and scaling out.
Global Hub enables implementing multi-tenancy patterns that address more complex enterprise requirements without losing the single pane-of-glass view. The right choice of multi-tenancy pattern to implement will depend on multiple factors, including organizational operating model, architectural governance principles in force, and general appetite for risk.
External Secrets Operator is a Kubernetes operator that integrates with external secret management systems like AWS Secrets Manager, HashiCorp Vault, Google Secrets Manager, Azure Key Vault, and many ...