Identifying the software in an AMD SEV Confidential VM

The Anjuna Confidential Container leverages the following technologies to implement a secure process that ensures that secrets are automatically and safely delivered to AMD SEV Confidential VM enclaves:

  • Measured boot using a Trusted Platform Module (TPM).

  • AMD SEV, which isolates applications and data from insiders and other threats, even those that gain root or administrative access.

Using those capabilities, the Anjuna Confidential Container allows:

  • Measuring the software associated with an AMD SEV Confidential VM when building a disk image.

  • Automatically generating a signed attestation report when the AMD SEV Confidential VM boots.

  • Verifying the attestation report in the Anjuna Policy Manager.

  • Verifying that the Anjuna Confidential Container is running in an SEV enclave.

  • Securely delivering secrets to the Anjuna Confidential Container if it has been authorized to access those secrets.

In this section, you will learn how the Anjuna Confidential Container uses software measurements to perform this secure process.

Identifying the software

The software is uniquely identified by a set of hashes that represent various parts of the system. Those hashes are:

  • computed when the disk images are created

  • used to create access policies that grant access to specific enclaves in the Anjuna Policy Manager (APM)

  • used to create a signed attestation report in the AMD SEV Confidential VM enclave (using the TPM device assigned to the enclave), which will then be verified and matched against access policies by the APM

The enclave software measurement

The Anjuna Confidential Container measures every file included in an Azure custom VM image, which is then used to create an Azure Confidential VM. The software measurements (named Platform Configuration Registers or PCRs, following the TPM conventions) are:

  • PCR4: Boot loader

  • PCR5: GUID Partition Table (GPT): see Wikipedia: GUID Partition Table for more information

  • PCR9: the kernel command line, the kernel image, and the Anjuna Confidential Container binaries

  • PCR15: the application running in the enclave

    • the Docker image (including every file contained in the Docker image)

    • the enclave configuration file, which contains configuration data on how to run the application stored in the Docker image:

      • ENTRYPOINT of the Docker image,

      • environment variables,

      • the working directory,

      • the Linux username or user ID for running the application,

      • the APM configuration (optional)

From the PCR values listed above, the Anjuna Confidential Container creates a final measurement named ENCLAVE ID, which represents the unique identity of an enclave. The ENCLAVE ID can be used to create a policy in the APM that grants access to a specific secret.

The PCR4 and PCR9 values are stable for a specific release of the Anjuna Confidential Container. The PCR5 value is a random value (GUID) generated every time a disk image is created. The PCR15 value changes every time the container image, the enclave configuration file, or the root filesystem changes. The root filesystem can change if you change files with your application and reboot the VM.

The enclave signature

The Anjuna CLI supports signing disk images, which is very useful for organizations that have disk images that change often. Disk image changes are caused by updates to the application or to the Anjuna Confidential Container binaries. When a disk image changes, the measurements also change, which requires updating the access policies (i.e., the new enclave must be granted access to the same secrets).

The Anjuna CLI disk create command accepts an optional --signing-key argument, which is used to sign the software measurements of the disk image (PCR4/PCR5/PCR9/PCR15).

You can configure the APM to grant access to enclaves based on the signing key, regardless of the software measurements. This feature removes the need to repeatedly update the APM policies every time the software changes, assuming that you use the same private key to sign the disk images.

PCR16 contains the measurement of the public key associated with the signing key. The APM can create policies that will grant access to specific secrets if the enclave’s signature matches the expected signing key.

High level workflow

This section describes the steps to follow in order to enable this transparent attestation process. The following diagram describes the important phases of this process:

Anjuna Confidential Container Attestation Flow

Build phase

Step 1: Build the disk image

During this phase, you use the Anjuna CLI to create a disk image that contains the following:

  • The Anjuna Confidential Container binaries (this is done automatically)

  • The enclave configuration file, which includes the URL for the APM to be used by the enclave to perform the attestation process

  • The container image of your choice

Step 2: Upload the disk image

After the raw disk image is created, upload it to your cloud provider, which will use it to create an AMD SEV Confidential VM that will run your application container.

Step 3: Update the Anjuna Policy Manager policies

Using the measurements produced during Step 1, create policies that grant your enclaves access to the secrets that are needed. You can use a combination of ENCLAVE ID and PCR16 (signing key) to create those policies.

Runtime phase

After completing the steps in the Build phase, you are ready to create the AMD SEV Confidential VM and run your application.

Create the AMD SEV Confidential VM instance for your application

Using the Anjuna CLI, you can create an AMD SEV Confidential VM based on the disk image created during Step 1: Build the disk image. You can specify parameters for the instance like vCPUs, memory, disk size, deployment region, and zone.

Automatic attestation inside the enclave

The Anjuna Confidential Container performs the enclave’s boot sequence, which is:

  • Start the Linux kernel,

  • Perform the attestation process with the APM and retrieve any secrets required by your application,

  • Prepare a sandbox for your application to run,

  • Copy the secrets into the sandbox, and

  • Start your application in the sandbox.