Configure CoCo runtimes with shared_fs=none

[wainersm]

Which feature do you think can be improved?

The confidential runtime classes (qemu-coco-dev, qemu-snp, qemu-tdx, qemu-sev) are all configured with shared_fs=virtio-9p which actually represents a confidentiality flaw due the lack of a secure/trusted channels to share the host filesystem into the guest. Until we don't have a confidential mechanism to share host filesystem within the guest, it's suggested that CoCo runtimes are configure with shared_fs=none, i.e, not host sharing is allowed.

Once setting shared_fs=none, features like ConfigMap and Secrets resources will rely on files copied over the guest. We will need to test and fix any breakage with these features (as well as downward API and projected volumes).

How can it be improved?

Set shared_fs=none by default on qemu-coco-dev, qemu-snp, qemu-tdx and qemu-sev runtime configuration.toml file.

Additional Information

@fidencio actually first proposed that approach If I'm not mistaken and has already raised a PR for TDX: #9315 . From hist work we already have a list of test (so features) that break:

• k8s: guest-pull: "Test readonly volume for pods" fails #9667
• k8s: guest-pull: initContainer with shared volume fails #9668
• k8s: guest-pull: "Setting sysctl" test fail #9666
• k8s: guest-pull: Kill all processes in container test fails when pulling the image inside the guest #9664
• k8s: guest-pull: "Liveness probe" test "fails" #9665

Work breakdown

• TEEs: Use shared_fs=none for TDX #9315 (@fidencio)
• TEEs: Use shared_fs=none for AMD / SEV
• TEEs: Use shared_fs=none for non-TEE (qemu-coco-dev)
• [RFC] New tests for shared_fs=none #9652

[wainersm]

* [ ]  TEEs: Use shared_fs=none for SNP / SEV

@ryansavino @AdithyaKrishnan @fitzthum Could you own the enablement on AMD runtime classes? If this configuration change is also of your interest.

* [ ]  TEEs: Use shared_fs=none for non-TEE (qemu-coco-dev)

I'll be working on ^^^^