Provisioning MariaDB Password on Azure DCXas_v5 VM
This tutorial guides you through provisioning a MariaDB container on a confidential buckypaper VM in Azure. The steps can be easily adapted for any cloud service provider that supports buckypaper.
Confidential computing revolutionizes workload security by assigning unique identities to workloads running in enclaves. With Nitride, this concept extends to workload identity management. Instead of traditional user authentication, a Buckypaper VM performs attestation—similar to user authentication but for workloads—to verify its authorization with Nitride, the workload identity provider. This ensures secure access to the Vault key management service. In Nitride, policies govern workload identity verification and define access privileges, enhancing security and control in confidential environments.
The Buckypaper secret engine in vHSM is enabled by default on vault.enclaive.cloud. You can use this vHSM to generate, store, and manage cryptographic keys seamlessly. For more information see, Registering a buckypaper plugin in a vHSM if you are using your own instance.
Prerequisites
Create a Buckypaper VM with Azure DCXas_v5 VM as the cloud service provider
Installed Docker in the Buckypaper VM
Install vHSM CLl in the Buckypaper VM
To generate a dynamic secret for MariaDB, log in to vault.enclaive.cloud or a vHSM server with buckypaper plugin enabled and then authenticate using your credentials.
Install vHSM on your local computer if you are using your own instance of vHSM for attestation.
To attest and provision MariaDB password on Azure DCXas_v5 Virtual Machine:
Create and verify the attestation
Perform these steps in the Buckypaper Virtual Machine to create attestation and obtain the login token.
Create a
attestation.jsonfile with the following content as vHSM-Nitride admin or user.
Create a attestation workload for the provider
azure-sev-snp-vtpmusing:vhsm nitride attestation create @attestation.json.
The output is similar to:
Verify that attestation was successful for the provider using:
vhsm nitride attestation -provider=azure-sev-snp-vtpm report <workload-uuid>
The output is similar to:
Troubleshooting
Error message:
"failed attestation: azure-sev-snp-vtpm: measurement did not match, found: d0a83c906e0713081ac5212b4232f91ad551e394bd5f89b08ca5f9bb31b3de6bd5dbb6ae3f4ec796c87152731d43fd11, expected: ffd92c5d5207afadf3b93be300060a98f9b96bd2a1300c97f1042f2b5f313b964ffc3c14645a7b706c5f6fe5ccfa51d7"
When you enable remote attestation using the vhsm nitride init command. It creates essential Nitride identities, including: platform, firmware, and workload
The measurement in the default identities would not match the measurement on the Buckypaper VM. Hence, the attestation fails.
Solution:
Update the measurement of the identity with the measurement that the error message reads. In this example, you need to update the identity named azure-dc2asv.
Generate a dynamic secret for MariaDB
Perform these steps in a terminal of the local computer where you have set the VAULT_ADDR='https://vault.enclaive.cloud/'.
Generate a dynamic secret :
vhsm read buckypaper/data/workload/env/MARIADB_PASSWORD dynamic=true
Start a MariaDB container
Start a docker container running MariaDB by passing the secret.
Verify that the password is set.
Example Output:
You have successfully attested a Virtual Machine and generated a MariaDB password using the Buckypaper secrets engine.
Last updated
Was this helpful?