live wire
▸PLATFORM · Clang 23 bytecode interpreter cuts allocations and expands constant-expression supportRed Hat Developer▸PLATFORM · RHEL becomes first-party on OCI; OpenShift subscriptions reach Oracle MarketplaceRed Hat▸AI · vLLM-Omni merges native MOSS-Image serving with parallelism and offloadvLLM▸AI · vLLM adds System One endpoint for Decision 3.0 multimodal routing models (Oct. 15)vLLM▸SECURITY · Red Hat rates OpenShift AI 3.4.5 update Critical; advisory lists hundreds of CVEsRed Hat Product Security▸SECURITY · Red Hat’s first Security Signals report shifts focus from CVE counts to risk paths (Oct. 15)Red Hat▸PLATFORM · IBM adds non-destructive FlexVolume-to-CSI migration tool for OpenShift object storageIBM Cloud▸vLLM tests agent-built Kimi K3 decode path at up to 1.9× speedup; PR remains openvLLM▸AI · LeaderWorkerSet 1.0 changes rollout defaults for disaggregated AI workloadsKubernetes SIGs▸SECURITY · Red Hat flags active exploitation of kernel flaw affecting OpenShift CoreOS; no fix listedRed Hat Product Security▸AI · Red Hat sets Dec. 9 showcase for AI 3.6 agent governance and model servicesRed Hat▸vLLM 0.32.0 drops Python 3.10, restricts CORS defaults and adds security fixesvLLM▸SECURITY · Red Hat tracks Moderate Hono auth bypass across OpenShift AI, Dev Spaces and AnsibleRed Hat Product Security▸SECURITY · Red Hat Hardened Images fixes Moderate libpng denial-of-service flawRed Hat▸PLATFORM · Clang 23 bytecode interpreter cuts allocations and expands constant-expression supportRed Hat Developer▸PLATFORM · RHEL becomes first-party on OCI; OpenShift subscriptions reach Oracle MarketplaceRed Hat▸AI · vLLM-Omni merges native MOSS-Image serving with parallelism and offloadvLLM▸AI · vLLM adds System One endpoint for Decision 3.0 multimodal routing models (Oct. 15)vLLM▸SECURITY · Red Hat rates OpenShift AI 3.4.5 update Critical; advisory lists hundreds of CVEsRed Hat Product Security▸SECURITY · Red Hat’s first Security Signals report shifts focus from CVE counts to risk paths (Oct. 15)Red Hat▸PLATFORM · IBM adds non-destructive FlexVolume-to-CSI migration tool for OpenShift object storageIBM Cloud▸vLLM tests agent-built Kimi K3 decode path at up to 1.9× speedup; PR remains openvLLM▸AI · LeaderWorkerSet 1.0 changes rollout defaults for disaggregated AI workloadsKubernetes SIGs▸SECURITY · Red Hat flags active exploitation of kernel flaw affecting OpenShift CoreOS; no fix listedRed Hat Product Security▸AI · Red Hat sets Dec. 9 showcase for AI 3.6 agent governance and model servicesRed Hat▸vLLM 0.32.0 drops Python 3.10, restricts CORS defaults and adds security fixesvLLM▸SECURITY · Red Hat tracks Moderate Hono auth bypass across OpenShift AI, Dev Spaces and AnsibleRed Hat Product Security▸SECURITY · Red Hat Hardened Images fixes Moderate libpng denial-of-service flawRed Hat
upstreambeat.ai
guidePLATFORM

IBM maps Crypto Express acceleration into OpenShift pods on LinuxONE

A concrete device-plugin pattern turns mainframe cryptographic hardware into a schedulable OpenShift resource, with explicit limits around host setup and pod privilege.

OpenShift pod requests Crypto Express hardware through a device plugin.
AI-generated diagram
By The News Desk· Oct 14, 2026the quick take — two AI hosts go live when you do

IBM has published a concrete pattern for giving Red Hat OpenShift workloads access to Crypto Express hardware on IBM LinuxONE and IBM Z. The walkthrough uses a Kubernetes device plugin to turn a configured cryptographic adapter into a resource that a pod can request, rather than leaving hardware assignment outside the cluster scheduler. IBM’s post demonstrates the path with a Java application on WebSphere Liberty.

What the device plugin controls

The cluster layer does not replace the underlying mainframe configuration. IBM says physical passthrough still has to be established through LPAR activation profiles or z/VM. After that, the plugin discovers Crypto Express adapters on worker nodes and tracks allocation of each adjunct processor queue number, or APQN, so two workloads do not claim the same hardware. A central ConfigMap groups adapter and domain pairs into named cryptoconfigsets scoped to a namespace; a pod then requests a resource such as cex.s390.ibm.com/cex-accel-test: 1. The project repository describes the plugin as providing containerized applications with access to Crypto Express cards on LinuxONE and IBM Z.

That makes the useful abstraction explicit: the hardware remains platform-specific, but its allocation becomes declarative and visible to Kubernetes scheduling. This is not a portable accelerator recipe for arbitrary OpenShift clusters; it depends on s390x systems, configured adapters and a worker selected for that hardware.

The application stack and privilege boundary

IBM’s example starts from Red Hat Universal Base Image 9 and combines IBM Semeru Runtime 25, WebSphere Liberty 26.0.0.7, SunPKCS11, opencryptoki, icatok and libica. IBM recommends leaving symmetric cryptography such as AES to the on-chip CPACF facility while directing asymmetric operations to Crypto Express, avoiding unnecessary adapter latency. The post validates the route with icastats, whose hardware counters show RSA-CRT and SHA operations without software fallback in the demonstrated run.

The security context deserves attention. IBM’s sample starts the container as user 0 because the PKCS#11 slot daemon must initialize token access, while disabling privilege escalation, dropping all default Linux capabilities and adding back only SETGID and SETUID. That is narrower than a generally privileged pod, but it is still a deployment-specific exception platform teams should review rather than copy mechanically.

What platform teams can reuse

The reusable part is the contract between infrastructure configuration, namespace-scoped resource definitions and pod scheduling. Teams can adapt that contract to containerized applications that need hardware-backed cryptographic operations, while keeping adapter ownership visible to the scheduler. The repository points to both a community image on Quay and an IBM-certified image in Red Hat’s container catalog, giving OpenShift operators a supported distribution path in addition to source and manifests.

For teams already running LinuxONE or IBM Z, the article closes an implementation gap between “hardware acceleration is available” and “this pod can request it safely.” For everyone else, it is most useful as a worked example of how a narrowly scoped Kubernetes device plugin can expose specialized infrastructure without pretending the prerequisite hardware and host configuration disappear.

sources

Filed by The News Desk. Corrections: desk@upstreambeat.ai · Our standards →

comments · 0

    Comments are moderated before they appear. Your email is used once to confirm it is you — never shown, never sold. Corrections and questions get an answer from the desk when we have one.

    more from the desk