Red Hat OpenShift 4.3 and OpenShift Container Storage 4: Key Kubernetes Enhancements Explained

This article is based on reporting originally published by Container Journal in January 2020.

Overview

Red Hat announced the general availability of Red Hat OpenShift 4.3 and Red Hat OpenShift Container Storage 4 in January 2020. Both releases reflect a strategic shift in enterprise Kubernetes adoption: as organisations move past initial deployment, the focus turns to operationalising, securing, and scaling Kubernetes clusters — particularly those running stateful, storage-dependent workloads.

OpenShift 4.3: What’s New

Kubernetes 1.16 as the Foundation

OpenShift 4.3 is based on Kubernetes 1.16, which introduced several API deprecations and stability improvements, including the promotion of Custom Resource Definitions (CRDs) and the Horizontal Pod Autoscaler to stable APIs. Upstream Kubernetes 1.16 changes form the baseline on which Red Hat’s platform additions are built.

Encryption Enhancements

A major focus of this release is data security. OpenShift 4.3 adds:

• LUKS encrypted volume support: Remote enablement of Linux Unified Key Setup (LUKS) on-disk-format encrypted volumes, allowing organisations to encrypt node storage at the block device level.
• Encryption at rest: The ability to encrypt data stored within the cluster.
• FIPS 140-2 Level 1 compliance: OpenShift 4.3 meets the encryption requirements specified in the Federal Information Processing Standard FIPS 140-2 Level 1, making it suitable for US federal agencies and regulated industries that mandate FIPS-compliant cryptographic modules.

TLS Configuration API

OpenShift 4.3 introduces a configuration API for TLS cipher suite selection. Administrators can now explicitly choose the cipher suites used by:

• The Ingress controller
• The API server
• The OAuth Operator

This capability makes it significantly easier to align cluster security configuration with existing corporate or regulatory networking standards, removing the need for workarounds or custom admission controllers to enforce cipher policies.

Additional OpenShift 4.3 Features

• Prometheus monitoring integration: Built-in support for the open-source Prometheus monitoring stack.
• Log forwarding by log type: The ability to forward logs off-cluster, filtered by log type, enabling more granular log management and routing to external SIEM or log aggregation platforms.
• Node Topology Manager: Allows the kubelet to coordinate resource assignment decisions across device plugins, helping optimise workloads that require co-located NUMA-aware resources (such as GPUs or high-performance NICs).
• Persistent volume resizing: Administrators can resize persistent volumes without recreating them, reducing disruption for stateful applications.
• Customisable OpenShift console: Teams can extend and personalise the web console to suit their workflows.

OpenShift Container Storage 4: Multi-Cloud and Operator Support

Multi-Cloud Object Gateway (NooBaa)

One of the most significant additions to OpenShift Container Storage 4 is the multi-cloud object gateway, built on technology from NooBaa, a company Red Hat acquired in 2018. The gateway allows Kubernetes clusters to access external object storage hosted on any public cloud that exposes an S3-compatible API.

This means teams can use a single, consistent interface to read and write object data across AWS S3, Google Cloud Storage, Azure Blob Storage, and on-premises S3-compatible stores — without modifying application code for each target.

Rook Operator Support

OpenShift Container Storage 4 also adds support for Rook, a CNCF project that acts as a Kubernetes Operator for storage systems. Rook automates the deployment, configuration, scaling, and recovery of storage clusters (primarily Ceph) within Kubernetes, treating storage as a first-class Kubernetes workload. This reduces the operational burden on teams managing persistent storage for containerised applications.

Hybrid Cloud Strategy and Private Cluster Networking

OpenShift 4.3 reinforces Red Hat’s hybrid cloud positioning. Organisations can deploy OpenShift clusters into pre-existing customer-managed VPN/VPC networks and subnets on:

• Amazon Web Services (AWS)
• Microsoft Azure
• Google Cloud Platform (GCP)

Alternatively, clusters can be installed with private-facing load balancer endpoints that are not publicly exposed to the internet, giving security-conscious organisations greater network isolation.

Red Hat, backed by IBM since the 2019 acquisition, is positioning OpenShift as a single control plane capable of managing Kubernetes workloads consistently across on-premises data centres and multiple public clouds — the practical definition of a hybrid cloud.

The Broader Operational Shift in Enterprise Kubernetes

Brian Gracely, then Senior Director for Product Strategy at Red Hat, articulated a clear trajectory: the early wave of Kubernetes adoption was developer-led, focused on getting containers running. The next phase — underway in 2020 — is operationalisation at scale: securing clusters, managing persistent storage, and reducing the need for Kubernetes specialists through automation and better tooling.

The features in OpenShift 4.3 and OpenShift Container Storage 4 directly address this shift. Encryption APIs, FIPS compliance, the Node Topology Manager, Rook operator support, and multi-cloud storage gateways collectively lower the operational complexity that has historically required dedicated Kubernetes platform teams.

Summary of Key Changes