Spire Agent doesn't support cgroupsv2 for docker workload attestor plugin

[telliere]

Client's attestation isn't a security concern but more of a practical concern since a client cannot retrieve anything from the vault (write only policies).

Still, attesting clients' workloads makes harder for a user to spoof it's client identity. In order to do that, we currently leverage spire docker plugin, which provides a good way of making sure that the workload running runs inside of one of the HPCS-provided images.

This docker plugin makes usage of cgroupsv1 /proc/PID/cgroups which provides informations about the container, etc.
This behaviour has been modified in cgroupsv2 and this file doesn't provide anymore the needed informations. This way, docker plugin's functions are broken.

see : spiffe/spire#4682
and : spiffe/spire#4251

[telliere]

Current mitigation :

UNIX plugin provides the possibility to use the SHA256 of the binary calling the workload API as a selector for SVIDs. On standard LINUX systems, it allows us to make sure that the program fetching the workload API is the binary we've put inside of the HPCS containers.

[telliere]

On Mac, docker is not natively supported, causing docker containers to run inside of a VM/microVM. This results in a replacement of those calling binaries. f.e :

time="2024-03-22T09:39:01Z" level=debug msg="PID attested to have selectors" pid=66 selectors="[type:\"unix\" value:\"uid:0\" type:\"unix\" value:\"user:root\" type:\"unix\" value:\"gid:0\" type:\"unix\" value:\"group:root\" type:\"unix\" value:\"supplementary_gid:0\" type:\"unix\" value:\"supplementary_group:root\" type:\"unix\" value:\"supplementary_gid:1\" type:\"unix\" value:\"supplementary_group:bin\" type:\"unix\" value:\"supplementary_gid:2\" type:\"unix\" value:\"supplementary_group:daemon\" type:\"unix\" value:\"supplementary_gid:3\" type:\"unix\" value:\"supplementary_group:sys\" type:\"unix\" value:\"supplementary_gid:4\" type:\"unix\" value:\"supplementary_group:adm\" type:\"unix\" value:\"supplementary_gid:6\" type:\"unix\" value:\"supplementary_group:disk\" type:\"unix\" value:\"supplementary_gid:10\" type:\"unix\" value:\"supplementary_group:wheel\" type:\"unix\" value:\"supplementary_gid:11\" type:\"unix\" value:\"supplementary_group:floppy\" type:\"unix\" value:\"supplementary_gid:20\" type:\"unix\" value:\"supplementary_group:dialout\" type:\"unix\" value:\"supplementary_gid:26\" type:\"unix\" value:\"supplementary_group:tape\" type:\"unix\" value:\"supplementary_gid:27\" type:\"unix\" value:\"supplementary_group:video\" type:\"unix\" value:\"path:/usr/bin/qemu-x86_64\" type:\"unix\" value:\"sha256:3fc6c8fbd8fe429b67276854fbb5ae594118f7f0b10352a508477833b04ee9b7\"]" subsystem_name=workload_attestor

We currently have no mitigation for that