Prior to this change the kata-agent was launching the guest-components programatically as child process. For CAA it is preferable to launch the processes as systemd units for improved reliability and to remove redundancy (due to the network ns requirement api-server-rest was spawned in the root ns by kata and via systemd in the podns ns by systemd)
We need to make the "update" functionality aware of the guest_components_procs agent setting, so it will be copied to the destination agent configuration file.
The attestation-agent unit is spawned after process-user-data, because it will consume the templated kata-agent config. The confidential-data-hub and api-server-rest units are activated by the presence of the unix sockets they connect to.
attestation-agent will keep defaulting to the kata agent config for the aa_kbc_params config, that's why we need to configure the agent path in the mkosi image.
The process tree on a podvm will look like this after in change:
note: at the moment the kata entry in versions.yaml is pointing at a fork, this will be toggled once the respective PR is merged
note 2: at the moment both kata-agent and attestation-agent start after the process-user-data oneshot unit, we'll have to see whether there will be race conditions with encrypted images and tweak the order of those units.
Prior to this change the kata-agent was launching the guest-components programatically as child process. For CAA it is preferable to launch the processes as systemd units for improved reliability and to remove redundancy (due to the network ns requirement api-server-rest was spawned in the root ns by kata and via systemd in the podns ns by systemd)
We need to make the "update" functionality aware of the
guest_components_procs
agent setting, so it will be copied to the destination agent configuration file.The attestation-agent unit is spawned after process-user-data, because it will consume the templated kata-agent config. The confidential-data-hub and api-server-rest units are activated by the presence of the unix sockets they connect to.
attestation-agent will keep defaulting to the kata agent config for the
aa_kbc_params
config, that's why we need to configure the agent path in the mkosi image.The process tree on a podvm will look like this after in change:
note: at the moment the kata entry in versions.yaml is pointing at a fork, this will be toggled once the respective PR is merged
note 2: at the moment both kata-agent and attestation-agent start after the process-user-data oneshot unit, we'll have to see whether there will be race conditions with encrypted images and tweak the order of those units.