-
Notifications
You must be signed in to change notification settings - Fork 94
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
podvm: launch guest-components as systemd units #1858
podvm: launch guest-components as systemd units #1858
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally looks good, just a couple of questions.
src/cloud-api-adaptor/podvm/files/etc/systemd/system/confidential-data-hub.service
Show resolved
Hide resolved
423c30e
to
17a11d6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Thanks!
src/cloud-api-adaptor/podvm/files/etc/systemd/system/confidential-data-hub.service
Show resolved
Hide resolved
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. Signed-off-by: Magnus Kulke <magnuskulke@microsoft.com>
17a11d6
to
3a92eff
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
Thanks @mkulke
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.