Skip to content

Adding netns to jailer #305

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Merged
merged 1 commit into from
Nov 18, 2019
Merged

Conversation

xibz
Copy link
Contributor

@xibz xibz commented Oct 25, 2019

This adds netns specification per create vm request. In the event that
no netns was found in the runc config, we will then make sure of what
was passed into the create vm request

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

@xibz xibz changed the title Jailer netns clean Adding netns to jailer Oct 25, 2019
@xibz xibz force-pushed the jailer-netns-clean branch from 6810029 to a7af606 Compare October 25, 2019 03:58
Copy link
Contributor

@sipsma sipsma left a comment

Choose a reason for hiding this comment

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

Something we need to think about: right now this doesn't really work with the CNI support. When the CNI support was originally added to the Go SDK, it was written such that:

  1. If a CNI network interface was provided for the VM, the netns specified in the machine.JailerConfig would be used unless one wasn't specified, in which case a new one would be created.
  2. When starting a VM, if there was no machine.JailerConfig but a netns was specified (i.e. you are using a CNI interface but w/out JailerConfig being specified) then we just directly start the machine in the netns.

However, I just realized that the jailer support in firecracker-containerd actually doesn't use the machine.JailerCfg field in the go sdk, it uses its own JailerConfig that doesn't get translated to the go sdk's JailerCfg. So right now I think weird things happen if you use a CNI interface w/ a firecracker-containerd JailerConfig netns specified in CreateVM:

  • The netns specified in the CreateVM call will be set in the runc config, but the go sdk code will not know about that, so then a new netns will be created due to 1. above and then runc itself will be started inside that new netns due to 2. above.
  • But then runc is going to start the actual Firecracker process inside the separate netns specified as part of CreateVM, which is not where CNI interfaces were actually created, so the VM won't see any of them.

There are probably multiple ways to address this, not sure yet which one is best:

  1. Is it possible to have firecracker-containerd actually set the netns field in the go sdk's machine.JailerConfig when it was set in the CreateVM's JailerConfig?
  2. If the above isn't possible, could we change the Go SDK to move the existing machine.JailerConfig.NetNS field to just be directly in the machine object? Then we can conditionally set that field in firecracker-containerd w/out creating a whole machine.JailerConfig object.

Let me know what you think.

@xibz xibz force-pushed the jailer-netns-clean branch from a7af606 to 56ed692 Compare October 26, 2019 01:11
@xibz
Copy link
Contributor Author

xibz commented Oct 26, 2019

If the above isn't possible, could we change the Go SDK to move the existing machine.JailerConfig.NetNS field to just be directly in the machine object? Then we can conditionally set that field in firecracker-containerd w/out creating a whole machine.JailerConfig object.

I think what I can do is modify the SDK code to create a netns handler by passing in the netns path. This will use a default netns in the default handlers, then during jailing it'll create and swap handlers with its netns. Then in the firecracker-containerd code I just need to inject the correct handlers.

@xibz
Copy link
Contributor Author

xibz commented Nov 4, 2019

Waiting on firecracker-microvm/firecracker-go-sdk#155 to be merged

Copy link
Contributor

@sipsma sipsma left a comment

Choose a reason for hiding this comment

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

Can we also update one of the tests in cni_integ_test.go to use a runc jailer config? Just to make sure it interacts with the network namespacing as expected

@xibz xibz force-pushed the jailer-netns-clean branch 4 times, most recently from bebea92 to 6e4ccce Compare November 9, 2019 00:21
@xibz xibz requested review from sipsma and nmeyerhans November 12, 2019 19:46
@xibz xibz force-pushed the jailer-netns-clean branch 2 times, most recently from 0e6cbbf to b825062 Compare November 14, 2019 18:52
go.sum Outdated
Comment on lines 62 to 63
github.com/firecracker-microvm/firecracker-go-sdk v0.17.1-0.20191029213755-dbf9a1e05f09 h1:JDfRpK+V2J1Es+Xm6aMJjCqvA4xv1kuWnJfeSopyDwo=
github.com/firecracker-microvm/firecracker-go-sdk v0.17.1-0.20191029213755-dbf9a1e05f09/go.mod h1:tVXziw7GjioCKVjI5/agymYxUaqJM6q7cp9e6kwjo8Q=
Copy link
Contributor

