OCI base-profile artifacts at ghcr.io/security-profiles/runc are amd64-only

[Ca-moes]

What happened:

Setting baseProfileName: oci://ghcr.io/security-profiles/runc:v1.3.3 (or any other published tag) on a SeccompProfile causes spod on a linux/arm64 host to fail with:

ERROR cannot pull base profile  err="read profile: open /tmp/pull-XXXXXXXXX/profile.yaml: no such file or directory"

The profile sits in Pending indefinitely; no SecurityProfileNodeStatus is created.

Inspecting the OCI manifest at any tag in this repository (verified on v1.1.4 through v1.4.0) shows it is a single-arch image manifest (not an OCI image index) with one layer titled profile-linux-amd64.yaml:

TOKEN=$(curl -sSL "https://ghcr.io/token?scope=repository:security-profiles/runc:pull&service=ghcr.io" | jq -r .token)
curl -sSL -H "Authorization: Bearer $TOKEN" \
  -H "Accept: application/vnd.oci.image.index.v1+json,application/vnd.oci.image.manifest.v1+json" \
  "https://ghcr.io/v2/security-profiles/runc/manifests/v1.4.0" \
  | jq '{mediaType, layers: [.layers[].annotations]}'

Returns:

{
  "mediaType": "application/vnd.oci.image.manifest.v1+json",
  "layers": [
    { "org.opencontainers.image.title": "profile-linux-amd64.yaml" }
  ]
}

There is no linux/arm64 (or any other non-amd64) variant published.

What you expected to happen:

spod resolves the OCI artifact for the host architecture and merges the runc default profile into the user's SeccompProfile. The profile reaches status.status: Installed. This is the documented behaviour described in installation-usage.md under "Base profile via OCI artifact".

How to reproduce it (as minimally and precisely as possible):

1. Bring up a Kubernetes cluster on a linux/arm64 node (e.g. kind v0.31.0 on an Apple Silicon Mac, or a kind cluster on an arm64 Linux runner).
2. Install cert-manager and SPO from deploy/operator.yaml.
3. Apply a SeccompProfile that references the OCI base profile:

   apiVersion: security-profiles-operator.x-k8s.io/v1beta1
   kind: SeccompProfile
   metadata:
     name: test
     namespace: default
   spec:
     baseProfileName: oci://ghcr.io/security-profiles/runc:v1.3.3
     defaultAction: SCMP_ACT_ERRNO

4. Watch the spod logs for the node:

   kubectl -n security-profiles-operator logs ds/spod -c security-profiles-operator

The error log line above appears and the profile never installs.

Anything else we need to know?:

