Rootless Podman for attempt containers on SSH workers

Cerrado
  • ¿Algo no está bien?
#792 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Ya se ha fusionado un pull request relacionado.

  • #804 de @usine-phildl — fusionado

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
45/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
debian, docker, linux, typescript
Área
backend, devops, infrastructure

Línea de trabajo

Read docs/research/rootless-attempt-containers.md for the plan. Edit infra/hetzner/cloud-init.yaml to install Podman and remove Docker group, and update packages/executor/src/ssh for runtime choice and Podman CLI ops. Run unit tests for runtime detection with a fake shell. Done when a disposable worker passes the validation table and PR records runtime details.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Implements the recommendation of docs/research/rootless-attempt-containers.md (#728, merged as ac3ee650). Today attempts run in Docker containers on the worker and the usine SSH user is in the docker group, which is root-equivalent on the machine (#555 item 6). With rootless Podman and --userns=keep-id, containers run as the unprivileged usine user, the docker group goes away, and an attempt that escapes its container has the rights of an ordinary user.

Decision of 2026-10-30: do it, after the rest of wave 2 (#776 roles is the last large item before it). Docker stays a supported runtime during the transition; the cloud-init selects one.

Change, in the order of the research document's "Recommendation and required changes"

  1. infra/hetzner/cloud-init.yaml (and the gateway overlay): install Podman, crun, uidmap and the Debian systemd user-session pieces; allocate non-overlapping subordinate UID and GID ranges for usine; enable lingering so detached containers survive SSH disconnects; drop the Docker proxy drop-in and daemon.json on Podman workers while keeping /etc/environment, nftables, gateway DNS, the gh socket service and metadata protection; remove usine from the docker group on Podman workers.
  2. Executor (packages/executor/src/ssh): an explicit runtime choice carried through the container operations and ShellContainer.runtime, with Podman detection from its structured info (rootless, cgroup v2, delegated controllers); start, exec, inspect, restart, cancellation, OOM recording, removal and label-scoped sweeping validated against Podman's CLI output and errors, secrets kept on stdin; the pulled attempt image unchanged (--userns=keep-id keeps the image's non-root user and host-owned mounts).
  3. Preflight: fails with a remediation when cgroup delegation, subordinate ranges or lingering are missing.
  4. Docs: add-a-worker guide and infra/hetzner README describe the Podman worker and how to rebuild the snapshot; ADR amendment recording the runtime choice.

Acceptance

The research document's "Validation required for implementation" table, run on a disposable worker built from the new cloud-init: boot and non-interactive SSH, resource enforcement, OOM lifecycle, file ownership across two concurrent attempts, network and pulls (gateway routes, proxy downloads, metadata denial, cold GHCR pull, Boat tailnet path), harnesses (Claude, Codex, Pi, Chromium without privileged mode), lifetime and cleanup. Record runtime, OCI runtime, kernel, cgroup version and delegated controllers in the PR. Unit tests cover the runtime detection and the operations against a fake shell for both runtimes.

Large: cloud-init and executor can be two PRs; the worker validation is the operator's dogfood step after the executor PR merges, not a task for the factory.

Lenguaje dominante
TypeScript
Estrellas
1
Forks
0
Merge medio
3 h 44 min
PR fusionados (30 d)
378

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de basaltbytes/usine

Todos los issues de basaltbytes/usine

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.