Issue BB: [Preview] 프리뷰 컨테이너 사용자 코드 실행 격리 — 워크스페이스 소유자를 node 로 통일 (설계 확정, 미구현)

[Danto7632]

인계 문서입니다. 설계는 실측으로 확정됐고 구현만 남았습니다. 처음 열었을 때 적었던 방법은 틀린 것으로 판명나 아래에서 대체했습니다(경위는 첫 코멘트).

🔥 Issue 개요

프리뷰 컨테이너는 사용자가 연결한 저장소를 실제로 빌드해 돌립니다. npm install 의 postinstall 스크립트와 빌드 스크립트는 저장소가 정하는 코드이고, 지금 그것이 컨테이너 안에서 root(uid 0)로 실행됩니다.

cap-drop ALL + no-new-privileges 라 컨테이너 탈출로 바로 이어지지는 않습니다. 지금 안전한 진짜 이유는 바인드 마운트가 없기 때문인데, 나중에 누가 마운트를 하나 붙이는 순간 root 라는 사실이 갑자기 중요해집니다. 그때 기억나지 않을 종류의 전제입니다.

급하지 않습니다. 실제로 위험했던 경로(컨테이너 → 호스트의 Qeploy API)는 PR #333 에서 닫았습니다. 이건 심층 방어입니다.

🔒 확정된 제약 — 이것이 설계를 결정합니다

cap-drop ALL 이 DAC_OVERRIDE 를 뗍니다. 그래서 이 컨테이너의 root 는 파일 권한을 우회하지 못합니다.

$ docker exec <preview> grep CapEff /proc/self/status
CapEff:	00000000000000c1        # CHOWN(0) + SETGID(6) + SETUID(7) 뿐. DAC_OVERRIDE(1) 없음

$ docker exec <preview> sh -c 'chown -R node:node /workspace; echo x > /workspace/app/by-root.txt'
sh: can't create /workspace/app/by-root.txt: Permission denied      # exit=1

# 비교 — DAC_OVERRIDE 를 주면 된다
$ docker run --cap-drop ALL --cap-add DAC_OVERRIDE ... 'chown -R 1000:1000 /workspace; echo y > /workspace/app/x'
exit=0

결론: 워크스페이스는 주인이 하나여야 합니다. 중간에 node 로 넘기면 그 뒤의 root 명령(git push·diff·씨딩)이 전부 막힙니다. 절반만 옮기는 설계는 없습니다 — 그렇게 시도했다가 되돌린 것이 첫 코멘트에 있습니다.

✅ 목표 상태는 동작합니다 (실측)

적대적 postinstall 을 심어 확인했습니다.

확인	결과
저장소 코드의 uid	1000 (root 아님)
/etc/shadow 읽기	거부
/etc · /usr/local/bin 쓰기	거부
apk add	거부
워크스페이스 쓰기	허용 (필요)
빌드 산출물 생성	정상

git config --global · credential.helper · git init/commit · 실제 clone · npm install 전부 node 로 됩니다(git 을 root 로 미리 깔아 둔 상태에서).

처음 측정에서 이것들이 실패해 권한 문제로 읽을 뻔했는데, git 이 안 깔려 있어서였습니다. 설치 후 다시 재면 전부 통과합니다.

🎯 설계 — 이 순서로 하는 것이 중요합니다

1단계. 프리뷰 컨테이너와 빌드 컨테이너를 분리한다 (이것부터)

지금 createAndStartContainer 와 exec 를 둘이 함께 씁니다.

preview/PreviewSessionService           프리뷰
preview/ProjectPreviewService           프리뷰
provisioning/NativeBuildService         빌드 (Gradle)
provisioning/DockerImageBuildService    빌드 (이미지)
provisioning/WebImageBuildService       빌드
provisioning/FrontendStaticHostingAdapter

분리하지 않고 기본 사용자를 뒤집으면 배포 파이프라인까지 영향을 받습니다. 분리해 두면 빌드 경로는 한 줄도 안 바뀌므로 재검증할 것이 없어집니다 — 이 작업에서 위험을 가장 크게 줄이는 한 걸음입니다.

