Manage Kubernetes Clusters with Red Hat ACM

Red Hat Advanced Cluster Management for Kubernetes (ACM) is an enterprise-grade management platform designed to solve the “cluster sprawl” problem.

As an organization grows, managing security, configurations, and applications across a single Kubernetes cluster evolves into managing dozens or hundreds of clusters spread across multiple public clouds (AWS, Azure, GCP) and on-premises datacenters. ACM acts as a centralized control plane—a single pane of glass—to govern your entire global fleet.

ACM is architected around a Hub-and-Spoke model. You designate one stable OpenShift cluster as the Hub, and it manages all other clusters, which are referred to as Managed Clusters (Spokes).

The Four Core Pillars of ACM

ACM delivers value across four primary operational areas:

1. Multicluster Lifecycle Management

ACM treats clusters the same way Kubernetes treats pods. It allows you to provision, upgrade, and destroy clusters programmatically across hybrid cloud environments.

  • Centralized Provisioning: You can spin up a Red Hat OpenShift on AWS (ROSA) cluster, an Azure Red Hat OpenShift (ARO) cluster, or a bare-metal cluster directly from the ACM console or via an API.
  • Single-Click Upgrades: SRE teams can trigger cluster version upgrades across multiple global regions simultaneously.
  • Discovery: ACM can scan your cloud provider accounts to find existing, unmanaged Kubernetes clusters (such as standard EKS, AKS, or GKE environments) and bring them under your central governance canopy.
2. Policy-Based Governance & Compliance

Instead of manually checking if each cluster is secure, ACM introduces Policy-As-Code. You define a desired security compliance state once on the Hub cluster, and ACM continuously enforces it on all managed spokes.

  • Automated Remediation: If a policy dictates that all production clusters must have a specific NetworkPolicy active, and a local cluster administrator deletes it, ACM will instantly flag it as “Non-Compliant” and can be configured to automatically recreate it (Self-Healing).
  • Regulatory Compliance: ACM comes pre-built with policy templates to measure your infrastructure’s posture against standards like PCI-DSS, HIPAA, and CIS Benchmarks.
3. Advanced Multicluster Application Delivery

Deploying an application to one cluster is simple. Deploying a highly available microservice to 50 target clusters spread globally requires advanced orchestration. ACM integrates natively with Subscription channels and GitOps (ArgoCD).

  • Placement Rules: You can define smart rules using Kubernetes labels. For example: “Deploy this backend application to any cluster labeled environment=production and region=eu-west.”
  • Dynamic Balancing: If you spin up a brand new cluster in Europe next week and label it appropriately, ACM will instantly recognize it and deploy the application payloads to it without you modifying your application pipeline.
4. Multicluster Observability & Networking

ACM centralizes performance metrics and multi-cluster container cross-communication.

  • Aggregated Telemetry: Rather than logging into 50 different Grafana dashboards, ACM leverages an optimized, long-term storage engine (Thanos) to aggregate operational alerts, capacity constraints, and compute metrics from every spoke back into a single viewpoint.
  • Submariner Integration: ACM simplifies multi-cluster networking by configuring Submariner, an open-source tool that creates secure, direct VPN tunnels between worker nodes in entirely different geographical clouds, allowing pods in AWS to talk directly to pods on-premises via private IP space.

Why Enterprises Use ACM (The Value Metric)

Operational ChallengeWithout ACMWith ACM
Cluster UpgradesSREs must manually SSH/log into each cluster and run commands sequentially.One centralized dashboard orchestrating rolling updates to a cluster fleet.
Config DriftLocal configurations slowly drift apart over time, causing silent deployment errors.Continuous policy reconciliation ensures all clusters remain perfectly identical.
Identity & RBACAdmin access must be mapped and maintained inside every unique cluster API.Map access permissions once at the Hub layer; it propagates cleanly down to spokes.

ACM vs. Standard GitOps (ArgoCD/Flux)

