feat(actor-template): per-container securityContext

[Davanum Srinivas (dims)]

Add an opt-in securityContext block on ActorTemplate.spec.containers[], plumbed through ateletpb to atelet's OCI bundle builder. Templates that omit it produce the same OCI bundle as before.

Two fields are exposed:

• capabilities.add — Linux capabilities to grant on top of the default sandbox set (CAP_AUDIT_WRITE, CAP_KILL, CAP_NET_BIND_SERVICE). Entries may be written with or without the CAP_ prefix; case is normalised; duplicates collapse against the defaults.

• runAsUser / runAsGroup — the UID and GID to start the container process as. Unset preserves atelet's existing default of root.

The motivating workload is NVIDIA OpenShell's openshell-sandbox supervisor, which needs CAP_NET_ADMIN, CAP_SETUID, CAP_SETGID to configure the actor's network and user namespaces, and a non-root start UID for the supervisor process itself. Capabilities alone are not enough — the entry point still runs as root until something drops privileges.

Test plan:

• go vet clean on touched packages
• Unit tests for resolveCapabilities: defaults, prefix normalisation, case folding, dedup, blank-entry skip
• ContainerSecurityContext DeepCopy round-trip with pointer-isolation assertions for Capabilities.Add and RunAsUser
• cmd/ateapi/internal/controlapi workflow tests pass with the new copy block in resume + suspend
• kind end-to-end with a template that opts into both fields

[a4-a4s1]

Looking at #73 alongside the production-readiness thread already on #20:

• feat(actor-template): per-container securityContext #73 (this PR): per-container securityContext — spec-default, workload author opts in.
• Support actortemplate secret env #20: per-container env/secret resolution — spec-default, workload author opts in.
• ActorTemplate: Enforce that all images must be pinned #51 (closes Prevent user from creating ActorTemplates with un-pinned images #10): image-pinning via ValidatingAdmissionPolicy — operator-owned, cluster-wide.

Two layers showing up — spec-default vs admission-policy — both with K8s precedent.

One Q for maintainers: is a convention forming for which hardening axes land at which layer, or is this contributor-discretion right now? The first axis merged tends to anchor the shape for the rest.

[🤖a4s1]

[Michael Taufen (mtaufen)]

Where does the openshell-sandbox supervisor sit in the architecture? Is it duplicating some of the jobs ateom has, or is it more like runsc or a vmm? If the latter, we have plans to support multiple sandbox technologies, maybe it fits best there? Taahir Ahmed (@ahmedtd) curious for your thoughts

[Davanum Srinivas (dims)]

Michael Taufen (@mtaufen) openshell-sandbox is an in-container supervisor that runs as PID 1 of the workload container, inside the gVisor sandbox that ateom-gvisor + runsc already set up. From my understanding, it looks like this right now:

ateom-gvisor → runsc (single gVisor sandbox kernel)
                ├── pause container        (pid ns A, mount ns A, ...)
                │   └── PID 1: /pause
                └── supervisor container   (pid ns B, mount ns B, ...)
                    └── PID 1: openshell-sandbox  ← here
                        └── PID 2: workload (e.g. python3 agent.py)

It's just a regular Linux process under runsc, not a peer of runsc or a duplicate of ateom. Its job is application-layer policy enforcement: OPA/rego rules over outbound syscalls and HTTP, Landlock filesystem allowlists, capability bounding, and drop_privileges from root to a non-root UID before execve-ing the actual workload. None of that overlaps with what ateom or runsc do.

This PR is needed because that supervisor has to start with a couple of capabilities (CAP_SETUID / CAP_SETGID for the privilege drop, etc.) and a configurable runAsUser — knobs that the driver currently can't request through ActorTemplate. The multi-sandbox-technology direction is orthogonal: openshell-sandbox would still want this same securityContext regardless of whether the underlying sandbox is runsc, Kata, or anything else.