2단계. 프리뷰 컨테이너의 워크스페이스를 처음부터 node 소유로 만든다

컨테이너 생성 시 root 가 mkdir -p /workspace/app && chown -R node:node /workspace. 중간에 넘기지 않습니다.

node 는 node:20-alpine 에 이미 있는 uid 1000 이라 전용 이미지가 필요 없습니다. (/ 가 root 소유라 node 스스로는 /workspace 를 못 만듭니다 — 그래서 root 가 만들어 넘깁니다.)

3단계. exec 기본 사용자를 node 로 뒤집고, root 가 필요한 것만 표시한다

방향이 중요합니다. 워크스페이스를 만지는 곳을 하나씩 찾아 node 로 바꾸면 40곳을 훑어야 하고, 하나 빠뜨리면 그 경로만 조용히 깨집니다. 반대로 기본을 뒤집으면 root 가 필요한 목록이 짧습니다.

• apk add ... (4곳)
• nginx 기동·종료 (PreviewRuntimeLauncher, FrontendStaticHostingAdapter)
• 컨테이너 생성 시 mkdir + chown

HOME=/home/node 를 함께 주세요. 없으면 npm 캐시와 git config --global 이 root 홈을 쓰려다 죽습니다.

4단계. (별건) egress 허용목록

이 저장소에 이미 답이 있습니다 — 코딩 에이전트가 internal 네트워크 + tinyproxy CONNECT 허용목록으로 돕니다(CodingAgentProperties.Egress). 같은 방식을 프리뷰에 적용하면 되지만 허용목록이 넓어야 하고(npm·yarn·pnpm·bun 레지스트리, GitHub, Maven Central, Gradle 배포처) 빌드를 깨뜨릴 위험이 실질적이라, 3단계와 분리해서 실제 프로젝트로 태워 보며 하는 편이 낫습니다.

⚠️ 함정 — 실측으로 확인한 것들

컨테이너는 재사용됩니다. /tmp/qeploy-build.log 가 이전 실행에서 root 소유로 남아 있으면 node 의 tee 가 거기서 죽습니다. 빌드가 아니라 로깅 때문에 실패하고, 원인은 로그에 안 남습니다.

정리 전 tee → exit=1
정리 후 tee → exit=0

빌드가 git 자격증명을 물려받지 않게 됩니다. git config --global 로 설정한 credential.helper 는 root 의 것이라, 빌드를 node 로 돌리면 저장소의 빌드 스크립트가 우리 GitHub 자격증명에 닿지 못합니다. 보안상 이득이지만 private git 의존성을 쓰는 프로젝트는 설치가 깨질 수 있습니다 — 그런 사례가 나오면 자격증명을 어느 사용자에 둘지 따로 정해야 합니다.

JAVA_FULLSTACK 경로가 가장 덜 검증된 곳입니다. PreviewRuntimeLauncher 가 프리뷰 컨테이너 안에서 nginx·openjdk 를 돌리는데, 여기는 제가 재보지 못했습니다. nginx 는 root 로 두면 되지만(워크스페이스를 읽기만 하므로), 실제로 그런지는 돌려 봐야 합니다.

📋 이미 되어 있는 것 (다시 하지 마세요)

