Red Hat Advanced Cluster Security for Kubernetes
Kubernetes makes it easy to ship applications fast, but keeping those clusters secure is a different story. Containers come and go, images pull in dependencies you never looked at, and one misconfigured deployment can open a door you didn’t know existed.
That’s the problem Red Hat Advanced Cluster Security for Kubernetes (RHACS) is built to solve. It’s a Kubernetes-native security platform, based on the open source StackRox project, that protects your workloads across the whole lifecycle: when you build them, when you deploy them, and while they’re running. It works on Red Hat OpenShift and on other Kubernetes platforms like EKS, AKS and GKE, and you can run it yourself or use the managed RHACS Cloud Service.
Under the hood, RHACS has two main parts:
- Central: the control plane you install once, usually on a hub cluster. It hosts the web console, the API, the policy engine, the Scanner and the database, and it’s where you manage everything.
- Secured Cluster: the components you install on every cluster you want to protect. Sensor watches the cluster and reports back to Central, Collector monitors runtime and network activity on each node, and the Admission controller blocks deployments that break your policies.
In short: RHACS gives you one place to see what’s running in your clusters, spot what’s risky, and stop problems before they reach production.
Key Features
Vulnerability management Scans container images and running workloads for known vulnerabilities (CVEs), and shows you which ones actually matter based on what’s deployed and exposed.
Risk profiling Ranks your deployments by overall risk, combining vulnerabilities, configuration issues and runtime activity, so your team knows where to start.
Security policies Comes with a large set of built-in policies and lets you write your own. Policies can alert you or actively block risky builds and deployments.
Configuration management Flags risky settings such as privileged containers, missing resource limits, exposed secrets or overly broad RBAC permissions.
Network segmentation A visual network graph shows how your workloads talk to each other, and RHACS can generate Kubernetes network policies to lock down traffic that shouldn’t be happening.
Runtime detection and response Watches running containers for suspicious behavior, like unexpected processes or privilege escalation, and can respond by killing the pod.
Compliance Checks your clusters against common standards such as CIS Benchmarks, NIST, PCI DSS and HIPAA, with reports you can share with auditors.
DevOps and CI/CD integration The roxctl CLI and API plug security checks straight into your pipelines, so issues are caught at build time instead of after deployment (shift-left security).
Integrations Connects with image registries, SIEM tools, incident management platforms and chat tools like Slack, so alerts land where your team already works.
Multi-cluster visibility Manage security for many clusters, across clouds and on-premises, from a single central dashboard.
Part 1
Install RHACS and Apply Deploy-Time and Runtime Policies
On your OpenShift cluster, go to OperatorHub, search for “Advanced Cluster Security for Kubernetes”, and click Install.
Keep the default configuration options and click Install.
The installation completed successfully.
Click Create Central to deploy the Central instance.
Once Central is installed, you can access the Advanced Cluster Security for Kubernetes dashboard. Log in to the dashboard .
You can integrate multiple Kubernetes clusters with a single Red Hat Advanced Cluster Security instance and manage the security of all of them from one RHACS UI.
Select the init bundle installation method. You can also choose to create a cluster registration secret instead.
Enter a name and select OpenShift, since I am integrating an OpenShift cluster. Choose Operator as the installation method and click Download.
Apply the downloaded YAML file on the cluster. It creates the secrets required for the integration.
Configure the Secured Cluster.
Once the Secured Cluster configuration is complete, you can see the cluster in the Advanced Cluster Security UI. Check the health status of all the services and make sure they are healthy.
Test Deploy-Time and Runtime Policies:-
By default, RHACS comes with built-in policies. You can also create your own custom policies based on your requirements.
For testing, let’s clone an existing CPU and memory limit policy, set it to enforce, and then try to deploy a pod without specifying CPU and memory limits to see whether the policy works.
By default, the “No CPU request or memory limit specified” policy only informs; it does not enforce. Let’s clone it and set it to enforce, so that any pod without CPU and memory limits is blocked from deploying. Click Actions, then click Clone policy.
Enter a name, keep the other settings at their defaults, and click Next.
You can apply a policy at different lifecycle stages: Build, Deploy, Build and Deploy, or Runtime. Here I am testing deploy time, so choose Deploy and click Next.
Keep the default configuration and click Next.
I am applying the policy only to namespaces whose names start with “test”. You can scope a policy based on your requirements, such as multiple namespaces or all namespaces in a cluster, and you can also apply it to a specific cluster. Here I am applying it to namespaces starting with “test”, such as test123, test344 and so on. Click Next.
Set the policy status to Enabled, set the response to Inform and enforce, select enforcement at deploy time, and click Next.
Click Save to save the policy.
The policy was created successfully. Now let’s try to deploy a container in the test123 namespace without specifying CPU and memory settings.
I am deploying a CentOS Stream 9 pod without CPU and memory specifications (I commented out those lines). Let’s deploy it and see what happens.
The deployment failed, and the error shows the policy that is blocking the pod from being deployed on the cluster.
In the Advanced Cluster Security dashboard, you can see this on the Violations page, with the enforcement action “Blocked deployment create”. Any pod deployed without CPU or memory specifications in a namespace starting with “test” will now fail. Deploy-time policy testing is complete.
Now let’s update the YAML file, uncomment (or add) the CPU and memory specifications, and try deploying the pod again.
This time, the deployment is successful.
Let’s log in to the pod and run the dnf install wget command. Right now you can install any package in the container after deployment. Next, let’s configure a runtime policy that blocks any dnf command from running at the pod level.
Runtime Policy Test:-
Let’s clone the existing built-in “Red Hat Package Manager in Image” policy.
After cloning, enter a name and keep the other settings at their defaults.
Make sure you select Runtime as the lifecycle stage so the policy is applied at runtime.
Keep the default configuration and click Next.
I am applying the policy to namespaces whose names start with “test”. You can set the scope based on your requirements: a particular cluster, a particular namespace, multiple namespaces, or all namespaces. Click Next.
Set the policy status to Enabled, set the response to Inform and enforce, select Runtime as the enforcement behavior, and click Next.
Click Save to save the policy.
Let’s deploy the pod using a Deployment. When a runtime policy detects a violation, it automatically kills the pod, and the Deployment recreates it, so a Deployment is the best way to test this.
Once the pod is running, log in to it and run dnf install wget, dnf update, or any other dnf command. The session is terminated immediately and the pod is killed, because the runtime policy blocks any dnf execution at the container level.
As you can see below, the old pod was killed and a new pod was created.
We have now tested policies at deploy time and at runtime. In Part 2, I will cover how to enforce policies at build time, including in a CI/CD pipeline. Advanced Cluster Security also provides many other security features, and you can manage multiple Kubernetes clusters centrally with all the key security features for Kubernetes. Follow and subscribe to my blog, and follow my LinkedIn page for updates on new parts and other useful posts.