Security
Headlines
HeadlinesLatestCVEs

Headline

Enabling Peer Pods on IBM Z and LinuxONE with Red Hat OpenShift sandboxed containers

Red Hat OpenShift sandboxed containers (OSC) version 1.5.0, introduces Peer Pods to IBM Z and LinuxONE. This update is the product of a cooperation between IBM and Red Hat, and is an important step in improving sandboxed containers, paving the way for Confidential Containers. By integrating with IBM Z and LinuxONE, OpenShift sandboxed containers help tackle the challenges of providing more secure and efficient containerized applications in complex IT infrastructures.Understanding Peer Pods in OpenShiftPeer Pods have expanded the capabilities of OpenShift, allowing for the use of Kata Container

Red Hat Blog
#mac#linux#red_hat#git#asus#ibm#ssl

Red Hat OpenShift sandboxed containers (OSC) version 1.5.0, introduces Peer Pods to IBM Z and LinuxONE. This update is the product of a cooperation between IBM and Red Hat, and is an important step in improving sandboxed containers, paving the way for Confidential Containers. By integrating with IBM Z and LinuxONE, OpenShift sandboxed containers help tackle the challenges of providing more secure and efficient containerized applications in complex IT infrastructures.

Understanding Peer Pods in OpenShift

Peer Pods have expanded the capabilities of OpenShift, allowing for the use of Kata Containers on cloud-based clusters without the need for nested virtualization. This is particularly significant as it opens up opportunities to deploy sandboxed containers in environments where nested virtual machines (VMs) are either impractical or undesirable. By leveraging the cloud-api-adaptor and its libvirt provider, Peer Pods manage Kata Containers directly, avoiding the complexities of nested VMs. This innovation enhances the flexibility and adaptability of OpenShift sandboxed containers across various cloud platforms.

Specifically, the cloud-api-adaptor utilizes cloud provider APIs to manage VM instances. In the case of IBM Z and LinuxONE, it employs the libvirt provider, which connects to a libvirt daemon instance. This approach allows for more precise control and management of VMs, aligning them more seamlessly with the needs of the containerized environment in OpenShift.

For those interested in a deeper understanding of Peer Pods, this introductory blog post provides a comprehensive look into their benefits and how they function. Additionally, the GitHub page for the cloud-api-adaptor’s libvirt provider offers valuable technical insights, making it an essential resource for anyone looking to implement this feature.

5 steps to a running Peer Pod****1. Ensure your environment meets these prerequisites

Before starting, confirm that your IBM Z and LinuxONE environment meets all the prerequisites for OpenShift sandboxed containers, which are aligned with OpenShift’s requirements.

2. Deploy the OpenShift sandbox containers Operator

Install the OSC Operator and set enablePeerPods: true when creating the KataConfig. This step activates the Peer Pods feature in your environment.

3. Configure Peer Pods

Follow the instructions in the documentation to set up Peer Pods. This involves specific configurations to ensure seamless integration with your system.

4. Create the KataConfig Custom Resource

After ensuring your prerequisites are met, create a KataConfig custom resource (CR) with the enablePeerPods: true setting. This action configures your nodes for the kata-remote RuntimeClass and triggers the necessary installations and settings adjustments by the OpenShift sandboxed containers Operator. Here’s a simple KataConfig YAML example:

apiVersion: kataconfiguration.openshift.io/v1
kind: KataConfig
metadata:
name: cluster-kataconfig
spec:
enablePeerPods: true

Apply this configuration using the OpenShift CLI (oc), and prepare for the worker nodes to reboot, which is part of the installation process. Monitor the status section in example-kataconfig until completion.

5. Run an example workload with Fedora Pod

Finally, deploy an example workload to test the Peer Pods environment. Here’s an example of a Fedora pod using the RuntimeClassName: kata-remote

apiVersion: v1
kind: Pod
metadata:
name: hello-openshift
labels:
 app: hello-openshift
spec:
runtimeClassName: kata-remote
containers:
 - name: hello-openshift
   image: quay.io/openshift/origin-hello-openshift
   ports:
     - containerPort: 8888
   securityContext:
     privileged: false
     allowPrivilegeEscalation: false
     runAsNonRoot: true
     runAsUser: 1001
     capabilities:
       drop:
         - ALL
     seccompProfile:
       type: RuntimeDefault
---
kind: Service
apiVersion: v1
metadata:
 name: hello-openshift-service
labels:
 app: hello-openshift
spec:
selector:
   app: hello-openshift
ports:
 - port: 8888

This configuration defines a Fedora pod, specifically using the kata-remote RuntimeClass to run on Peer Pods in your OpenShift environment on IBM Z and LinuxONE.

Conclusion

The technology preview of OpenShift sandboxed containers on IBM Z and LinuxONE offers a new way to run containers with improved isolation. This update marks a step forward for container environments on the platform and sets the stage for integrating Confidential Containers, enhancing isolation further based on IBM Secure Execution for Linux technology.

Deploying these containers is straightforward, requiring minimal changes from a non-peer pod deployment. Adding the runtimeClassName to the deployment spec or pod template is all it takes. This showcases Red Hat’s commitment to enabling the use of advanced container isolation and Confidential Computing with minimal changes during pod deployment.

Red Hat Blog: Latest News

Managed Identity and Workload Identity support in Azure Red Hat OpenShift