• The resolver in internal/pkg/artifact/artifact.go (around line 356) tries profile-linux-${arch}.yaml first and then falls back to profile.yaml. Neither exists in the artifact for non-amd64 architectures, so the fallback also fails.
• The upstream e2e that exercises this path, test/tc_base_profiles_oci_test.go, currently carries //nolint:unused // test is flaky and therefore got deactivated (verified on main HEAD dbc1b7a5c). Re-enabling that test on an arm64 runner would be a natural regression target once a fix lands.
• Suggested fix: have whatever workflow publishes ghcr.io/security-profiles/runc:* push a multi-arch OCI image index, with one per-arch manifest pointing to a profile-linux-${arch}.yaml layer. Adding linux/arm64 (and ideally linux/ppc64le for parity with the rest of SPO's matrix) would unblock the OCI base-profile path on non-amd64 hosts.
• I haven't yet located the publishing workflow in the SPO repo (the matrix in .github/workflows/build.yml covers the spoc CLI, not the runc OCI artifact). Happy to send a PR once pointed at the right place.

Environment:

• Cloud provider or hardware configuration: kind v0.31.0 on Apple Silicon (M-series); also reproduced on an arm64 GitHub Actions runner.
• OS: Ubuntu 24.04 (runner) / Linux node images shipped with kind.
• Kernel: 6.x range.
• Others: SPO v0.10.0; reproduced against main HEAD dbc1b7a5c. cert-manager v1.x.

[Ca-moes]

A bit more context after digging into this:

The publishing tooling is already multi-arch-capable — spoc push accepts --platforms and matching --profiles (cmd/spoc/main.go#L177-L210, internal/pkg/cli/pusher/options.go#L60-L95). So once an arm64 SeccompProfile YAML exists, a maintainer-driven republish like:

spoc push \
  -f examples/baseprofile-runc.yaml,examples/baseprofile-runc-arm64.yaml \
  --platforms linux/amd64,linux/arm64 \
  ghcr.io/security-profiles/runc:v1.4.0

would produce the multi-arch OCI image index that internal/pkg/artifact/artifact.go's profileName(platform) (around line 356) expects on arm64 hosts. The gap is the YAML, not the tooling.

To save a review round-trip, a candidate arm64 profile is below. It's derived from the existing examples/baseprofile-runc.yaml (40 of the 41 syscalls are present on arm64; arch_prctl is x86_64-only and is the only entry dropped). All remaining syscalls are standard Linux/POSIX entries present on the arm64 generic syscall table. The empirical gold standard would be to record runc init on arm64 with spoc record the same way the amd64 list was originally produced (per commit ad6de5adc308); happy to do that and submit a real PR if it would be useful.

examples/baseprofile-runc-arm64.yaml (candidate, derived from baseprofile-runc.yaml by removing arch_prctl)

---
apiVersion: security-profiles-operator.x-k8s.io/v1beta1
kind: SeccompProfile
metadata:
  name: runc-v1.4.0-arm64
spec:
  defaultAction: SCMP_ACT_ERRNO
  architectures:
    - SCMP_ARCH_AARCH64
  syscalls:
    - action: SCMP_ACT_ALLOW
      names:
        - brk
        - capget
        - capset
        - chdir
        - close
        - close_range
        - epoll_ctl
        - epoll_pwait
        - execve
        - exit_group
        - faccessat2
        - fcntl
        - fstat
        - fstatfs
        - futex
        - getcwd
        - getdents64
        - getpid
        - getppid
        - getuid
        - mmap
        - mprotect
        - nanosleep
        - newfstatat
        - openat
        - openat2
        - prctl
        - read
        - recvfrom
        - rt_sigreturn
        - sched_yield
        - set_tid_address
        - setgid
        - setgroups
        - setuid
        - sigaltstack
        - statx
        - tgkill
        - write

For the cosign-cache side of the OCI base-profile path on any arch, see #3162. With both that fix and the multi-arch republish, test/tc_base_profiles_oci_test.go (currently nolint:unused) would no longer need the disableOciArtifactSignatureVerification: true patch and could be re-enabled on amd64 + arm64 runners.

Happy to send a PR adding examples/baseprofile-runc-arm64.yaml (and/or a docs note in installation-usage.md covering the --platforms workflow) if either is useful — let me know which path you'd prefer.

[saschagrunert]

Thanks for the detailed analysis. The derived arm64 profile should be recorded via spoc record on arm64 rather than manually trimmed. Would you like to send a PR adding the arm64 profiles and updating the publish workflow?

[Ca-moes]

Picking this up — happy to send the PR. First, a heads-up from recording the arm64 profile the way you suggested, since it turned up some things worth aligning on.

Setup: native aarch64 Linux (kernel exposes /sys/kernel/btf/vmlinux), spoc v0.10.1, runc v1.4.2, an OCI bundle from runc spec over an Alpine aarch64 rootfs.

1. sudo spoc record drops privileges to SUDO_UID, so runc run fails with rootless container requires user namespaces. Running spoc record from a real root shell keeps the child as root and it succeeds — maybe worth a doc note.
2. spoc record doesn't follow runc init into the container's namespaces. Recording as root, a 5×-merged run gives ~77 syscalls but is missing capset, capget, setuid, setgid, setgroups, mount, pivot_root, keyctl, sethostname, setsid, umount2, … — strace -f on the same runc run confirms runc really calls all of those.
3. Scope. A full spoc record of runc run captures runc's entire lifecycle (~95 syscalls via strace -f), but examples/baseprofile-runc.yaml is ~40 — as I read it, the syscalls runc init needs after seccomp() up to execve of the workload. The git history (version-name bumps, occasional hand-added syscalls like openat2/sigaltstack/statx) suggests the amd64 file is curated rather than a raw recording.

Could you point me at the exact procedure used to produce/maintain baseprofile-runc.yaml on amd64? Once I can replicate it on arm64 I'll send the profile. (If the intended answer is that the post-seccomp() runc init tail is essentially arch-agnostic — i.e. arm64 = the amd64 list minus the x86-only arch_prctl — I'm glad to go that route; I just want to match how you maintain it.)

On the publish workflow: I couldn't find an automated workflow that publishes ghcr.io/security-profiles/runc:* — the only in-repo references are the manual spoc push examples in installation-usage.md. Should this PR (a) add the arm64 SeccompProfile YAML + a docs note on the multi-arch spoc push --platforms invocation, or (b) also add a new GH Actions workflow to automate the republish? Happy either way — (b) is bigger, so I'd want your steer on where credentials for that package live.