OpenShift platform hardening: Australian Essential Eight and Information Security Manual (ISM)

This document provides a detailed analysis of Australian Information Security Manual (ISM) controls and Essential Eight strategies to mitigate risk, and how OpenShift and Red Hat Advanced Cluster Security for Kubernetes (RHACS) helps to align with these strategies and controls.

This document enables security architects, platform engineers, compliance teams, and auditors to better align Red Hat OpenShift with the Essential Eight and ISM risk management strategies, and support these teams to manage risk for container workloads.

Specifically, the document covers how OpenShift can be configured to address the following ISM controls and Essential Eight risk mitigation strategies:

  • Application control and SIEM Integration
  • Patching applications and CVE Analysis
  • CI/CD pipelines and application hardening
  • Least privilege and role-based access controls
  • Network segmentation & observability
  • Phishing-resistant, multi-factor authentication

Application control

ISM-0846 / ISM-0955 / ISM-1392 / ISM-1490 / ISM-1656 / ISM-1657 / ISM-1660 / ISM-1746

The Essential Eight requires that application control is implemented at all maturity levels. At maturity level one this is typically simply restricting the execution of executables, libraries, scripts installers and other applications to an organisation-approved set, while at higher maturity levels, rulesets are regularly validated, and allowed and blocked application control events are centrally logged.

Red Hat Advanced Cluster Security for Kubernetes (RHACS) provides a sophisticated application control mechanism that aligns closely with the requirements of the Essential Eight while preserving consistency and portability for workloads.

RHACS uses an extended Berkeley Packet Filter (eBPF) probe to detect processes running in containers on OpenShift and then allows this baseline to be locked. If a process is detected running in the container that falls outside this baseline (via the eBPF probe), the workload is terminated and recreated; immediately destroying any attacker-controlled processes, restoring the service, and reporting the application control violation through to a configured SIEM.

Figure 1.

In this screenshot from Red Hat Advanced Cluster Security for Kubernetes, the only processes permitted to run inside the container are associated with the .NET runtime. Any other process detections will result in a policy violation, followed by first-level incident response and violations being forwarded to the SIEM.

OpenShift also supports several native configurations that enable cluster-level workload control, aligning with the intent of these ISM controls without the workload fidelity that RHACS provides. These configurations control allow-listing source registries, ensuring that containers can only be deployed from trusted locations. These do not require additional operators, and are natively supported by the platform.

The OpenShift configuration options are allowedRegistries and allowedRegistriesForImport.

The difference is subtle, but important:

  • allowedRegistriesForImport limits the container image registries from which normal users may import images. It only affects the image API, for example, oc import-image and ImageStreams.
  • allowedRegistries determines how the container runtime (CRI-O) should treat individual registries when accessing images for builds and pods.

Both options need to be configured to effectively limit the registries used for a cluster. These configuration options are included in the OpenShift Compliance Operator “Essential Eight” security profiles, enabling cluster operators to scan for misconfigured clusters.

RHACS supports visualising the results of the OpenShift Compliance Operator scans and reporting these through to the SIEM. For example, the allowedRegistries and allowedRegistriesForImport configurations reported by the OpenShift Compliance Operator “Essential Eight” profile, and allows these compliance issues to be visualised across clusters. RHACS natively integrates with several SIEMs, including Splunk and AWS Security Hub, and also provides generic syslog and webhook integrations for other security platforms.

Figure 2.

This screenshot from Red Hat Advanced Cluster Security for Kubernetes (RHACS) shows the OpenShift Compliance Operator results for application control-related configuration.. The screenshot shows that the allowedRegistries and allowedRegistriesForImport configurations have not been applied, and container images can be deployed from any registry.

Patch applications

ISM-1690 / ISM-1693 / ISM-1694 / ISM-1695 / ISM-1696 / ISM-1698 / ISM-1700 / ISM-1701 / ISM-1702 / ISM-1752 / ISM-1703 / ISM-1876 / ISM-1902 / ISM-1921

The Essential Eight requires that controls to patch applications are implemented at all maturity levels. At maturity level one, patches, updates or other vendor mitigations for vulnerabilities in online services must be applied within 48 hours of release when vulnerabilities are assessed as critical by vendors or when working exploits exist. At maturity level three, a vulnerability scanner is used at least daily to identify missing patches or updates for vulnerabilities in online services.

The ISM also makes specific reference to the frequency of vulnerability scanning and patching activities. ISM-1690 requires that patches, updates or vendor mitigations for internet-facing services are applied within 48 hours if an exploit exists for a vulnerability. ISM-1698 requires that a vulnerability scanner is used at least daily to identify missing patches or updates.

