Add mesh VPN support to the CDH

[portersrc]

RFC issue is here

This PR holds the main guest functionality for overlay network support with Nebula. The main additions are in confidential-data-hub/overlay-network.

Related PRs:

• trustee plugin and nebula support Add nebula_ca plugin trustee#539
• additional trustee support Update trustee to support nebula VPN feature trustee#814
• integration testing [Draft] tests/coco: Add e2e testing for nebula vpn kata-containers/kata-containers#11379

Additional support:

• possible kata agent support (no PR opened for this yet) (passes the pod name to the CDH when initializing the VPN)

[fitzthum]

A few comments on the first half of the PR

[portersrc]

Do we want a compile-time feature flag for the overlay-network AND a CdhConfig setting to enable it? We should definitely have the config setting. I'm wondering if the compile-time feature confuses the matter (though it has its merits).

[fitzthum]

Do we want a compile-time feature flag for the overlay-network AND a CdhConfig setting to enable it? We should definitely have the config setting. I'm wondering if the compile-time feature confuses the matter (though it has its merits).

We probably should have a feature so the code can be completely removed for trypophobes (or people who just want a really small guest tcb).

[cclaudio]

If you have this as pub overlay_network: Some(OverlayNetworkConfig) and the OverlayNetworkConfig struct as below, I think you would not need the enable flag as rust would require nebula to be defined at compilation time. Later, if someone adds support for another overlay network we could have them under cargo feature flags.

pub struct OverlayNetworkConfig {
    pub nebula: NebulaConfig,
}

With this I think you should be able to clean up multiple other places in this PR. E.g. you may not need the validate function and the overlay_network cargo feature flag.

[cclaudio]

I don't know if CDH is multi-threaded or if we will have support for multiple nebula VPNs, but if so it might be better to use tempdir_in

[portersrc]

maybe we handle this if/when we try to tackle multi-VPN?

[cclaudio]

IP and pod-name are required, but it also have some nice optional fields. I would be great if we can support them as well
https://github.com/confidential-containers/trustee/blob/main/kbs/src/plugins/implementations/nebula_ca.rs#L55

[cclaudio]

That makes me thinkg if we should add the nebula version somewhere to be able to check for compatibility in the future

[portersrc]

I remember you added these fields. I'm seeing:

    /// Optional: how long the cert should be valid for.
    /// The default is 1 second before the signing cert expires.
    /// Valid time units are seconds: "s", minutes: "m", hours: "h".
    duration: Option<String>,
    /// Optional: comma separated list of groups.
    groups: Option<String>,
    /// Optional: comma separated list of ipv4 address and network in CIDR notation.
    /// Subnets this cert can serve for
    subnets: Option<String>,

I'm wondering now if duration should even be something that the worker node requests. Should it instead be set up on the trustee side? For groups and subnets, I'm tempted to punt to a future PR. For example, I'm not clear on the constraints for the subnets option (and I haven't tested either of these features yet).

[portersrc]

That makes me think if we should add the nebula version somewhere to be able to check for compatibility in the future

I also wonder if nebula does this as part of its own protocol.

[fitzthum]

I think we probably want to enable this entirely via the cdh config / init-data rather than through the kata agent. You may still want to get the pod name from the agent, though.

[portersrc]

What is the thing that should actually kick the initialization of the overlay network now, though? The CDH is a driver that registers services to listen for requests. For example, it might receive a request to pull an image. Or, in the case of the overlay network, it would receive a request from the kata-agent to start. If kata-agent isn't doing that, what should? In other words, after we register the service here, who actually makes this API call?