Choose a reason for hiding this comment

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

go mod tidy may remove the lines.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good catch! Fixed

@xibz xibz force-pushed the jailer-netns-clean branch from b825062 to 0337126 Compare November 14, 2019 19:12
}
func (j *runcJailer) overwriteConfig(cfg *Config, machineConfig *firecracker.Config, socketPath, configPath string) error {
var err error
j.once.Do(func() {
Copy link
Contributor

Choose a reason for hiding this comment

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

What is the purpose of the once here? The all operations inside the closure look have no side-effects.

Copy link
Contributor Author

@xibz xibz Nov 14, 2019

Choose a reason for hiding this comment

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

caches the config so multiple reads on the file do not occur.

Added some docs to clarify the intention

Copy link
Contributor

@kzys kzys Nov 14, 2019

Choose a reason for hiding this comment

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

But the function is only called by BuildJailedMachine() -> BuildJailedRootHandler() (this one cloud be private) -> overwriteConfig(). The cache won't be invalidated, even confgPath is different.

Can we remove this one for now? I don't think this file read would be a hot spot.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Was worried about the file system call, but if you think it isn't going to be a hot spot I can remove it.

@xibz xibz force-pushed the jailer-netns-clean branch 2 times, most recently from 2fe34e8 to 3381183 Compare November 14, 2019 19:21
@xibz xibz force-pushed the jailer-netns-clean branch from 3381183 to 9a9c431 Compare November 14, 2019 19:29
@xibz xibz force-pushed the jailer-netns-clean branch 2 times, most recently from 8d3c678 to e18daaa Compare November 14, 2019 21:14
func (j *runcJailer) overwriteConfig(cfg *Config, machineConfig *firecracker.Config, socketPath, configPath string) error {
var err error
// here we attempt to cache the runc config. If the config has already been
// cached, we will return immediately
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this comment still relevant? Otherwise LGTM

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good catch, fixed!

@xibz xibz force-pushed the jailer-netns-clean branch from e18daaa to 23204f6 Compare November 14, 2019 23:26

if err = json.Unmarshal(configBytes, &spec); err != nil {
return nil, errors.Wrapf(err, "failed to unmarshal firecracker-runc-config.json")
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Please use runcConfigPath instead of hard-coding firecracker-runc-config.json here

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed

Copy link
Contributor

Choose a reason for hiding this comment

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

You don't have to use Sprintf inside Wrapf :)

@xibz xibz force-pushed the jailer-netns-clean branch from 23204f6 to 8903ba8 Compare November 15, 2019 00:11

if err = json.Unmarshal(configBytes, &spec); err != nil {
return nil, errors.Wrapf(err, "failed to unmarshal firecracker-runc-config.json")
}
Copy link
Contributor

Choose a reason for hiding this comment

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

You don't have to use Sprintf inside Wrapf :)

@xibz xibz force-pushed the jailer-netns-clean branch from 8903ba8 to cc43916 Compare November 15, 2019 20:29
@xibz
Copy link
Contributor Author

xibz commented Nov 15, 2019

You don't have to use Sprintf inside Wrapf :)

lol, fixed!

@xibz xibz force-pushed the jailer-netns-clean branch from cc43916 to 5dc0b68 Compare November 18, 2019 19:03
@xibz xibz force-pushed the jailer-netns-clean branch from 5dc0b68 to 0100a64 Compare November 18, 2019 19:25
This change allows for users to pass in a custom network namespace in
the create vm request. This will then pass that netns to the SDK which
will run the VM in that netns.

Signed-off-by: xibz <impactbchang@gmail.com>
@xibz xibz force-pushed the jailer-netns-clean branch from 0100a64 to e1c305d Compare November 18, 2019 19:33
@xibz xibz merged commit 52dc331 into firecracker-microvm:master Nov 18, 2019
@xibz xibz deleted the jailer-netns-clean branch November 18, 2019 19:46
@xibz xibz mentioned this pull request Dec 10, 2019
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants