IBM maps Crypto Express acceleration into OpenShift pods on LinuxONE

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.