항목	상태
cap-drop ALL + no-new-privileges	적용
메모리·swap·CPU·PID 상한	적용
컨테이너 간 통신 차단(enable_icc=false)	적용
게시 포트 루프백 전용	적용
docker socket · 바인드 마운트	없음
exec 타임아웃 10분	적용
MySQL 루프백 바인딩	적용
Qeploy API 루프백 바인딩	적용 (PR #333)

✅ 완료 기준

• 프리뷰 컨테이너와 빌드 컨테이너가 분리되어, 빌드 경로가 이 변경의 영향을 받지 않는다
• 저장소의 코드(npm install postinstall·빌드 스크립트)가 uid 0 이 아닌 사용자로 실행된다
• 워크스페이스의 소유자가 하나다(권한 충돌 없음)
• apk add·nginx 등 플랫폼 명령이 그대로 동작한다
• JAVA_FULLSTACK 프리뷰가 정상 동작한다
• (별건) 프리뷰 egress 가 허용목록으로 좁혀진다

📎 참고

• DockerContainerService.createAndStartContainer · exec · execWithExitCode
• CodingAgentProperties.Egress — 이미 동작하는 egress 허용목록 구현
• PR [Security] 프리뷰 컨테이너→API 경로 차단 · 쓰기 토큰 수명 단축 · 소유권 회귀 가드 [ #332 ] #333 — 호스트 도달 경로 차단, state.md §4.25

[Danto7632]

착수했다가 되돌렸습니다 — 설계 전제가 틀렸습니다

구현해 보고 실측하니 이 이슈가 적어 둔 방법("root 로 워크스페이스를 만들어 넘기고 이후 exec 를 --user node 로")이 성립하지 않습니다. 부분 적용은 지금보다 나쁘고, 전체 적용은 제가 검증할 수 없는 경로까지 건드립니다. 코드는 되돌렸고, 알아낸 것을 남깁니다.

핵심 발견 — cap-drop ALL 이 DAC_OVERRIDE 를 뗀다

프리뷰 컨테이너의 root 는 파일 권한을 우회하지 못합니다.

$ docker exec <preview> grep CapEff /proc/self/status
CapEff:	00000000000000c1        # CHOWN(0) + SETGID(6) + SETUID(7) 뿐. DAC_OVERRIDE(1) 없음

그래서 워크스페이스를 node 에게 넘기면 이후 root 명령이 전부 막힙니다.

$ docker exec <preview> sh -c 'chown -R node:node /workspace; echo x > /workspace/app/by-root.txt'
sh: can't create /workspace/app/by-root.txt: Permission denied     # exit=1

# 비교 — DAC_OVERRIDE 를 준 컨테이너에서는 된다
$ docker run --cap-drop ALL --cap-add DAC_OVERRIDE ... 'chown -R 1000:1000 /workspace; echo y > /workspace/app/by-root.txt'
exit=0

이슈 본문의 "쓰기 주체를 섞으면 안 된다" 는 맞았지만, 이유가 예상과 달랐습니다. root 소유 파일을 node 가 못 쓰는 것이 아니라 — 그건 우회 가능합니다(node 소유 디렉터리에서는 지우고 다시 만들 수 있음) — node 소유 트리에 root 가 못 쓰는 것이 문제입니다. 방향이 예상과 반대입니다.

결론: 워크스페이스는 주인이 하나여야 합니다. 절반만 옮기는 설계는 없습니다.

목표 상태는 동작합니다 (실측)

git 을 먼저 깔아 두면 node 로 전 과정이 됩니다. 처음 측정에서 git 이 없어 실패한 것을 권한 문제로 읽을 뻔했는데, 설치 후 다시 재니 전부 통과했습니다.

git config --global          OK
credential.helper 설정       OK   (/tmp/.git-credentials 는 node 도 쓸 수 있다)
git init + commit            OK
실제 clone (github.com)      OK
npm install                  OK

격리도 확인했습니다. 적대적 postinstall 을 심어 npm install 을 돌린 결과:

uid=1000                     저장소 코드가 root 가 아닌 uid 로 실행됨
/etc/shadow 읽기             거부
/etc 쓰기                    거부
/usr/local/bin 쓰기          거부
apk add                      거부
워크스페이스 쓰기            허용 (필요하다)
빌드 산출물 생성             정상

즉 목표는 옳고 도달 가능합니다. 가는 길이 이 이슈가 적은 것보다 넓을 뿐입니다.

왜 제가 끝내지 않았나

createAndStartContainer 와 exec 를 프리뷰 컨테이너와 빌드 컨테이너가 함께 씁니다.

preview/.../PreviewSessionService        createAndStartContainer
preview/.../ProjectPreviewService        createAndStartContainer
provisioning/.../NativeBuildService      createAndStartContainer   ← Gradle 빌드
provisioning/.../DockerImageBuildService createAndStartContainer   ← 이미지 빌드
provisioning/.../WebImageBuildService    createAndStartContainer
provisioning/.../FrontendStaticHostingAdapter

기본 사용자를 뒤집으면 AWS·EC2 가 필요해 제가 돌려볼 수 없는 배포 경로까지 영향을 받습니다. 검증하지 못한 채로 배포 파이프라인을 건드리는 것보다, 지금 상태(컨테이너 안 root, 다만 cap-drop ALL·no-new-privileges·마운트 없음)로 두는 편이 낫다고 판단했습니다.

다음 사람을 위한 설계

1. 워크스페이스를 만들 때부터 node 소유로. 중간에 넘기지 않는다 — 넘기는 순간 그 앞뒤가 갈린다.
2. exec 기본 사용자를 node 로 뒤집고, root 가 필요한 것만 표시한다. 목록이 짧다:
   • apk add ... (4곳)
   • nginx 기동·종료 (PreviewRuntimeLauncher, FrontendStaticHostingAdapter)
   • 컨테이너 생성 시 mkdir + chown
     반대로 하면(워크스페이스를 만지는 곳을 하나씩 찾아 node 로) 40곳을 훑어야 하고, 하나 빠뜨리면 그 경로만 조용히 깨진다.
3. HOME=/home/node 를 함께 준다. 없으면 npm 캐시와 git config --global 이 root 홈을 쓰려다 죽는다.
4. 프리뷰 컨테이너와 빌드 컨테이너를 구분한다. createAndStartContainer 에 인자를 두든 메서드를 나누든, 빌드 컨테이너는 지금 동작을 유지한 채로 프리뷰만 옮길 수 있어야 한다. 이것이 이 작업의 실질적인 첫 단계다.
5. 컨테이너 재사용을 잊지 말 것. /tmp/qeploy-build.log 가 이전 실행에서 root 소유로 남아 있으면 node 의 tee 가 거기서 죽는다 — 빌드가 아니라 로깅 때문에 실패하고, 원인은 로그에 안 남는다. 실측으로 확인했다(정리 전 exit=1, 정리 후 exit=0).

부수 효과 하나 — 나쁘지 않은 쪽

빌드를 node 로 돌리면 git config --global 로 설정한 credential.helper 를 빌드가 물려받지 않습니다. 저장소의 빌드 스크립트가 우리 GitHub 자격증명에 닿지 못하게 되는 것이라 보안상 이득입니다. 다만 private git 의존성을 쓰는 프로젝트는 설치가 깨질 수 있으니, 그런 사례가 나오면 자격증명을 어느 사용자에 둘지 따로 정해야 합니다.

egress 제한은 그대로 남습니다

이번에 건드리지 않았습니다. 코딩 에이전트가 쓰는 방식(internal 네트워크 + tinyproxy 허용목록)을 적용하면 되지만, 허용목록이 넓어 실제 프로젝트로 태워 보기 전에는 빌드를 깨뜨릴 위험이 있습니다.

[Danto7632]

@dldnsgkr 프리뷰 런타임 쪽이라 넘깁니다. 본문을 확정된 설계로 다시 썼습니다 — 처음 열었을 때 적었던 방법은 제가 구현해 보고 틀린 것으로 확인해 대체했습니다(경위는 위 코멘트).

넘기는 이유: 위험한 부분(PreviewRuntimeLauncher·PreviewWorkspaceService의 사용자 전환)이 전부 그쪽 영역이고, 특히 JAVA_FULLSTACK 경로는 제가 재보지 못한 유일한 곳입니다. 제가 1단계(컨테이너 분리)만 먼저 하는 것도 검토했는데, 그 추상은 2단계를 하는 사람이 고르는 게 맞고 제가 createAndStartContainer 를 선점하면 충돌만 만듭니다.

비싼 부분은 끝나 있습니다. cap-drop ALL 이 DAC_OVERRIDE 를 뗀다는 것과, 그래서 워크스페이스 주인이 하나여야 한다는 결론이 본문에 실측과 함께 있습니다. 순서(빌드 컨테이너 분리 → 워크스페이스를 처음부터 node → exec 기본 뒤집기)도 그대로 따라가면 됩니다.

급하지 않습니다. 실제로 위험했던 컨테이너→호스트 API 경로는 #333 에서 닫았고, 이건 심층 방어입니다. #318 이 우선이면 그쪽 먼저 하셔도 됩니다.