🇰🇷 한글 설명
Beta9의 빌드 워커는 테넌트 이미지 정의의 셸 명령을 Buildah RUN 라인으로 실행하면서 BUILDAH_ISOLATION=chroot 설정으로 인해 파일시스템 루트만 변경하고 PID, 네트워크, IPC, 사용자 네임스페이스를 공유합니다. 이로 인해 테넌트가 root 권한과 CAP_DAC_OVERRIDE를 가진 워커 컨테이너의 파일시스템(runc, buildah, runsc 바이너리, 서비스 계정 토큰, 호스트 마운트)에 쓰기 접근할 수 있습니다. 워커 0.1.756에서 Buildah RUN 단계에 OCI 격리와 독립된 PID, IPC, 네트워크 네임스페이스를 적용하여 수정되었습니다.
💡 쉬운 설명
고객이 올린 이미지 빌드 과정의 명령이 서버의 핵심 실행 환경을 건드릴 수 있는 문제입니다. 일반 사용자 권한만으로도 서버 내부를 장악할 수 있어 매우 위험합니다.
🇺🇸 원문 (English)
Beta9 turns each shell command in a tenant image definition into a Dockerfile RUN line and executes it with Buildah on the build worker. The worker image sets BUILDAH_ISOLATION=chroot, and no buildah invocation passes --isolation, so the step only changes its filesystem root. It keeps the worker pod's PID, network, IPC, and user namespaces, runs as uid 0, and holds CAP_DAC_OVERRIDE. PID 1 in that procfs is the worker entrypoint, so /proc/1/root is the worker container's filesystem and is writable. That filesystem contains the runc, buildah, and runsc binaries the worker uses to start tenant containers, the worker's Kubernetes service account token, and the host directories mounted into the pod. Worker pods are privileged. Clip v2 layered builds are the default, so a tenant with a workspace token reaches this by submitting one image build. The read-only proof confirmed the shared namespaces, CAP_DAC_OVERRIDE, and that the worker's runc binary is visible at /proc/1/root. Fixed in worker 0.1.756: Buildah RUN steps, including the WORKDIR mkdir, use OCI isolation with private PID, IPC, and network namespaces, and tenant ARG values are passed only into the build container.
📍 영향받는 시스템
Beta9 워커 0.1.756 이전 버전 (Clip v2 기본 빌드 사용 환경)
⚔️ 공격 벡터
워크스페이스 토큰을 가진 테넌트가 악성 셸 명령이 포함된 이미지 빌드를 한 번 제출하여 워커 파일시스템에 접근하고 권한을 상승시킴
🛡️ 대응 방법
Beta9 워커를 0.1.756 이상으로 업데이트하고 빌드 워커의 네임스페이스 격리 설정을 확인
🔧 검증 코드
출력된 버전이 0.1.756 이상이면 수정된 상태이며, 결과가 없거나 그보다 낮은 버전이면 즉시 업데이트가 필요합니다.
docker inspect $(docker ps -q --filter name=beta9-worker) --format '{{.Config.Image}}' 2>/dev/null | grep -oE '0\.1\.[0-9]+'