Skip to content
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

Conversation

mkulke
Copy link
Collaborator

@mkulke mkulke commented Jun 11, 2024

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:

$ pstree
systemd-+-agent-protocol----6*[{agent-protocol-}]
        |-api-server-rest---2*[{api-server-rest}]
        |-attestation-age---2*[{attestation-age}]
        |-confidential-da---2*[{confidential-da}]
        |-dbus-broker-lau---dbus-broker
        |-kata-agent-+-nginx---2*[nginx]
        |            |-pause
        |            `-5*[{kata-agent}]
        |-2*[login---bash]
        |-opa---6*[{opa}]
        |-sshd---sshd---sshd---bash---pstree
        |-systemd---(sd-pam)
        |-systemd-homed
        |-systemd-journal
        |-systemd-logind
        |-systemd-network
        |-systemd-oomd
        |-systemd-resolve
        |-systemd-udevd
        `-systemd-userdbd---3*[systemd-userwor]

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.

@mkulke mkulke added the test_e2e_libvirt Run Libvirt e2e tests label Jun 11, 2024
Copy link
Member

@stevenhorsman stevenhorsman left a 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.

@mkulke mkulke force-pushed the mkulke/start-guest-components-via-systemd branch 3 times, most recently from 423c30e to 17a11d6 Compare June 11, 2024 13:55
@mkulke mkulke requested a review from stevenhorsman June 11, 2024 13:55
Copy link
Member

@stevenhorsman stevenhorsman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Thanks!

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>
@mkulke mkulke force-pushed the mkulke/start-guest-components-via-systemd branch from 17a11d6 to 3a92eff Compare June 11, 2024 17:01
Copy link
Member

@bpradipt bpradipt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm
Thanks @mkulke

@mkulke mkulke merged commit 9267faf into confidential-containers:main Jun 11, 2024
27 checks passed
@mkulke mkulke deleted the mkulke/start-guest-components-via-systemd branch June 11, 2024 18:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
test_e2e_libvirt Run Libvirt e2e tests
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants