This is the multi-page printable view of this section.
Click here to print.
Return to the regular view of this page.
Hardware Requirements
Hardware requirements for deploying Confidential Containers
Confidential Computing is a hardware technology.
Confidential Containers supports multiple hardware platforms
and can leverage cloud hardware.
If you do not have bare metal hardware and will deploy Confidential Containers
with a cloud integration, continue to the cloud section.
You can also run Confidential Containers without hardware support
for testing or development.
The Confidential Containers operator, which is described in the following section,
does not setup the host kernel, firmware, or system configuration.
Before installing Confidential Containers on a bare metal system,
make sure that your node can start confidential VMs.
This section will describe the configuration that is required on the host.
Regardless of your platform, it is recommended to have at least 8GB of RAM and 4 cores
on your worker node.
1 - CoCo without Hardware
Testing and development without hardware
For testing or development, Confidential Containers can be deployed without
any hardware support.
This is referred to as a coco-dev or non-tee.
A coco-dev deployment functions the same way as Confidential Containers
with an enclave, but a non-confidential VM is used instead of a confidential VM.
This does not provide any security guarantees, but it can be used for testing.
No additional host configuration is required as long as the host supports virtualization.
2 - Secure Execution Host Setup
Host configurations for IBM s390x
This document outlines the steps to configure a host machine to support
IBM Secure Execution on IBM Z & LinuxONE platforms. This capability enables
enhanced security for workloads by taking advantage of protected
virtualization. Ensure the host meets the necessary hardware and software
requirements before proceeding.
Hardware Requirements
Supported hardware includes these systems:
- IBM z15 or newer models
- IBM LinuxONE III or newer models
Software Requirements
Additionally, the system must meet specific CPU and kernel configuration
requirements. Follow the steps below to verify and enable the Secure Execution
capability.
-
Verify Protected Virtualization Support in the Kernel
Run the following command to ensure the kernel supports protected virtualization:
cat /sys/firmware/uv/prot_virt_host
A value of 1 indicates support.
-
Check Ultravisor Memory Reservation
Confirm that the ultravisor has reserved memory during the current boot:
sudo dmesg | grep -i ultravisor
Example output:
[ 0.063630] prot_virt.f9efb6: Reserving 98MB as ultravisor base storage
-
Validate the Secure Execution Facility Bit
Ensure the required facility bit (158) is present:
cat /proc/cpuinfo | grep 158
The facilities field should include 158.
If any required configuration is missing, contact your cloud provider to
enable the Secure Execution capability for a machine. Alternatively, if
you have administrative privileges and the facility bit (158) is set, you can
enable it by modifying kernel parameters and rebooting the system:
-
Modify Kernel Parameters
Update the kernel configuration to include the prot_virt=1 parameter:
sudo sed -i 's/^\(parameters.*\)/\1 prot_virt=1/g' /etc/zipl.conf
-
Update the Bootloader and reboot the System
Apply the changes to the bootloader and reboot the system:
sudo zipl -V
sudo systemctl reboot
-
Repeat the Verification Steps
After rebooting, repeat the verification steps above to ensure Secure Execution is properly enabled.
Additional Notes
- The steps to enable Secure Execution might vary depending on the Linux
distributions. Consult your distribution’s documentation if necessary.
- For more detailed information about IBM Secure Execution for Linux, see also
the official documentation at IBM Secure Execution for Linux.
3 - SEV-SNP Host Setup
Host configurations for AMD SEV-SNP machines
In order to launch SNP memory encrypted guests, the host must be prepared with a compatible kernel, 6.8.0-rc5-next-20240221-snp-host-cc2568386. AMD custom changes and required components and repositories will eventually be taken upstream.
Sev-utils is an easy way to install the required host kernel, but it will unnecessarily build AMD compatible guest kernel, OVMF, and QEMU components. The additional components can be used with the script utility to test launch and attest a base QEMU SNP guest. However, for the CoCo use case, make sure to use the coco tagged version because they are already packaged and delivered with Kata.
Alternatively, refer to the AMDESE guide to manually build the host kernel and other components.
Create the Certificate-Chain
Certificate chains (cert-chain) are an essential piece for creating a secure and trusted environment, ensuring that data is processed securely and that all components involved are verified and trustworthy. Use the following commands to create a cert-chain for SNP.
git clone -b snphost-0.5.0 https://github.com/virtee/snphost.git && cd snphost/
cargo build
mkdir /tmp/certs
./target/debug/snphost fetch vcek der /tmp/certs
./target/debug/snphost import /tmp/certs /opt/snp/cert_chain.cert
Optional Edit the SNP config File
The previous section installs the cert-chain in the default path, if you would like to install the cert-chains in a custom directory, it will need to be specified in the SNP config file. But first, you will need to install the operator first before being able to edit the SNP config file. Follow these instructions to setup the operator. In order to use cert chain that was made for SNP, the Kata SNP configuration file needs to be edited first. The config file can be found under /opt/kata/share/defaults/kata-containers/configuration-qemu-snp.toml.
The location of the certificate chain needs to be specified under snp_certs_path.
snp_certs_path = "{PATH TO cert_chain.cert}"
4 - SGX Host Setup
Host configurations for Intel SGX machines
TODO
5 - TDX Host Setup
Host configurations for Intel® Trust Domain Extensions (TDX)
Additional Notes