A common point of confusion is how ACM differs from pure GitOps engines:

  • Tools like ArgoCD and Flux excel at ensuring the files inside a Git repository match the resources inside a single cluster ecosystem.
  • ACM operates at a layer above. It acts as the orchestrator of the GitOps engines. ACM can deploy ArgoCD onto 20 new clusters simultaneously, pass them their environment-specific parameters, configure the cluster firewalls, and monitor the overarching infrastructure compliance state across all 20 regions.

Here is an example of an ACM Policy manifest.

An ACM policy is broken down into two main parts:

  1. The Governance Rule (Policy): This defines what resource must exist on your clusters (e.g., a mandatory NetworkPolicy, an RBAC configuration, or a specific security setting).
  2. The Target Selector (PlacementBinding): This uses Kubernetes labels to dictate which specific clusters in your global fleet must receive and enforce this policy.

The Global Compliance Blueprint

This policy ensures that Host Networking is completely disabled across all production clusters to prevent containers from sniffing traffic or bypassing cluster security boundaries.

YAML

apiVersion: policy.open-cluster-management.io/v1
kind: Policy
metadata:
name: policy-disable-host-network
namespace: open-cluster-management-global-set
spec:
remedyAction: enforce # Options: 'inform' (just report violations) or 'enforce' (automatically fix them)
disabled: false
policy-templates:
- objectDefinition:
apiVersion: policy.open-cluster-management.io/v1
kind: ConfigurationPolicy
metadata:
name: config-gatekeeper-host-network
spec:
complianceType: musthave # The resource MUST exist exactly as declared below
remediationAction: enforce
object-templates:
- complianceType: musthave
objectDefinition:
# This injects an OPA/Gatekeeper rule into the managed cluster
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sConstraintHostNetwork
metadata:
name: production-block-host-network
spec:
match:
kinds:
- apiGroups: [""]
kinds: ["Pod"]
---
apiVersion: apps.open-cluster-management.io/v1
kind: PlacementBinding
metadata:
name: bind-host-network-policy
namespace: open-cluster-management-global-set
subFilter: ClusterAndGroup
placementRef:
name: placement-production-clusters # Points to the targeting rule below
apiGroup: apps.open-cluster-management.io
kind: PlacementRule
subjects:
- name: policy-disable-host-network
apiGroup: policy.open-cluster-management.io
kind: Policy
---
apiVersion: apps.open-cluster-management.io/v1
kind: PlacementRule
metadata:
name: placement-production-clusters
namespace: open-cluster-management-global-set
spec:
# This targets ANY cluster with these matching labels in ACM
clusterSelector:
matchExpressions:
- key: environment
operator: In
values:
- production
- key: cloud
operator: In
values:
- aws
- azure

Operational Mechanics: Inform vs. Enforce

Inside an ACM policy, the remediationAction field is your configuration dial for risk mitigation.

  • remediationAction: inform: ACM acts purely as an automated compliance scanner. If an administrator manually modifies a cluster and breaks a security standard, ACM changes that cluster’s status to Non-Compliant on the central console dashboard and fires off an alert to your security team (via Slack, Splunk, or PagerDuty), but it does not touch the cluster. This is ideal for testing new policies before rolling them out broadly.
  • remediationAction: enforce: ACM acts as an automated, self-healing system. The moment a cluster drifts away from the target standard, the ACM Hub intercepts it and immediately re-applies the desired configuration, completely overriding the manual configuration drift.

Monitoring Compliance at Scale

Once this policy manifest is saved to your GitOps workflow and reconciled by the Hub, ACM continuously executes a compliance check across your infrastructure.

If you view your centralized dashboard console, you get a clean grid showing every cluster. If an application team introduces a non-compliant deployment on a cluster in Frankfurt, that specific grid block turns red, giving your engineering team an instant, unified view of security governance posture across thousands of global worker nodes.

Leave a Reply