Interesting! It seems reasonable, but this is definitely a deep-in-the-machine change. I'm tagging @cilium/sig-datapath for review, since they know the kernel implications of the RuntimeDefault seccomp profile better than I.

Also, FYI, you need one more automatic update -- see the failed CI job for details.

As far as I understand the "GitHub Workflow Related Checks" issue is fixed by #39398 .

/test

I clicked the "Update with rebase" button and triggered the tests. Let's see the results.

/test

I Just rebased to see if that fixes the test ci

@Sindvero were you able to triage the results? I'd like to make sure if possible we are looking at the results to see whether there are existing issues filed for them or if they are new to this PR. Otherwise we can end up trapped in a cycle of rebase/retrigger.

/test

@Sindvero were you able to triage the results? I'd like to make sure if possible we are looking at the results to see whether there are existing issues filed for them or if they are new to this PR. Otherwise we can end up trapped in a cycle of rebase/retrigger.

I didn't check the test.

Looks like it passed the tests it wasn't passing previously. Thanks

My biggest concern is that the default containerd seccomp profile somehow blocks a syscall we rely on. I ultimately think this is unlikely; it is configured to reject disallowed syscalls with a non-zero errno. Unless there is some seriously yolo code in Cilium, we should be noticing if a given syscall fails.

So this is probably safe to merge, especially since it would have lots of time to "soak" in CI.

We had a discussion about this during the Cilium community meeting. Some notes:

• One of the concerns was that Cilium is not the same as most apps, so the syscalls that Cilium makes may differ from what the default profile may allow. This could represent some risk for Cilium being able to do what it needs to do. We can not directly influence the seccomp profile in use here (other than to revert back to unconfined).
• The general sense that "if you can lock something down, you should" is a reasonable approach, though it does not take into account the threat model. (Not discussed, but the implication of this point is that this may not represent a real improvement to security)
• There was a question about whether the CI test environments would highlight issues relating to the seccomp profile, and how those failures may bubble up so that we ensure we see any breakage this might introduce.
• I got the sense that those present were open to rolling this out in an upcoming release and adjust the approach (opt-in vs opt-out for instance) based on the feedback we get from testing and users.

/ci-gke versions=all channel=stable

/ci-gke versions=all

/ci-gke channel=extended

/ci-gke versions=all channel=extended