Edit

Share via

Use Fleet Manager Managed Namespaces to control user access and resource quotas across multiple clusters (preview)

Applies to ✔️ Fleet Manager with hub cluster

This article provides a conceptual overview of multi-cluster managed namespaces.

Important

Azure Kubernetes Fleet Manager preview features are available on a self-service, opt-in basis. Previews are provided "as is" and "as available," and they're excluded from the service-level agreements and limited warranty. Azure Kubernetes Fleet Manager previews are partially covered by customer support on a best-effort basis. As such, these features aren't meant for production use.

What are multi-cluster managed namespaces?

With multi-cluster managed namespaces on targeted member clusters, platform administrators can define resource quotas, network policies, labels, annotations, and control access to namespace resources. Fleet Manager then automatically places the namespace and its associated resources on the designated member clusters. This extends the capability of AKS managed namespaces, which provide a way to logically isolate workloads within a single cluster.

If the platform administrator specifies member clusters during namespace creation or update, the managed namespace generates a read-only Cluster Resource Placement (CRP) object, with a PickFixed placement policy, to propagate the namespace to the selected member clusters.

Administrators can also control two key behaviors:

  • Adoption Policy: How conflicts are resolved when a managed namespace is placed on a member cluster that already has an unmanaged namespace with the same name
  • Delete Policy: Whether Kubernetes resources are deleted upon managed namespace deletion

Resource quotas

Platform administrators can use resource quotas to cap CPU and memory consumption at the namespace layer.

  • CPU requests and limits: Set the minimum and maximum CPU resources that workloads in the namespace can request or consume.
  • Memory requests and limits: Set the minimum and maximum memory resources that workloads in the namespace can request or consume.

Note

The quotas set for a namespace are applied to each individual member cluster independently, not shared across all clusters in the namespace.

Network policies

Network policies control allowed traffic for pods within a namespace. You can independently select one of three built-in network policies for ingress and egress traffic. If omitted, no network policy is applied to the namespace.

Network policies are applied to each cluster individually and don't control cross-cluster network traffic for the namespace. Each member cluster enforces its own network policy independently within its local namespace instance. Network policies include:

  • Allow all: Allow all network traffic, including traffic between pods and external endpoints.
  • Allow same namespace: Allow all network traffic between pods within the same namespace.
  • Deny all: Deny all network traffic, including traffic between pods and external endpoints.

Note

While platform administrators can set default network policies through the managed namespace configuration, users with sufficient permissions can create extra policies that relax the overall network policy for the namespace.

Labels and annotations

Platform administrators can apply both Kubernetes labels and annotations to the managed namespace. By default, each managed namespace has a built-in label indicating it's managed by ARM.

Adoption policy

When a managed namespace is created, the adoption policy determines how existing unmanaged namespaces are handled if they already exist on the target cluster. Similar to a single cluster namespace, the following options are available:

  • Never: Managed namespace creation fails if a namespace with the same name already exists in the cluster.
  • IfIdentical: Managed namespace creation fails if a namespace with the same name already exists in the cluster, unless the namespaces are identical. If the namespaces are identical, Fleet takes over the existing namespace to be managed.
  • Always: The managed namespace always takes over the existing namespace, even if some resources in the namespace are overwritten.

During adoption a managed namespace may take over fields on a namespace on a member cluster, but it doesn't remove the resources from the namespace.

Delete policy

The delete policy controls how the Kubernetes namespace is handled when the managed namespace resource is deleted. There are two built-in options:

  • Keep: Leaves the Kubernetes namespace intact on the member clusters, but removes the ManagedByARM label.
  • Delete: Removes the Kubernetes namespace and all resources within it from the member clusters.

Note

A delete policy of Delete completely removes the Kubernetes namespace resource and the resources within it from the target member clusters, even if it existed prior to, and was adopted by the multi-cluster managed namespace.

Multi-cluster managed namespace built-in roles

Multi-cluster managed namespaces use the existing Azure Role Based Access Control (RBAC) control plane roles to manage and access managed namespaces. The existing data plane RBAC roles are applied to interact with the managed namespace created on the Fleet Manager hub cluster.

To control access to a managed namespace on member clusters, managed namespaces use the following built-in roles, which can be applied at the namespace scope:

Role Description
Azure Kubernetes Fleet Manager RBAC Reader for Member Clusters • Read-only access to most objects in the namespace on the member cluster.
• Can't view roles or role bindings.
• Can't view secrets (prevents privilege escalation via ServiceAccount credentials).
Azure Kubernetes Fleet Manager RBAC Writer for Member Clusters • Read and write access to most Kubernetes resources in the namespace.
• Can't view or modify roles or role bindings.
• Can read secrets (and can assume any ServiceAccount in the namespace).
Azure Kubernetes Fleet Manager RBAC Admin for Member Clusters • Read and write access to Kubernetes resources in the namespace on the member cluster.
Azure Kubernetes Fleet Manager RBAC Cluster Admin for Member Clusters • Full read/write access to all Kubernetes resources on the member cluster.

For example, a developer in team-A which owns the team-A managed namespace would need to read and write Kubernetes resources in the namespace on the hub cluster. They would also need to read objects in the team-A namespace on the member clusters which it exists on. Consequently, the platform administrator would assign them Azure Kubernetes Fleet Manager RBAC Writer at the fleet scope and Azure Kubernetes Fleet Manager RBAC Reader for Member Clusters at the managed namespace scope for these respective requirements.

Next steps