tigera · ctauchen · Feb 24, 2026 · Feb 25, 2026 · Feb 26, 2026
@@ -28,7 +28,6 @@ The $[prodname] network plugins provide a range of networking options to fit you
   <DocCardLink docId='networking/configuring/workloads-outside-cluster' />
   <DocCardLink docId='networking/configuring/pod-mac-address' />
   <DocCardLink docId='networking/configuring/node-local-dns-cache' />
-  <DocCardLink docId='networking/configuring/add-maglev-load-balancing' />
 </DocCardLinkLayout>
 
 ## IP address management

@@ -259,8 +259,8 @@ spec:
               <p>
                 The following example of a NodePort service may not be suitable for production and high availability.
                 For options, see{' '}
-                <Link href={`${baseUrl}/multicluster/mcm/fine-tune-deployment`}>
-                  Fine-tune multi-cluster management for production
+                <Link href={`${baseUrl}/multicluster/reference/port-and-service-requirements`}>
+                  Port and service requirements
                 </Link>
                 .
               </p>

@@ -330,8 +330,8 @@ spec:
               <p>
                 The following example of a NodePort service may not be suitable for production and high availability.
                 For options, see{' '}
-                <Link href={`${baseUrl}/multicluster/mcm/fine-tune-deployment`}>
-                  Fine-tune multi-cluster management for production
+                <Link href={`${baseUrl}/multicluster/reference/port-and-service-requirements`}>
+                  Port and service requirements
                 </Link>
                 .
               </p>

@@ -146,8 +146,8 @@ spec:
             <p>
               The following example of a NodePort service may not be suitable for production and high availability. For
               options, see{' '}
-              <Link href={`${baseUrl}/multicluster/mcm/fine-tune-deployment`}>
-                Fine-tune multi-cluster management for production
+              <Link href={`${baseUrl}/multicluster/reference/port-and-service-requirements`}>
+                Port and service requirements
               </Link>
               .
             </p>

@@ -156,8 +156,8 @@ spec:
               <p>
                 Create a service to expose the management cluster. The following example of a NodePort service may not
                 be suitable for production and high availability. For options, see{' '}
-                <Link href={`${baseUrl}/multicluster/mcm/fine-tune-deployment`}>
-                  Fine-tune multi-cluster management for production
+                <Link href={`${baseUrl}/multicluster/reference/port-and-service-requirements`}>
+                  Port and service requirements
                 </Link>
                 . Apply the following service manifest.
               </p>

@@ -295,8 +295,8 @@ spec:
               <p>
                 Create a service to expose the management cluster. The following example of a NodePort service may not
                 be suitable for production and high availability. For options, see{' '}
-                <Link href={`${baseUrl}/multicluster/mcm/fine-tune-deployment`}>
-                  Fine-tune multi-cluster management for production
+                <Link href={`${baseUrl}/multicluster/reference/port-and-service-requirements`}>
+                  Port and service requirements
                 </Link>
                 . Apply the following service manifest.
               </p>

@@ -40,7 +40,7 @@ All of this is built on Calico Open Source, the most widely used container netwo
     description='Secure outbound traffic with fixed, routable IP assignment'
   />
   <DocCardLink
-    docId='multicluster/federation/overview'
+    docId='multicluster/explanation/cluster-mesh'
     title='Cluster Mesh'
     description='Resilient and secure networking between clusters at scale'
   />
@@ -127,7 +127,7 @@ All of this is built on Calico Open Source, the most widely used container netwo
   />
 
   <DocCardLink
-    docId='multicluster/set-up-multi-cluster-management/standard-install/create-a-management-cluster'
+    docId='multicluster/how-to/create-a-management-cluster'
     title='Multi-Cluster Controls'
     description='Manage network security and observability for multiple clusters'
   />

@@ -127,8 +127,8 @@ To install a standard $[prodname] cluster with Helm:
 
 **Multicluster Management**
 
