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.
Click on the Red Hat Package Manager in Image Policy. Highlight the right-hand side policy details.
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.
Click on the Fixable Severity at least important policy in the list. (It’s usually 20-30 rows down. You can also filter for it by typing “fixable” in the filters bar.
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.
Click Action → Edit Policy in the upper right of the policy
Click Next to see Policy Behavior
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.
Click ON for both Build and Deploy enforcement.
Click Next at the bottom panel until you get to Review Policy page.
|TODO add new policies section|