update containerd to 1.4.3, runc to 1.0.0-rc93

[bcressey]

Issue number:
Fixes #1299

Description of changes:
Update containerd to 1.4.3. The preliminary work in #1318 lets us drop our SELinux-related patches in favor of the upstream logic, though we now have a new one to fix volume mount labels. We're also able to drop the dependency on socat and remove that package now that CRI has its own port-forwarding implementation.

Note that MCS isolation is not yet enforced even though containerd 1.4 is allocating the MCS pairs. We need changes to our SELinux policy to enable this.

Update runc to 1.0.0-rc93. The /dev/mqueue issue was fixed upstream, so we no longer need our patch.

Testing done:
Launched an ECS task and verified that it ran correctly. Ran conformance tests for 1.18 on x86_64, and 1.19 on aarch64. Tests passed.

Verified that process labels for unprivileged containers launched through CRI had MCS pairs by default, and that mount labels for all containers had MCS pairs by default. Privileged containers run as control_t and unprivileged containers run as container_t.

Verified that port-forwarding worked by launching a redis pod and connecting to it with a local client. The redis test exposed the issue with volume mount labels - a SAVE command returned an error because the database could not write to the /data path. Confirmed that SAVE works correctly with the new CRI patch.

Verified that containers launched via CRI have the 65536 soft file descriptor limit by default.

Verified that runc shows the new version information.

# runc -v
runc version 1.0.0-rc93+bottlerocket
commit: 12644e614e25b05da6fd08a38ffa0cfe1903fdec
spec: 1.0.2-dev
go: go1.15.6
libseccomp: 2.5.1

Terms of contribution:

By submitting this pull request, I agree that this contribution is dual-licensed under the terms of both the Apache License, version 2.0, and the MIT license.

[webern]

nice

[samuelkarp]

Verified that process labels for unprivileged containers launched through CRI had MCS pairs by default, and that mount labels for all containers had MCS pairs by default. Privileged containers run as control_t and unprivileged containers run as container_t.

Verified that port-forwarding worked by launching a redis pod and connecting to it with a local client. The redis test exposed the issue with volume mount labels - a SAVE command returned an error because the database could not write to the /data path. Confirmed that SAVE works correctly with the new CRI patch.

Verified that containers launched via CRI have the 65536 soft file descriptor limit by default.

@bcressey Were you able to verify that these are true for containers launched via Docker as well? Testing in the aws-dev variant should be sufficient, or you could test with ECS and the aws-ecs-1 variant if you want as well.

[samuelkarp]

I'd like to see this tested with Docker as well before merge, but the code LGTM.

[bcressey]

I'd like to see this tested with Docker as well before merge, but the code LGTM.

Docker wouldn't have been affected by any of the CRI changes, so I didn't include it in the test results. I've confirmed that the results are what I expected after landing #1315 and #1318:

• privileged - process label is control_t, filesystem has MCS pair
• label disabled - process label is control_t, filesystem has MCS pair
• unprivileged - process label is container_t plus MCS pair, filesystem has MCS pair

I noted one discrepancy between Docker and CRI which is that the former will relabel volume mounts for "shared" usage, meaning the MCS pair is not used, while the latter uses the MCS pair. I have it in my list of things to sort out as part of making MCS isolation work.

Containers in Docker have the ulimits from daemon.json, currently 1024 soft and 4096 hard.

For port forwarding I wasn't quite sure what to test, but I verified that remote connectivity via redis-cli worked, and that I could save the database, when I ran docker run -it --rm -p 6379:6379 redis:latest.