-- [Create a $[prodname] management cluster](../../../multicluster/set-up-multi-cluster-management/standard-install/create-a-management-cluster.mdx)
-- [Create a $[prodname] managed cluster](../../../multicluster/set-up-multi-cluster-management/standard-install/create-a-managed-cluster.mdx)
+- [Create a $[prodname] management cluster](../../../multicluster/how-to/create-a-management-cluster.mdx)
+- [Create a $[prodname] managed cluster](../../../multicluster/how-to/create-a-managed-cluster.mdx)
 
 **Recommended**
 

@@ -0,0 +1,71 @@
+---
+description: Understand the architecture of Calico Enterprise multi-cluster management, including management and managed cluster topology, the guardian component, and communication model.
+---
+
+# Multi-cluster management architecture
+
+$[prodname] multi-cluster management lets you centralize control of multiple Kubernetes clusters in a single management plane. This page explains the architectural components and how they interact.
+
+## Management and managed cluster topology
+
+A multi-cluster management deployment consists of two cluster roles:
+
+- **Management cluster**: The central cluster that hosts the $[prodname] web console (Manager), centralized log storage (Elasticsearch), and the control plane for all connected clusters.
+- **Managed cluster**: A cluster that connects to the management cluster and forwards its log data, telemetry, and resource information to the central management plane.
+
+A management cluster can manage many managed clusters. Each managed cluster maintains a persistent connection to the management cluster.
+
+### What the management cluster provides
+
+- Centralized web console for visibility and control across all clusters
+- Centralized Elasticsearch for log storage (flow logs, audit logs, DNS logs, L7 logs, events)
+- Aggregated Prometheus metrics
+- Cross-cluster RBAC enforcement — users authenticate on the management cluster and their identity is passed to managed clusters for authorization
+
+### What managed clusters handle locally
+
+- Local policy enforcement and data plane operations
+- Local $[prodname] components (calico-node, Typha, kube-controllers)
+- Connection to the management cluster via a `ManagementClusterConnection` resource
+
+## Communication model
+
+Managed clusters connect to the management cluster over **port 9449** (TCP). The management cluster exposes this port through a Kubernetes Service in the `calico-system` namespace that targets the Manager pod using the label selector `k8s-app: calico-manager`.
+
+The service type can be:
+
+- **NodePort** — simplest for getting started; maps an external port (e.g. 30449) to 9449 on the Manager pod.
+- **LoadBalancer** — recommended for production and high availability.
+
+A security rule or firewall rule is required to allow inbound connections from managed clusters to the management cluster on this port.
+
+## Key custom resources
+
+| Resource | Cluster | Purpose |
+|---|---|---|
+| `ManagementCluster` | Management | Declares the cluster as a management cluster and specifies the address managed clusters use to connect. |
+| `ManagedCluster` | Management | Registers a managed cluster, triggers generation of an installation manifest. |
+| `ManagementClusterConnection` | Managed | Connects the managed cluster to the management cluster. Applied from the manifest generated by the `ManagedCluster` resource. |
+
+## Guardian
+
+Guardian is the component on managed clusters that maintains the connection to the management cluster. It is deployed automatically when the `ManagementClusterConnection` is applied to a managed cluster. Guardian:
+
+- Establishes and maintains a secure tunnel to the management cluster
+- Forwards log data to centralized storage
+- Proxies API requests from the management cluster to local cluster resources
+
+## Log data flow
+
+All log data from managed clusters flows through the Guardian tunnel to the management cluster's Elasticsearch instance. Indexes are namespaced by cluster name using the pattern:
+
+```
+<log-type>.<cluster-name>.<date>
+```
+
+The management cluster itself uses the cluster name `cluster`. Managed clusters use the name chosen during registration.
+
+## Next steps
+
+- [Cluster mesh and federation](cluster-mesh.mdx)
+- [Security model](security-model.mdx)
@@ -0,0 +1,94 @@
+---
+description: Understand how Calico Enterprise cluster mesh enables cross-cluster endpoint identity, federated services, and multi-cluster networking.
+---
+
+# Cluster mesh
+
+## Overview
+
+$[prodname] cluster mesh secures cross-cluster connections with identity-aware network policy and federates services for cross-cluster service discovery. It also provides multi-cluster networking to establish cross-cluster connectivity.
+
+## Why cluster mesh
+
+By default, pods can only communicate with pods within the same cluster. Services and network policy only select pods from the local cluster. $[prodname] cluster mesh overcomes these barriers with three features:
+
+- **Federated endpoint identity** — A local cluster includes the workload and host endpoints of remote clusters in the calculation of local network policies on each node.
+- **Federated services** — A local Kubernetes Service populates with Endpoints selected from both local and remote cluster Services.
+- **Multi-cluster networking** — An overlay network between clusters provides cross-cluster connectivity.
+
+## Pod IP routability
+
+$[prodname] cluster mesh operates at the network layer based on pod IPs.
+
+Federated endpoint identity and federated services both require that pod IPs are routable between clusters. Identity-aware network policy needs source and destination pod IPs preserved to establish pod identity. Federated Service endpoints must also be routable to be useful.
+
+You can establish pod IP routability in two ways:
+
+- **$[prodname] multi-cluster networking** — extends the overlay network (VXLAN and/or WireGuard) between clusters.
+- **Network-provided routing** — manually set up routing without encapsulation (e.g. VPC routing, BGP routing).
+
+## Federated endpoint identity
+
+Federated endpoint identity allows a local cluster to include remote cluster endpoints in local policy calculations. For example, Cluster A can write a network policy that allows its application pods to talk to database pods in Cluster B.
+
+Key points:
+
+- Network policies are **not** federated — policies from a remote cluster are not applied to local endpoints.
+- Only the local cluster's policies are rendered and applied locally.
+- Rule selectors can reference both local and remote endpoints based on labels.
+
+This works because each cluster synchronizes endpoint data from remote clusters via `RemoteClusterConfiguration` resources. Traffic from remote clusters preserves pod IPs, and the local cluster associates those IPs with the pod specifications it synchronized.
+
+## Federated services
+
+Federated services provide cross-cluster service discovery. A federated service consolidates endpoints from services across all clusters in the mesh into a single local Service.
+
+The Tigera Federated Services Controller manages federated services:
+
+- It monitors services across all clusters in the mesh.
+- It populates a local federated service with endpoints matching a `federation.tigera.io/serviceSelector` annotation.
+- It does not change configuration on remote clusters.
+
+A federated service uses an annotation instead of a pod selector:
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+  name: my-app-federated
+  namespace: default
+  annotations:
+    federation.tigera.io/serviceSelector: run == "my-app"
+spec:
+  ports:
+    - name: my-app-ui
+      port: 8080
+      protocol: TCP
+  type: ClusterIP
+```
+
+Endpoints are selected only when the service port name and protocol in the federated service matches the port name and protocol in the backing service. If you have an existing service discovery mechanism, federated services are optional.
+
+## Multi-cluster networking
+
+$[prodname] multi-cluster networking extends the overlay network of a cluster to include nodes from remote clusters. This is made possible by each cluster having a view into the datastore that includes remote pods and nodes.
+
+Multi-cluster networking uses the `overlayRoutingMode` field in `RemoteClusterConfiguration`. When set to `Enabled`, the cluster establishes cross-cluster overlay routes.
+
+Both VXLAN and WireGuard are supported for cross-cluster routing. If both are enabled and a WireGuard peer is not ready, communication falls back to VXLAN.
+
+## How the mesh is formed
+
+The cluster mesh is formed by a set of bidirectional `RemoteClusterConfiguration` connections:
+
+1. Each cluster creates a `kubeconfig` with limited credentials for remote clusters to use.
+2. Each cluster creates a `RemoteClusterConfiguration` for every other cluster, referencing the remote cluster's `kubeconfig` stored in a Secret.
+3. Typha connects to each remote cluster's API server using the stored credentials and synchronizes endpoint, node, and IP pool data.
+
+For a mesh of clusters A, B, and C, you need `RemoteClusterConfiguration` resources for each pair in both directions: \{A→B, B→A, A→C, C→A, B→C, C→B\}.
+
+## Next steps
+
+- [Security model](security-model.mdx)
+- [Set up cluster mesh](../how-to/set-up-cluster-mesh.mdx)
+- [Configure federated services](../how-to/configure-federated-services.mdx)
@@ -1,9 +1,9 @@
 ---
-description: Steps to configure cluster mesh.
+description: Understand multi-cluster management and cluster mesh concepts.
 hide_table_of_contents: true
 ---
 
-# Federation and multi-cluster networking
+# Concepts
 
 import DocCardList from '@theme/DocCardList';
 import { useCurrentSidebarCategory } from '@docusaurus/theme-common';

@@ -0,0 +1,81 @@
+---
+description: Understand the security model for Calico Enterprise multi-cluster management, including credential generation, certificate management, and cross-cluster RBAC.
+---
+
+# Security model
+
+This page explains how $[prodname] secures communication and enforces access control across management and managed clusters, as well as within a cluster mesh.
+
+## Management cluster connection security
+
+### Certificate-based authentication
+
+When a managed cluster is registered on the management cluster (via a `ManagedCluster` resource), an installation manifest is generated containing a `ManagementClusterConnection` with the credentials the managed cluster needs to connect. The Guardian component on the managed cluster uses these credentials to establish and maintain a secure tunnel to the management cluster over port 9449.
+
+For Helm-based installations, certificates are generated explicitly:
+
+1. A self-signed certificate and key pair is generated for each managed cluster.
+2. The managed cluster's certificate is registered on the management cluster.
+3. The management cluster's TLS certificate is provided to the managed cluster for verification.
+
+This mutual TLS model ensures that both sides of the connection are authenticated.
+
+### User identity propagation
+
+When a user accesses a managed cluster's resources through the management cluster web console:
+
+1. The user authenticates against the management cluster using a service account or user account.
+2. The management cluster passes the user's identity to the managed cluster for authorization.
+3. The managed cluster evaluates the request against its own Kubernetes RBAC rules.
+
+This means:
+- All users must have a valid account on the management cluster to log in.
+- Users must have the **same username** defined on both the management cluster and any managed clusters they access.
+- A user can have different permissions on each managed cluster, defined by Kubernetes Role and ClusterRole objects, but the username in the corresponding RoleBinding/ClusterRoleBinding must match.
+
+## Cluster mesh security
+
+### Federation credentials
+
+Each cluster in a cluster mesh creates a dedicated ServiceAccount (`tigera-federation-remote-cluster`) with limited permissions for remote clusters to use. The credentials flow is:
+
+1. A ServiceAccount is created in the `calico-system` namespace.
+2. A ClusterRole and ClusterRoleBinding grant the account read-only access to the resources needed for federation (endpoints, nodes, IP pools, profiles).
+3. A `kubeconfig` is generated from the ServiceAccount token and the cluster's API server certificate.
+4. The `kubeconfig` is shared with remote clusters and stored as a Kubernetes Secret.
+
+### Secret access control
+
+When a cluster stores a remote cluster's `kubeconfig` as a Secret, Typha needs access to read it. An RBAC Role and RoleBinding in the secret's namespace grants the `calico-typha` ServiceAccount permission to watch, list, and get secrets in that namespace.
+
+### Credential verification
+
+You can verify that stored credentials work by extracting the kubeconfig from the secret and testing it:
+
+```bash
+kubectl get secret -n <secret-namespace> remote-cluster-secret-name \
+  -o=jsonpath="{.data.kubeconfig}" | base64 -d > verify_kubeconfig
+kubectl --kubeconfig=verify_kubeconfig get nodes
+```
+
+## Log data access control
+
+Log data from all managed clusters is stored in centralized Elasticsearch on the management cluster. Access to log data is controlled using Kubernetes RBAC:
+
+- The API group is `lma.tigera.io`.
+- `resources` controls access by cluster name.
+- `resourceNames` controls access by log type (`flows`, `audit`, `audit_ee`, `audit_kube`, `events`, `dns`, `l7`).
+
+For example, to allow access to flow and DNS logs for a specific cluster:
+
+```yaml
+- apiGroups: ['lma.tigera.io']
+  resources: ['app-cluster']
+  resourceNames: ['flows', 'dns']
+  verbs: ['get']
+```
+
+## Next steps
+
+- [Configure cross-cluster RBAC](../how-to/configure-cross-cluster-rbac.mdx)
+- [Architecture](architecture.mdx)