storage: Enable confidential ephemeral volumes

[sprt]

Merge Checklist

• Followed patch format from upstream recommendation: https://github.com/kata-containers/community/blob/main/CONTRIBUTING.md#patch-format
  • Included a single commit in a given PR - at least unless there are related commits and each makes sense as a change on its own.
• Aware about the PR to be merged using "create a merge commit" rather than "squash and merge" (or similar)
• genPolicy only: Ensured the tool still builds on Windows
• The upstream/missing label (or upstream/not-needed) has been set on the PR.

Summary

Please see commit messages. Note that this approach follows the driver-shim interface design (with the new metadata driver options) that we agreed to propose upstream with Intel. When we sync our fork with upstream, the agent code will look much different, but those agent changes should be transparent to the end user.

Upstream proposal: confidential-containers/confidential-containers#247

Depends on:

• Driver changes: azure-local-csi: Enable guest encryption #231
• kata-packages-uvm-coco changes: kata-packages-uvm-coco: add e2fsprogs dependency azurelinux#9938
• kata-containers-cc update: TODO

Migration flows:

• Of course if you want confidentiality at all you'll need to upgrade to these PRs.
• If you only upgrade Kata but not your driver, the local volumes will still work, just not confidential.
• If you only upgrade your driver but not Kata, you're broken because you need the Kata bits and the driver is now hardcoded to be confidential.

Test Methodology

Local testing

[sprt]

New changes:

• Addressed PR comments.
• Deploying the luks-encrypt-storage script from upstream at runtime: upstream checks the integrity tags in a lazy way (--integrity-no-wipe), and we need to copy that as the eager version has a significant performance overhead (~100sec for a 10GB per my testing). It was much easier to call a script rather than to convert all those commands to Rust Command::new() calls.
  • This also means we are now fully aligned with upstream's encryption settings.

Next step: genpolicy changes.

[sprt]

New changes: added genpolicy support.

[Redent0r]

Looks good to me from what I understand. My only feedback (possibly for a different PR) would be how to go about testing this. Would it be roughly something like:

1. Create pod with ephemeral volume
2. Write to it
3. Content of encrypted storage should not be available from the host side
   ?