What’s new in Red Hat Advanced Cluster Security Q1 2022

Over the last few months we’ve continued our investments in security innovations with capabilities designed to improve the operational effectiveness of security programs, including supply chain security. Our latest updates include improvements to vulnerability mangement, security policies, and additional insights and guardrails for common misconfigurations. 

Vulnerability management 

Risk acceptance and exception management

Vulnerability data alone are oftentimes not highly actionable because the true risk of a vulnerability is usually a function of its severity, exploitability, and context in a given runtime environment. 

Sometimes, a vulnerability doesn’t have a fix, or it might pose an acceptable level of risk when evaluated in context. Examples include:

• A non-exploitable vulnerability, such as when the vulnerable component lacks an attack vector or possible access
• A vulnerability that affects software that’s not used at runtime
• A vulnerability that exposes an attack vector that doesn't impact the application
• A misidentified vulnerability
• Compensating controls exist in the environment
• The vulnerability cannot be fixed without breaking required functionality

Developers need a way to identify and flag such vulnerabilities in order to request exceptions to vulnerability management policies. Otherwise, work might come to a grinding halt as they deal with the same false positives over and over, or they may just ignore security guidance all together after they lose faith in its efficacy. 

Red Hat Advanced Cluster Security for Kubernetes now empowers developers to take a more active role in triaging and resolving vulnerabilities. We’ve added new developer workflows to Dev Teams manage vulnerabilities more efficiently by 

• Allowing developer teams to make exceptions and flag vulnerabilities as acceptable risk
• Enabling security teams or team leads to engage in exception approval and validation
• Freeing up developer time spent on building manual workarounds

The new feature includes an approval process to ensure proper governance and (unintentional and intentional) insider threat mitigation in cases where an exception shouldn’t be approved. 

Schedule vulnerability reporting

One of the core pillars of securing containers and Kubernetes is to shift your security efforts to the left, transform developers into security users, and automate DevSecOps within developer workflows. This ensures that security isn’t hindering developer productivity but instead accelerates development by removing security hurdles seamlessly while ensuring security issues are fixed when they’re easiest to fix, during the Dev stages. 

To that end, we’ve introduced new, smarter, vulnerability reporting and notification that provides responsible teams with recurring reports of the most important vulnerabilities. As an example, security and developer teams can now receive a report with a

1. listing of all software components that they’re responsible for
2. that contain high risk, fixable vulnerabilities
3. and steps to remediate them

Our new reporting feature provides a more actionable notification system, delivered to the right team with recommended remediation steps, thereby shortening security feedback loops and further accelerating developer productivity.

Security policy enhancements

At the center of Red Hat Advanced Cluster Security is the policy engine that uses the declarative definitions in Kubernetes along with other details to enforce smarter security policies. We’ve added several new capabilities to our policy engine to address even more of your Kubernetes security and operational readiness use cases.

Service account token protection

Using insecure default settings is among the most common misconfigurations in the technology industry. At the same time, expecting users to understand and secure applications beyond the default settings is sometimes unreasonable and may even reduce development velocity. Systematically setting guardrails, providing guidance, and templating deployment patterns are the best mitigations to the risk of default settings. 

The way Kubernetes provisions a service account during pod creation is a great example of how the default setting in Kubernetes could leave you exposed. By default, Kubernetes automatically provisions a service account during pod creation and mounts the account’s secret token within the pod at runtime. Many containerized applications do not require direct access to the service account. If a threat actor compromises an application, they might obtain the account token to further compromise the server. Therefore, when an application does not need to access the service account directly, administrators must ensure that the pod specifications disable the default behavior. 

You can now use the Automount Service Account Token policy criteria to find the pods that have the service account mounted. Advanced Cluster Security can now scan your environment to determine the presence of a default setting that mounts the service account’s secret token at runtime, with the option of triggering an alert and blocking the deployment. We can then instruct Kubernetes to change this default setting and stop automounting service accounts.

Log4shell policy

Using Advanced Cluster Security for Kubernetes, organizations can identify container images associated  with the widely exploited vulnerable Log4j software package to facilitate their ongoing remediation efforts in their Kubernetes environments, or monitor for newly introduced vulnerable deployments. Advanced Cluster Security for Kubernetes may be used to identify components in Java manifest files, as well as software packages from other package managers. Advanced Cluster Security for Kubernetes uses feeds from the National Vulnerability Database (NVD) and from Red Hat’s Product Security team to identify vulnerable software packages. 

Red Hat Advanced Cluster Security for Kubernetes now comes with an out of the box default policy that looks for deployments with the vulnerable software packages.

Set policy criteria based on route exposures

A frequent challenge organizations face is prioritizing issues on applications that can have an outsized impact on their security posture. An area that many focus on are those applications that are exposed to an internal or external network. By setting policies that allow users to focus on deployments with external exposures from the cluster, such as a route users can more effectively prioritize issues on assets that post a greater security risk. 

By focusing teams on the most important remediation efforts by setting policies that combine vulnerability and misconfiguration information with route exposures to better prioritize security issues.

Red Hat Package Manager Execution Policy now supports Microdnf 

We’ve continued to make our investment in detecting tools that can be used by attackers to download tools that can be used in an attack. Customers using minimal container images such as ubi-minimal can now detect software downloads using microdnf in their containers to triage if the download is legitimate troubleshooting activity or an indicator of compromise.  We’ve achieved this by adding the microdnf package manager has been added to the default Red Hat package manager policies in Red Hat Advanced Cluster Security for Kubernetes.

Operational Readiness Checks

Kubernetes was designed at heart to be a self healing system. Red Hat Advanced Cluster Security for Kubernetes was designed to take advantage of that design choice by leveraging runtime enforcement actions to scale down pods rather than killing a process so that our customers could reduce the risk of a security enforcement action causing an critical business application outage. 

Using newly designed policy criteria that check for the presence of readiness probes, liveliness probes and pod replicasets, users can ensure that their applications are operationally ready according to an enterprise standard and further enable applications to self heal from application issues and security enforcement actions.  

Learn More

To learn more about Red Hat Advanced Cluster Security, visit our product page and documentation.

To get a more personalized look at Red Hat Advanced Cluster Security for Kubernetes, you can request a demo.