IBM Cloud Docs
Confidential computing with LinuxONE

Confidential computing with LinuxONE

Confidential computing is enabled on LinuxONE (s390x processor architecture) by using the IBM Secure Execution for Linux technology. This technology is part of the hardware of IBM z15, z16 (z15, z16) and IBM LinuxONE III generation systems. With IBM Secure Execution for Linux, you can securely deploy workloads in the cloud. It helps ensure the integrity and confidentiality of boot images, and server authenticity. Applications are isolated from the operating system, thus providing more privacy and security for the workload.

By using IBM Secure Execution for Linux, you can create encrypted Linux images that can run on a public, private, or hybrid cloud with their in-use memory protected. The workload or data is protected from external and insider threats.

A new operating system that uses the IBM Secure Execution for Linux technology is now available as IBM Hyper Protect. The associated image that is used to create the instance is called the IBM Hyper Protect Container Runtime (HPCR) image. A virtual server instance that's provisioned by using this image is called as an IBM Cloud Hyper Protect Virtual Servers for VPC (Virtual Private Cloud) instance.

For a technical deep dive into the IBM Hyper Protect Platform, see the white paper The Second Generation of IBM Hyper Protect Platform.

Check out the tutorial and the video on Confidential Computing for a financial transaction by using Hyper Protect Virtual Server for VPC. You can learn about how to protect Personally Identifiable Information and credit card information that is entered into web forms by using Confidential Computing on Hyper Protect Virtual Server for VPC.

For the on-prem version of Hyper Protect Virtual Servers, see IBM Hyper Protect Virtual Servers v2.1.

Hyper Protect Virtual Servers for VPC

The Hyper Protect Virtual Servers for VPC takes advantage of the IBM Secure Execution for Linux to provide a boundary around each instance and provides the following benefits:

  • Select Availability

    Instance profiles for the Hyper Protect Virtual Server instances are available in the US South (Dallas), US East (Washington, DC), Canada (Toronto), Brazil (São Paulo), United Kingdom (London), Germany (Frankfurt), Spain (Madrid), and Japan (Tokyo) regions.

  • Secure Execution boundary for protection from internal and external threats

    Hyper Protect Virtual Servers for VPC provides technical assurance that unauthorized users, including IBM Cloud admins, do not have access to the application. Workloads are locked down by individual, instance-level secure boundaries.

  • Multiparty contract and attestation of deployment

    Apply zero trust principles from workload development through deployment. As multiple personas and legal entities collaborate, it’s essential to separate duty and access. Hyper Protect Virtual Servers for VPC is based on a newly introduced encrypted contract concept. It enables each persona to provide its contribution and be ensured through encryption that none of the other personas can access this data or intellectual property. The deployment can be validated by an auditor persona through an attestation record, which is signed and encrypted to ensure that only the auditor has this level of insight.

  • Malware protections

    Hyper Protect Virtual Servers for VPC uses Secure Build to set up a verification process to ensure that only authorized code is running in an application. It deploys only container versions that are validated at deployment through explicit digest or are signed and may be pulled from a private Container Registry with authentication only.

  • Bring your own OCI image and use managed Container Runtime service

    Use any open-container initiative (OCI) image and gain the benefits of a confidential computing solution for extra levels of protection. Ensure through a signed contract, that only a given combination of your workload and environment is deployed.

  • Built on the Virtual Private Cloud (VPC) infrastructure for extra network security

    Choose from various profile sizes and grow as needed to protect containerized applications and pay-as-you-go on an hourly basis.

    Leverage your existing or common network security groups and logging infrastructure.

Complete the following steps to get started with Hyper Protect Virtual Servers for VPC. Most importantly, a valid contract is required for creating an instance.

Before you begin

