apparmor: explicitly set abi/3.0#12864
Conversation
f8faeca to
4bd0af8
Compare
This change sets the AppArmor policy used by containerd to indicate it is `abi/3.0`. This was chosen based on some code archeology which indicated that containerd 1.7 came out in March 2023, before the AppArmor 4.0 ABI. The AppArmor policies themselves date to much older; the last apparmor version-checks were removed in 4baa187 and c990e3f, and both were looking for AppArmor 2.8.96 or older, pointing to abi/3.0 being the "correct" one to pick. Nothing is preventing containerd from migrating to a newer AppArmor ABI; note, however, that anything newer than `abi/4.0` will need modifications to preserve UNIX domain sockets. This was tested by building a custom k3s v1.35.0+k3s3, with the following modification: ``` diff --git a/go.mod b/go.mod index 4e7bacd204..0fcaf76b8f 100644 --- a/go.mod +++ b/go.mod @@ -8,7 +8,7 @@ replace ( github.com/cilium/ebpf => github.com/cilium/ebpf v0.12.3 github.com/cloudnativelabs/kube-router/v2 => github.com/k3s-io/kube-router/v2 v2.6.3-k3s1 github.com/containerd/containerd/api => github.com/containerd/containerd/api v1.9.0 - github.com/containerd/containerd/v2 => github.com/k3s-io/containerd/v2 v2.1.5-k3s1 + github.com/containerd/containerd/v2 => github.com/achernya/containerd/v2 v2.0.0-20260206214308-5e0dce89c422 github.com/containerd/imgcrypt => github.com/containerd/imgcrypt v1.1.11 github.com/containerd/stargz-snapshotter => github.com/k3s-io/stargz-snapshotter v0.17.0-k3s1 github.com/docker/distribution => github.com/docker/distribution v2.8.3+incompatible ``` to use a precursor to this commit. Once built, the resulting k3s was tested on a brand-new Proxmox installation: ``` root@containerd-test:~# uname -a Linux containerd-test 6.17.2-1-pve containerd#1 SMP PREEMPT_DYNAMIC PMX 6.17.2-1 (2025-10-21T11:55Z) x86_64 GNU/Linux root@containerd-test:~# pveversion pve-manager/9.1.1/42db4a6cf33dac83 (running kernel: 6.17.2-1-pve) ``` Files were copied over: ``` achernya@achernya-dev:~/src/k3s$ scp -r dist/artifacts/ root@containerd-test: ``` and installed ``` root@containerd-test:~# mkdir -p /var/lib/rancher/k3s/agent/images/ /usr/local/bin root@containerd-test:~# cp artifacts/k3s /usr/local/bin/ root@containerd-test:~# cp artifacts/k3s-airgap-images-amd64.tar.zst /var/lib/rancher/k3s/agent/images/ ``` then finally started with `k3s server`. Argo CD was then installed: ``` root@containerd-test:~# k3s kubectl create namespace argocd namespace/argocd created root@containerd-test:~# k3s kubectl apply -n argocd --server-side --force-conflicts -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml [elided] root@containerd-test:~# k3s kubectl get pods -A NAMESPACE NAME READY STATUS RESTARTS AGE argocd argocd-application-controller-0 1/1 Running 0 31s argocd argocd-applicationset-controller-77475dfcf-6b4cb 1/1 Running 0 32s argocd argocd-dex-server-6485c5ddf5-ckp5s 1/1 Running 0 32s argocd argocd-notifications-controller-758f795776-djx69 1/1 Running 0 32s argocd argocd-redis-6cc4bb5db5-lt9fh 1/1 Running 0 32s argocd argocd-repo-server-c76cf57cd-mr4mc 1/1 Running 0 32s argocd argocd-server-6f85b59c87-w6cns 0/1 Running 0 32s kube-system coredns-6b4688786f-pnds2 1/1 Running 0 4m1s kube-system helm-install-traefik-crd-cn28g 0/1 Completed 0 4m1s kube-system helm-install-traefik-hc9gp 0/1 Completed 2 4m1s kube-system local-path-provisioner-6bc6568469-7wglx 1/1 Running 0 4m1s kube-system metrics-server-77dbbf84b-nqzsc 1/1 Running 0 4m1s kube-system svclb-traefik-fe6d3a0b-z7jsp 2/2 Running 0 3m14s kube-system traefik-5fdc878c8d-cjhx5 1/1 Running 0 3m15s ``` Fixes: containerd#12726 Signed-off-by: Alex Chernyakhovsky <[email protected]>
Head branch was pushed to by a user without write access
|
@samuelkarp or @mxpv I rebased the commits here and it turned off auto-merge, please take a look and merge when you have a chance. |
| abi <abi/3.0>, | ||
There was a problem hiding this comment.
Thanks! IIUC, we currently need to assume AppArmor 3.x because some (LTS) distros are still on this, correct? At least a quick search shows that both Debian stable (Trixie) and oldstable (Bookworm) are still on 3.x. Same for Ubuntu 22.04 (LTS).
Wondering if it would be good to add a comment in this file as a reminder why we're doing this, and when it'd be OK to update to 4.x.
There was a problem hiding this comment.
The ABI chosen is a property of the config in this file, not a desire to support LTS. If/when the file is updated to use newer rules, the ABI should.be updated.
There was a problem hiding this comment.
(You are obviously correct that if this config requests a newer ABI than the system has available, it won't work. But there's no harm in using an older ABI indefinitely)
There was a problem hiding this comment.
Oops; missed your reply; thanks for clarifying / confirming: yes I don't think there's an urgency to move to ABI 4.0 (at least not until there may be features we need of it). I was mostly contemplating if a comment would be good to have, because CI may not show failures, and there's always a risk some future visitor stumbles on the code (without checking git history), and thinking "3.0 is old; let's update!"
I opened a similar patch in the profile used by Moby (Docker Engine), which the containerd package was forked from; I added you as co-author, as you did the legwork 😃 ❤️
(still looking if we can reconcile the packages; possibly use that module in containerd)
|
/cherry-pick release/2.2 release/2.1 release/1.7 |
|
@thaJeztah: #12864 failed to apply on top of branch "release/2.2": DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
This change sets the AppArmor policy used by containerd to indicate it is
abi/3.0. This was chosen based on some code archeology which indicated that containerd 1.7 came out in March 2023, before the AppArmor 4.0 ABI. The AppArmor policies themselves date to much older; the last apparmor version-checks were removed in4baa187 and
c990e3f, and both were looking for AppArmor 2.8.96 or older, pointing to abi/3.0 being the "correct" one to pick.
Nothing is preventing containerd from migrating to a newer AppArmor ABI; note, however, that anything newer than
abi/4.0will need modifications to preserve UNIX domain sockets.This was tested by building a custom k3s v1.35.0+k3s3, with the following modification:
to use a precursor to this commit.
Once built, the resulting k3s was tested on a brand-new Proxmox installation:
Files were copied over:
and installed
then finally started with
k3s server. Argo CD was then installed:Fixes: #12726