Red Hat Advanced Cluster Security for Kubernetes (ACS) updates Common Exposures and Vulnerabilities (CVE) definitions every 5 minutes. Containers deployed to OpenShift are re-evaluated with the latest definitions every 4 hours. A risk mitigation strategy that Red Hat recommends is to implement ACS workflows that integrate CVE data streams with SIEMs and support SOC analysis, and block workloads with critical vulnerabilities from the OpenShift platform via admission control.

RHACS extends vulnerability scanning across language runtimes (Java, JavaScript, Python and Ruby) and application frameworks (.NET Core and ASP.NET Core). Vulnerability scanning is also supported for container images created from a number of operating systems, including Red Hat Enterprise Linux (RHEL), Amazon Linux and Debian. The complete list of supported container base images and application runtimes and frameworks supported by the Red Hat Advanced Cluster Security for Kubernetes (RHACS) vulnerability scanner is available at “docs.redhat.com”

RHACS workload vulnerabilities in the console, allowing vulnerability analysts to rapidly identify vulnerable workloads. This screenshot from Red Hat Advanced Cluster Security for Kubernetes (RHACS) shows a Debian-based container image that is vulnerable to CVE-2021-48648. RHACS shows that the vulnerability is fixable, the affected components within the container image, and when the vulnerability was first discovered within these images. Importantly, RHACS shows that the vulnerable workload is running in the ‘tailspin’ namespace of the ‘local-cluster’, allowing security teams to rapidly identify where the vulnerable code is running.

Figure 3.

Phishing-resistant, multi-factor authentication

ISM-0974 / ISM-1401 / ISM-1173 / ISM-1504 / ISM-1505 / ISM-1682 / ISM-1683 / ISM-1894 / ISM-1920

MFA fatigue and similar MFA bypass attacks have been used in several high-profile attacks over the years. Phishing-resistant MFA is designed to specifically thwart these types of attacks by using security keys to provide the additional factor required for a login. Security keys are small devices that connect to your computer or phone, allowing you to authenticate by physically touching the key or providing biometrics. Because only the user has physical access to the device and it doesn't support push notifications, it inherently mitigates many of these MFA bypass techniques.

The Essential Eight now requires phishing-resistant, multi-factor authentication at maturity levels two and three, and you can configure phishing-resistant MFA for OpenShift using the Red Hat build of Keycloak (RHBK). This is an enterprise product created from the open source Keycloak project, and is provided with every OpenShift subscription.

The Red Hat Build of Keycloak allows administrators to create a browser-based Web Authentication (WebAuthn) flow, requiring users to present security keys to log in to OpenShift. This screenshot, from the Red Hat Build of Keycloak, shows a WebAuthn-enabled authentication flow for an OpenShift cluster. This flow ensures that users authenticating to OpenShift present security keys after successfully authenticating with their user name and password, meeting the Essential Eight and ISM requirements for phishing-resistant MFA. Keycloak provides a complete audit log of successful and unsuccessful authentication attempts, which can be exported to an SIEM or similar security event logging solution.

Figure 4.

User and server application hardening

ISM-1246 / ISM-1247 / ISM-1825 / ISM-1915 / ISM-1916

The Essential Eight requires that user applications are hardened at all maturity levels. While guidance across the maturity levels focuses on desktop user applications, including web browsers, PDF software and office productivity applications, user applications running on OpenShift can also be hardened. ISM-1915 specifically requires that approved configurations for user applications are developed, implemented and maintained, and this approach ties closely to container applications.

The ISM further refines this approach with guidance for server applications, which are typically run in containers on OpenShift. ISM-1246 requires that server applications are hardened using Australian Signals Directorate (ASD) and vendor hardening guidance, and ISM-1247 requires that unneeded user accounts, components, services and functionality of server applications are disabled or removed.

Red Hat Advanced Cluster Security for Kubernetes (RHACS) provides out-of-the-box policies that support developers to harden container applications, aligning with this Essential Eight strategy. These policies can be integrated with continuous integration and continuous development (CI/CD) pipelines. If any of these policies are violated, CI/CD pipelines will fail, alerting developers to the failed security violation. Vulnerable workloads will be blocked by the RHACS Kubernetes admission controller.

