System Policies in RHACS

Red Hat Advanced Cluster Security for Kubernetes allows you to use out-of-the-box security policies and define custom multi-factor policies for your container environment.

Configuring these policies enables you to automatically prevent high-risk service deployments in your environment and respond to runtime security incidents.

All of the policies that ship with the product are designed with the goal of providing targeted remediation that improves security hardening.

You’ll see this list contains many Build and Deploy time policies to catch misconfigurations early in the pipeline, but also Runtime policies that point back to specific hardening recommendations.

These policies come from us at Red Hat - our expertise, our interpretation of industry best practice, and our interpretation of common compliance standards, but you can modify them or create your own.

This is what an RHACS policy looks like - front and center you can see the Rationale and Remediation designed to give the DevOps team some context about why this issue is important for security, and more importantly, what to do about the issue.

You might get the impression that we don’t like Package Managers!

While useful, in a container context they just represent a tool that an attacker can use to install software, and don’t have a legitimate use - a container should ship with all of the dependencies it requires.

Policy criteria can cross the build, deploy, and runtime lifecycles.

For example, policies that highlight vulnerabilities in deployments with privileged containers in that deployment.

Another example might runtime criteria - like execution of shell commands - in containers in deployments that have external network exposure.

It’s easy to write a policy that prevents use of compilers and other build tools - except in development clusters, in namespaces for CI/CD tools.

There are no “silos” - other tools require you to manage policies for vulnerabilities and runtime separately.

The unified policy engine allows for targeted conditions and targeted enforcement, easily allowing exceptions for specific applications once approved by security.

As you’ve seen - RHACS focuses on empowering and encouraging developers to understand and resolve security issues in their own deployments.

Sometimes we have to balance the carrot with a little stick, because security officers need to know that dangerous misconfigurations won’t be promoted and deployed in certain environments, and that’s where enforcement of policy comes in.

Enforcement is another demonstration of Kubernetes-native security, leveraging the pipeline process to prevent unacceptable risks.

In the absence of CI/CD integration, or for images that are promoted without going through CI/CD, we leverage the built-in power of a Kubernetes Admission Controller to decide if a deployment can be created.

We’re essentially programming OpenShift to prevent security risk Security gets their enforcement, and DevOps sees a “normal” failure from the OpenShift API, with clear remediation steps instead of a nebulous error that forces them to go open a ticket or look in another console.