Red Hat OpenShift 4.18 Now Available on IBM Power Red Hat® OpenShift® 4.18 has been released and adds improvements and new capabilities to OpenShift Container Platform components. Based on Kubernetes 1.31 and CRI-O 1.31, Red Hat OpenShift 4.18 focused on core improvements with enhanced network flexibility.
The NX accelerator has random number generation capabilities.
What what happens if the random-number entropy pool runs out of numbers? If you are reading from the /dev/random device, your application will block waiting for new numbers to be generated. Alternatively the urandom device is non-blocking, and will create random numbers on the fly, re-using some of the entropy in the pool. This can lead to numbers that are less random than required for some use cases.
Well, the Power9 and Power10 servers use the nest accelerator to generate the pseudo random numbers and maintains the pool.
Each processor chip in a Power9 and Power10 server has an on-chip “nest” accelerator called the NX unit that provides specialized functions for general data compression, gzip compression, encryption, and random number generation. These accelerators are used transparently across the systems software stack to speed up operations related to Live Partition Migration, IPSec, JFS2 Encrypted File Systems, PKCS11 encryption, and random number generation through /dev/random and /dev/urandom.
Kind of cool, I’ll have to find some more details to verify it and use it.
A reference can contain a domain (quay.io) pointing to the container registry, one or more repositories (also referred to as namespaces) on the registry (fedora), and an image (fedora-bootc) followed by a tag (41) and/or digest (sha256). Note that images can be referenced by tag, digest, or both at the same time..
When you create a Pod, the API Server reconciles the resource, and the Kube Scheduler is triggered to assign it to a Node. On the Node, the Kubelet converts to the OCI specification, enriches the container with host-device specific resources, and dispatches it to cri-o. cri-o, using the default container runtime launcher – runc or crun, and using the runc/crun configuration it launches and manages the container with SystemD, and attaches an eBPF program that controls device access.
If you are seeing EPERM issues accessing a device, perhaps you don’t have the right access set at the Pod level, you may be able to use a Device Plugin.
Options for adding Devices
You have a couple of things to look at:
volumeDevices
io.kubernetes.cri-o.Devices
cri-o config drop-in
crun or runc with DeviceAllow
https://github.com/containers/crun
https://github.com/containers/crun/blob/017b5fddcb0a29938295d9a28fdc901164c77d74/contrib/seccomp-notify-plugin-rust/src/mknod.rs#L9
A custom device plugin like https://github.com/IBM/power-device-plugin
For those with OpenShift Container Platform nodes that must support FIPS, and you’ve previously generated the certificates on a non-FIPS node. You must execute these steps from a FIPS-compliant environment, such as a RHEL server booted in FIPS mode.
Custom nftable firewall rules in OpenShift: https://access.redhat.com/articles/7090422
It’s a supported method for implementing custom nftables firewall rules in OpenShift clusters. It is intended for cluster administrators who are responsible for managing network security policies within their OpenShift environments.
I’m making a mental note that this tool from @simonkrenger k8s-etcd-decryptor is a life saver – I’ve used it once during development and need to get data out of etcd.
The tool decrypts the AES-CBC-encrypted objects from etcd. Note, AES-CBC is one of two encyrption types AES-GCM, and is not covered by the tool.