Red Hat Advanced Cluster Security for Kubernetes (RHACS) provides out-of-the-box policies that help to apply user application hardening, for example:

  • Netcat in image: This policy ensures that container images must not have the ‘netcat’ binary installed. Netcat can be used by attackers to probe internal services and move laterally once initial access is gained.
  • Log4Shell Remote Code Execution vulnerability: This policy ensures that vulnerable log4j libraries are not present in Java applications. Log4Shell is a critical vulnerability that is trivial to exploit and can remotely access running Java applications.
  • Secure shell (ssh) port exposed in image: This policy verifies whether container workloads are attempting to expose secure shell (SSH) access. SSH access is typically not used for container workloads, as it has fewer audit protections than Kubernetes execution, and presents a larger attack surface.

    • Figure 5.

    This screenshot from Red Hat Advanced Cluster Security for Kubernetes (RHACS) shows a policy used to harden applications on OpenShift, identifying Secure Shell (ssh) ports exposed by container images. This policy is configured to create alerts at the ‘build’ and ‘deploy’ stages of the container application lifecycle. The policy is also set to ‘inform’ - meaning that alerts will be raised, but built processes and deployments will not fail or be blocked. This can be configured to ‘enforce’; actively failing pipelines and blocking deployment processes.

    Restrict administrative privileges

    ISM-0430 / ISM-0445 / ISM-1263 / ISM-1508 / ISM-1591 / ISM-1883

    The Essential Eight requires that administrative privileges are restricted at all maturity levels, and OpenShift provides a comprehensive role-based access control (RBAC) framework designed to enforce the principle of least privilege across hybrid cloud environments.

    OpenShift RBAC operates at two levels:.

  • Cluster roles govern platform-wide actions — managing nodes, persistent volumes, namespaces, and cluster-scoped resources. OpenShift ships with predefined cluster roles like cluster-admin, cluster-reader, and self-provisioner, and allows organisations to define custom roles.
  • Project-scoped (namespace) roles restrict what users and service accounts can do within a specific project. The built-in admin, edit, and view roles provide a graduated access model, and custom roles let teams grant fine-grained permissions (e.g., allow deploying but not modifying secrets).

    • Red Hat Advanced Cluster Security for Kubernetes (RHACS) provides visibility into user privileges across OpenShift clusters and makes it easier to determine where administrative privileges have been created. RHACS does this by providing a consolidated view of cluster-wide RBAC for OpenShift, across multiple clusters. This provides security teams and platform administrators the ability to quickly identify anomalous administrative access, and remove these permissions. This screenshot shows consolidated user accesses across OpenShift clusters displayed in the RHACS console.

    Figure 6.

    RHACS also provides out-of-the-box policies that alert workloads requesting privileged access. Privileged access on Kubernetes and OpenShift means that workloads run without SELinux confinement, can access host-level resources, and are generally restricted.

    Sample policies that align with this control are:

  • Container with privilege escalation allowed: This policy alerts if a Kubernetes deployment has containers with allowPrivilegeEscalation set to true in its security context.
  • Privileged containers with Important and Critical fixable CVEs: This policy alerts on containers running in privileged mode with fixable important or critical vulnerabilities.
  • Ensure that a user for the container has been created: This policy alerts if a container tries to run as the root user.

    • Figure 7.

    This screenshot shows a policy violation for a container workload attempting to run in privileged mode with fixable important and critical vulnerabilities.

    Figure 8.

    The detail in the violation shows that the container ‘leaderboard’ is trying to start as a privileged workload, and that there are several critical and important vulnerabilities present in the containerised application.

    Network segmentation and segregation

    ISM-0385 / ISM-0520 / ISM-1181 / ISM-1182 / ISM-1271 / ISM-1273 / ISM-1479

    The ISM notes that network segmentation and segregation is one of the most effective controls in preventing malicious actors from easily propagating throughout the network once initial access has been gained. OpenShift provides built-in capabilities supporting network segmentation and observability, aligning with the ISM controls that require network access controls implemented.

    Kubernetes network policy is the default network isolation mode in OpenShift. By default, all pods in a project are accessible from other pods and network endpoints. To isolate one or more pods in a project, NetworkPolicy objects can be created in that project to indicate the allowed incoming connections. For example, this NetworkPolicy denies all network connections by default (it matches all pods but accepts no traffic):

    kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: deny-by-default spec: podSelector: {} ingress: []

    Red Hat Advanced Cluster Security for Kubernetes (RHACS) simplifies network policy for security teams and operators, allowing teams to visualise network traffic flows and simulate network policy. This enables security teams and cluster administrators to apply fine-grained control over network access controls, and visualise and simulate changes to network access controls.

    Figure 9.

    This screenshot from Red Hat Advanced Cluster Security for Kubernetes (RHACS) shows network connections between application components and internal OpenShift services, created from live network traffic flows. This screenshot also shows that there are no network policies governing ingress or egress network traffic currently in place - all ingress and egress is permitted.

    OpenShift also supports a native egress firewall that assists cluster administrators align to ISM requirements to ‘minimise communications with other servers at both the network and file system level’, and limits the external hosts that OpenShift workloads can access.

    OpenShift egress firewalls are commonly used in the financial services industry and other data-sensitive environments. The egress firewall supports a number of network isolation scenarios, e.g;

    • A pod can only connect to internal hosts and cannot initiate connections to the public Internet.
    • A pod can only connect to the public Internet and cannot initiate connections to internal hosts that are outside the OpenShiftcluster.
    • A pod can connect to only specific external hosts.
    • A pod can connect to only specific hosts.

    Category:

    Secure

    Tags:

    security