It's important to read the following information and complete the required preparations before you create a Hyper Protect Virtual Servers for VPC instance.

  • Planning

    Consider aspects including profiles and operating system images. To create a Hyper Protect Virtual Servers for VPC instance with a stock image, choose the IBM Hyper Protect Container Runtime image.

  • Choose to build your own image with Hyper Protect Virtual Servers

    Apart from using the stock image, you can choose to securely build your own image with Hyper Protect Virtual Servers and use that image to provision a Hyper Protect Virtual Servers for VPC instance. For more information, see Hyper Protect Secure Build.

  • Prepare a contract

    When you create an instance, you must pass a valid contract in the User Data field. The IBM Hyper Protect Container Runtime image consists of different components or services that decrypts the contract (if it's encrypted), validates the contract schema, checks for contract signature, creates the passphrase to encrypt the disk device, and brings up the container that's specified in the contract.

    If no contract is passed, the instance eventually shuts down.

  • Set up logging

    To launch a Hyper Protect Virtual Servers for VPC instance, you need to set up logging first by adding the logging configuration in the contract. After deployment, you can use two types of logging to view the Hyper Protect Virtual Servers for VPC instance logs.

    • Logging service that you set up

      See Logging for Hyper Protect Virtual Servers for VPC.

      If logging isn't configured successfully, the instance shuts down automatically.

    • Serial console

      After you select the operating system and proceed with the deployment, you can view the status of the deployment and also view the logs on the serial console to confirm whether the instance is a Hyper Protect Virtual Servers for VPC instance. You can also use the information from this log to troubleshoot provisioning issues. For more information, see Accessing virtual server instances by using VNC or serial consoles.

  • Data volume

    Currently, the instance supports only one data volume that is encrypted by default with the seed or passphrase that you provide, which helps ensure that your workload data is protected. Even though you can add multiple data volumes, they're ignored and only one of them is encrypted. It's recommended that you attach one data volume to the instance during instance creation so that data from the container is stored in the data volume. It's also recommended that you take a snapshot of the data volume so that you can revert to it in case you face any issues in the future.

    Starting from the HPCR image version ibm-hyper-protect-container-runtime-1-0-s390x-9, for new Hyper Protect Virtual Servers for VPC instances, the data volume is partitioned into two parts. The first partition (100Mib) is reserved for internal metadata; the second partition remains as the data volume for workload. Only new volumes are partitioned, and you can't use the partitioned volume with an older version of the HPCR image. Provisioning with an existing encrypted volume also works. The difference is that the existing volume does not get partitioned, and you can also go back to an older image with this volume.

    When you create a Hyper Protect Virtual Servers for VPC instance with an attached data volume, detaching that data volume causes the workload running on the instance to fail. It's recommended that you do not detach the data volume.

  • Security group for ports

    The ports that are associated with the container or workload must be explicitly opened up through security groups for them to be accessible. Therefore, you must create a security group based on the ports that are associated with the container and attach it to the corresponding VPC that's used with the Hyper Protect Virtual Servers for VPC instance.

Creating a Hyper Protect Virtual Servers for VPC instance

After you finish planning and have the contract ready, you can create a Hyper Protect Virtual Servers for VPC instance.

See the troubleshooting documentation or get support if you have any problems with the instance.

You can use Terraform to automate operations with Hyper Protect Virtual Servers for VPC.

You can use your Hyper Protect Virtual Servers for VPC instance in private-only network configurations, in which the VPC doesn't have a public gateway, and the virtual server instance doesn't have a floating IP. You can connect to private endpoints of other services, including Container Registry and IBM Log Analysis. The prerequisite is to have a DNS server attached to your virtual server instance. You don't need to do any additional configurations.

Recovering or upgrading a Hyper Protect Virtual Servers for VPC instance by using IBM Cloud VPC Snapshots.

If your Hyper Protect Virtual Servers for VPC fails for any reason, you can create a new instance and attach the data volume that was attached to the failed instance (within 15 minutes of creating the new instance). Ensure that you use the same contract that was used originally to create the instance.

Alternatively, create a snapshot of the data volume that was attached to the failed instance. Then create a new instance. When you attach the data volume, choose restoring a volume from a snapshot and select the snapshot that you took earlier to restore the volume from. Ensure that you use the same contract that was used originally to create the instance.

When you want to use a new Hyper Protect Container Runtime image whenever IBM makes it available, you can follow either of the procedures that are mentioned that uses snapshots. You must use the same contract that you used for creating the original instance.