Disk image options

vCPU type

The vCPU type specified when creating a disk image determines the type of CPU presented to the Anjuna Confidential Container at runtime. Newer CPU types support additional features, such as for performance and security; however, the host platform used to run the Anjuna Confidential Container must support the model specified, which requires the host to be the same generation or newer. The value specified affects the measurements of the Anjuna Confidential Container.

The following shows an example of specifying the CPU type to the disk create command:

$ anjuna-metal disk create hello-world.tar.gz \
    --technology=SEV-SNP \
    --docker-uri=hello-world \
    --vcpu-type=EPYC-Milan

The default value for --vcpu-type is EPYC-v4. Other valid values include:

  • EPYC-Milan

  • EPYC-Genoa

  • EPYC-Turin

The number of vCPUs to use can also be specified when creating a disk image (defaults to 4), and this value also affects the measurements of the Anjuna Confidential Container:

$ anjuna-metal disk create hello-world.tar.gz \
    --technology=SEV-SNP \
    --docker-uri=hello-world \
    --vcpu-type=EPYC-Milan \
    --vcpus=8

Using an enclave configuration file

A disk image can be created using an enclave configuration file that allows control over various aspects of the Anjuna Confidential Container, such as environment variables and additional files:

$ anjuna-metal disk create hello-world.tar.gz \
    --technology=SEV-SNP \
    --docker-uri=hello-world \
    --config=enclave-config.yaml

For more information on enclave configuration, see the SEV on CSP guide.

Using Podman

Both docker and podman are supported as container engines. You can choose to use podman by specifying the --podman-uri argument instead of --docker-uri (podman must be installed):

$ anjuna-metal disk create hello-world.tar.gz --technology=SEV-SNP --podman-uri=hello-world

Signing a Anjuna Confidential Container

AMD SEV-SNP allows the expected launch digest of a VM’s initial state to be signed with a user-supplied key. The signed expected measurements and the public part of the key are then included in the VM’s identity block, which will then be verified by the hardware when the Anjuna Confidential Container image is started.

The fingerprint of the public key, known as the Signer ID, can also be used to set up policies for retrieving secrets securely using the APM (see Attestation with the Anjuna Policy Manager).

To sign an Anjuna Confidential Container image, use the --signing-key option:

$ anjuna-metal disk create <disk-image> \
    --technology=SEV-SNP \
    --docker-uri=<docker-uri> \
    --signing-key=<file>

To generate a launch identity key that conforms with the SNP spec, use the following command:

$ openssl genpkey -algorithm ec -pkeyopt ec_paramgen_curve:"P-384" -out idkey.pem

Customizing root filesystem protection

You can choose to modify the protection level of the root partition used to run an Anjuna Confidential Container:

$ anjuna-metal disk create <disk-image> \
    --technology=SEV-SNP \
    --docker-uri=<docker-uri> \
    --rootfs-protection=encrypted-only

The available values for --rootfs-protection are:

  • full

  • encrypted-only

  • none

The default value is full, which provides tamper-proof encryption for your data. The full option requires initializing the entire disk on boot, so larger disk images will result in longer startup times. The encrypted-only option provides encryption without tamper-proofing, but may offer better startup time and write performance depending on your workload.

Avoid using none in production. Without encryption, the contents of the disk are accessible to an attacker, potentially exposing sensitive data, even when running inside an Anjuna Confidential Container.

For more information, see the Security overview of an Anjuna Confidential Container’s disk.