Confidential Computing
Confidential Computing is a technology which allows protection of data in use by using hardware-based Trusted Execution Environment (TEE), the type of environments that provide increased level of security for data integrity, data confidentiality, and code integrity.
1. Confidential Computing with Uyuni
The trustworthiness of the TEE is checked with the attestation process. Uyuni can be used as an attestation server for the systems registered to it. It generates a report page for the systems which run in this mode. These systems need to be attested and checked on regular base. The history of the past checks is also stored and available per request.
Confidential Computing Attestation depends on the used hardware and environment where the attested systems are running on.
|
Confidential Computing Attestation is only available when Uyuni is running on x86-64 architecture. |
2. Requirements
Confidential Computing can be set up in an environment with the following characteristics:
-
Attested system (virtual machine) is bootstrapped to Uyuni and runs on one of the following systems:
-
SUSE Linux Enterprise 15 SP6
-
SUSE Linux Enterprise 15 SP7
-
SUSE Linux Enterprise 16
-
openSUSE Leap 15 SP6
-
openSUSE Leap 15 SP7
-
openSUSE Leap 16
-
-
Hardware must have one of the following CPUs:
-
AMD EPYC Milan -
AMD EPYC Genoa -
AMD EPYC Bergamo -
AMD EPYC Siena -
AMD EPYC Turin -
IBM z16 -
IBM z17
-
-
BIOS must be configured to allow Confidential Computing attestation
-
Host OS and the virtualization software (KVM and libvirt) must support Confidential Computing
-
For information about required URLs when performing confidential computing attestation for IBM, see see Required URLs.
3. Limitations
Secure boot is attested.
However, currently KVM secure boot and AMD attestation tool snpguest are not working together.
4. Use Confidential Computing in Uyuni
|
For the exact steps for setting up and configuring Confidential Computing on your host, refer to the OS Vendor documentation. |
-
The attestation container is enabled during the installation of Uyuni with
mgradm install. -
Add the following to file
mgradm.yaml.coco: replicas: 1
-
To enable the attestation container after the installation, use the command line parameter
mgradm. -
Run the command
mgradm scale uyuni-server-attestation --replicas 1
-
To disable the already enabled attestation container, run the command:
mgradm scale uyuni-server-attestation --replicas 0
-
For the selected system, go to tab .
-
Enable the attestation by selecting the toggle button.
-
In the field
Environment Typeselect the correct option from the drop-down list. -
If the field
Environment Typeis set to one of theIBM z-seriesCPU values, two more settings are required,Host Key DocumentandSecure Execution Header.Host Key Documentis a public key certificate of the IBM hypervisor server instance where the attested system is going to run.Secure Execution Headeris a binary file needed to build the IBM secure VM image of the attested system.Both files should be requested by the administrator creating the attested system VM running on the IBM hypervisor.
Host Key DocumentandSecure Execution Headerare not security sensitive, therefore it is safe to store them on the Uyuni server. -
Click button Save to save the changes.
-
For the selected system, go to tab .
-
Click Schedule Attestation. The new form opens.
-
In the field
Earliestselect the time of running the attestation. -
If needed, add the newly created attestation to the action chain by selecting
Add tooption. -
Click button Schedule to save and schedule the new attestation execution.
-
For the selected system, go to tab .
-
Find and select the report you want to view.
-
After clicking the selected attestation report tab
Overviewwill open.-
If the selected CPU is
AMDyou will be shown additional tabsSEV-SNPandSecure boot. -
If the selected CPU is
IBMyou will be shown additional tabIBM SELPVATTEST.
-
-
From the navigation bar, select .
-
The list of all attestations will be shown in the main panel.
-
Find and select the report you want to view.
4.1. Report Statuses
Attestation reports can have one of the following statuses:
- Pending
-
This is the default status of the scheduled attestation. The report is still not available, either because the process has not yet started or completed.
- Successful
-
When the scheduled attestation creates a report which can be viewed, the status of the process is
Successful. - Failed
-
When the scheduled fails and does not create a report as a result, the status of the process is
Failed.
5. Related Topics
For more information about Confidential Computing, see here.