Red Hat OpenShift Advanced Cluster Security for Kubernetes (ACS)—built on the open-source StackRox technology—is an enterprise-grade, Kubernetes-native security platform.

While tools like OpenShift ACM handle the management and configuration of your fleet, ACS is your automated security officer. It protects your clusters across the entire application lifecycle: from the moment a developer writes code, through the CI/CD build pipeline, to live production runtime.

Because ACS is Kubernetes-native, it doesn’t use generic Linux host agents. Instead, it deploys security sidecars and controllers directly into your cluster’s data plane, leveraging Kubernetes’ native objects and network policies for deep, high-performance monitoring.

The Three Phases of ACS Security

ACS secures your infrastructure across three distinct stages of the software development lifecycle:

1. Build Phase (Preventing Insecure Code)

Security starts long before a pod is deployed. ACS integrates directly into your developer pipelines (Jenkins, Tekton, GitLab, GitHub Actions) to act as a security gate.

• Vulnerability Scanning: It scans container images for known vulnerabilities (CVEs), checking the operating system packages and language dependencies (Java, Python, Node.js).
• Policy Enforcement: If a developer attempts to build a container image containing a “Critical” severity vulnerability, or if the image attempts to package malicious tools like ssh or netcat, ACS can automatically fail the CI/CD build.

2. Deploy Phase (Hardening the Cluster)

Before a container is allowed to run, ACS evaluates its configuration against enterprise security best practices and regulatory compliance frameworks.

• Admission Control: ACS intercepts the deployment request. If an application manifest tries to run a pod with root privileges (privileged: true), lacks a mandatory resource limit, or mounts the host file system directly, ACS blocks the deployment.
• Risk Profiling: ACS automatically ranks every deployment in your cluster with a “Risk Score.” It correlates multiple risk factors (e.g., Is this image vulnerable? Does it have a public route to the internet? Is its file system writable?) so your security team knows exactly which apps to fix first.

3. Runtime Phase (Active Threat Detection)

Even if a container is perfectly safe when deployed, it can still be attacked or compromised while running. This is where ACS’s live detection engine shines.

• Process Baselines: When a pod starts, ACS monitors its behavior for the first few minutes and creates an automated “Process Baseline.” If an Nginx web server suddenly attempts to execute a bash script or run a crypto-miner (xmrig), ACS flags this anomalous behavior instantly.
• Automated Remediation: When a runtime violation occurs, ACS can be configured to take immediate action: it can alert your SRE team via webhooks, or automatically terminate the compromised pod so Kubernetes replaces it with a clean instance.

Core Operational Pillars

Automated Network Policy Generation

One of the most powerful features of ACS is its ability to fix your network firewalls automatically. It listens to the live traffic moving between your microservices, visualizes the communication paths, and generates the YAML NetworkPolicy code required to lock down those pods into a Zero-Trust state. You can review the generated code and push it straight to your GitOps repository.

Comprehensive Compliance Auditing

ACS continuously assesses your clusters against major compliance and regulatory standards out of the box, including:

• CIS Benchmarks (Kubernetes and Docker standards)
• PCI-DSS (Payment card industry security)
• HIPAA (Healthcare privacy and data protection)
• NIST SP 800-190 (Container security guide)

It generates real-time compliance reports across your multi-cluster fleet, showing auditor-ready evidence of your security posture.

Architectural Summary: ACM vs. ACS

It is common to confuse these two flagship Red Hat platforms since they both manage multiple clusters. They are designed to work together, not replace each other:

In OpenShift Advanced Cluster Security (ACS), security controls are declared programmatically as System Policies.

When a developer attempts to deploy a container, the ACS Admission Controller intercepts the request and matches the pod’s metadata, configuration, and image data against these policies. If a violation is found, ACS can either log an alert (inform) or completely block the deployment from starting (enforce).

Here is a production blueprint of an ACS Policy manifest designed to block any container attempting to deploy with known, exploitable remote code execution (RCE) vulnerabilities.

The ACS Deployment Prevention Policy

This policy targets workloads at the Deploy phase. It states that if an image contains a vulnerability with a CVSS score greater than or equal to 9.0 (Critical), and a known fix is available from the vendor, the platform must reject the deployment.

YAML

apiVersion: security.stackrox.io/v1alpha1
kind: SecurityPolicy
metadata:
  name: block-critical-cves-with-fixes
  labels:
    corporate-governance: "true"
spec:
  name: "Block Workloads with Critical Vulnerabilities (CVSS >= 9.0) with Available Fixes"
  description: "Prevents deployment of containers containing critical vulnerabilities where a vendor patch exists."
  rationale: "Allowing known critical exploits with available fixes into production creates unnecessary exposure to remote code execution and data exfiltration."
  remediation: "Update the base image or specific package inside your Dockerfile to pull the patched version specified in the ACS violation log."
  
  # Enable enforcement to actively block the deployment
  lifecycleStages:
    - DEPLOY
  enforcementActions:
    - FAIL_DEPLOYMENT_CREATE_REASON
    
  severity: CRITICAL_SEVERITY
  categories:
    - Vulnerability Management
  # The exact criteria ACS will evaluate
  policyCriteria:
    - cvss: ">= 9.0"
    - fixable: "true"
    
  # Exclude specific namespaces (like legacy systems or sandboxes) if needed
  scope:
    - cluster: "*"
      namespace: "*"
    - exclusions:
        - namespace: "sandbox-experimental"

How It Works in the Deployment Pipeline

When a developer runs oc apply -f deployment.yaml or a GitOps controller like ArgoCD attempts to sync a new image tag, the deployment workflow triggers the following evaluation sequence:

1. Interception: The Kubernetes API receives the deployment request and passes the pod spec to the ACS Admission Webhook.
2. Inspection: ACS quickly cross-references the container image SHA in its centralized database (supplied by continuous updates from upstream vulnerability databases like Red Hat, Mitre, and NVD).
3. Evaluation: ACS detects that the image contains CVE-2021-44228 (Log4Shell), which carries a CVSS score of 10.0 and has a confirmed fix.
4. Enforcement: Because enforcementActions is set to FAIL_DEPLOYMENT_CREATE_REASON, the Admission Webhook rejects the transaction.

What the Developer Sees in the Terminal

Instead of a successful deployment message, the developer’s deployment fails immediately at the CLI layer with a descriptive security rejection:

Plaintext

Error from server (Forbidden): admission webhook "srox-admission-control.stackrox.svc" denied the request: 
Deployment violated corporate SecurityPolicy 'Block Workloads with Critical Vulnerabilities (CVSS >= 9.0) with Available Fixes':
- Description: Prevents deployment of containers containing critical vulnerabilities where a vendor patch exists.
- Violation: Image 'quay.io/enterprise/legacy-app:v1.2' contains 3 critical fixable CVEs:
    * CVE-2021-44228 (CVSS 10.0) found in log4j-core-2.14.1. Fix available in 2.15.0.
- Remediation: Update the base image or specific package inside your Dockerfile to pull the patched version specified in the ACS violation log.

By embedding these programmatic check-points directly into the platform fabric, security shifts completely to the left. Operations and security engineering teams can rest assured that vulnerabilities are caught and handled automatically, protecting production environments without relying on manual audits.