작업 이미지 (evo-workspace)

웹 채팅의 workflow 작업 공간(~170)이 쓰는 이미지다. 채팅 모델과 사용자가 GitLab 프로젝트를 clone 해 이슈 등록·검증·커밋·MR 을 하는 도구만 담는다. 터미널 화면은 없다. 이 이미지를 쓰는 서비스는 workspace-runner이고, compose 배포·네트워크 격리는 workspace-deploy.md 다.

1. 들어 있는 것

이미지에는 도구 외에 workspace-runner(/usr/local/bin/workspace-runner, Go 정적 바이너리)도 들어 있다. 기본 실행은 도구 확인용이고, runner 로 쓸 때는 root 로 시작해 최소 권한(SETUID·SETGID·CHOWN)만 주어 실행한다 — workspace-runner.md.

도구	위치	비고
git	/usr/bin/git	기반 이미지(Alpine 3.22)의 패키지
glab	/usr/local/bin/glab	고정 버전의 공식 릴리스 바이너리
evo-workflow	/usr/local/bin/evo-workflow → /opt/evo/bin/evo	개발판 evo 를 evo-workflow 이름으로 실행하면 workflow 명령만 동작한다(evo-cli #487)

• evo 본체는 PATH 밖(/opt/evo/bin)에 둔다. 이름은 보안 경계가 아니다 — evo 를 직접 실행하면 전체 기능이 있다. 기능 차단은 서버 허용 목록과 컨테이너 격리로 한다.
• evo 로그인·조직 키 파일 없이 workflow 가 동작한다(빈 HOME 에서 시험). 다만 evo-cli 는 이를 지원 범위로 보장하지 않는다(조직 전용 권한이 생기면 구현 전에 알려 주기로 했다). 바뀌면 이 이미지의 시험이 먼저 실패한다.
• 없는 것: 컴파일러·make·패키지 관리자(apk)·curl·wget·nc·ssh(busybox 의 네트워크 도구 링크도 지운다). setuid·setgid 비트는 모두 제거했다. 빌드·테스트·의존성 설치는 이 이미지로 하지 않는다(1차 범위: 가벼운 작업만).
• 실행 계정은 uid 10002(workspace, root 아님). 읽기 전용 루트로 실행할 수 있다(쓰는 곳은 /work 볼륨과 /tmp). 사용자별 uid 로 바꿔 실행하는 일은 runner 가 한다.
• 환경 변수 기본값: GLAB_CHECK_UPDATE=false(업데이트 확인으로 밖에 나가지 않음), NO_PROMPT=1, GIT_TERMINAL_PROMPT=0. glab 설정 폴더·토큰은 실행 때 정한다(GLAB_CONFIG_DIR·GITLAB_TOKEN).
• git 시스템 설정(docker/workspace/gitconfig): 훅 실행 안 함(core.hooksPath=/dev/null), https 전송만 허용, 서브모듈 재귀 끔, 자격증명 저장소 끔, 받은 객체 검사(fsckObjects).
• git 자격증명 도우미 /usr/local/bin/git-askpass: git 이 https 자격증명을 물을 때 실행 환경 변수만 읽어 답한다(사용자 이름 oauth2, 비밀번호 GITLAB_TOKEN). 토큰이 없으면 빈 값을 내고, 파일·설정에서 읽지 않는다.

2. 버전 고정

• 도구 버전과 sha256 은 docker/workspace/tools.lock 이 정한다. 빌드는 내려받은 파일이 이 파일의 체크섬과 다르면 실패한다(Nexus 쪽 목록은 믿지 않는다).
• evo 는 개발판(1.0.0-dev.N)만 workflow 를 포함한다(정식 1.0.0 은 아직 없다). 정식판이 나오면 EVO_DEV_BASE_URL 대신 정식판 경로를 쓰도록 이 이미지를 고친다. evo-cli 가 workflow 전용 실행 파일(evo-workflow, 4.7MB)을 내면 교체한다 — 이미지는 ’evo-workflow 실행 파일 하나’만 가정하므로 명령 모양은 그대로다.
• glab 은 evo 설치 저장소의 deps/glab/<버전>/ 에서, evo 는 개발판 저장소 evo-cli/dev/<버전>/ 에서 받는다(Nexus raw, 익명 읽기).
• 기반 이미지는 태그(alpine:3.22)로 고정한다. Debian 12 기반은 이미지가 379MB 였고 취약점 검사에서 Debian 이 아직 고치지 않은 항목이 66건(HIGH 65·CRITICAL 1) 나와 Alpine 으로 바꿨다(163MB). evo·glab 은 정적 Go 바이너리라 libc 에 기대지 않는다. 기반 이미지가 갱신되면 같은 태그라도 내용이 바뀔 수 있으므로, 다시 빌드하면 보안 갱신이 들어온다.

갱신 절차

sh scripts/workspace/lock-tools.sh                      # 개발판 evo 최신 + glab 최신으로 tools.lock 갱신(체크섬은 Nexus 목록에서 읽음)
sh scripts/workspace/lock-tools.sh --evo 1.0.0-dev.1330 --glab 1.123.0   # 버전을 직접 정할 때
sh scripts/workspace/test-lock.sh                       # 형식 검사(도커 없이)
sh scripts/workspace/build.sh evo-workspace:local && sh scripts/workspace/test-image.sh evo-workspace:local

변경된 tools.lock 을 MR 로 올리면 CI(workspace_image_test)가 빌드·검사한다.

3. 빌드·검사

sh scripts/workspace/build.sh evo-workspace:local        # tools.lock 의 값을 build-arg 로 넘겨 빌드
sh scripts/workspace/test-image.sh evo-workspace:local   # 운영과 같은 제한(읽기 전용 루트·권한 제거·네트워크 없음)으로 15가지 검사
sh scripts/security/scan-image.sh evo-workspace:local trivy-report.txt   # 취약점(HIGH·CRITICAL) 보고서

• 검사 항목: git·glab·evo-workflow 가 고정 버전으로 동작, 로그인 없이 workflow 동작, evo 의 다른 명령(update) 거절, evo 본체가 PATH 에 없음, root 아님, 읽기 전용 루트, 컴파일러·패키지 관리자·curl·ssh 없음, setuid 없음, glab 업데이트 확인 꺼짐, git 훅 꺼짐·https 외 전송 거절, 이미지 라벨.
• 취약점 검사(scan-image.sh)는 Trivy(TRIVY_IMAGE, 기본 aquasec/trivy:0.57.1)를 쓴다. 검사기·취약점 DB 를 받을 수 없는 환경이면 보고서에 “결과 없음”을 적고 파이프라인은 실패하지 않는다. 폐쇄망은 미러 이미지와 DB 를 준비해 TRIVY_IMAGE 를 바꾼다.
• 폐쇄망 빌드는 EVO_DEV_BASE_URL·EVO_DEPS_BASE_URL(같은 폴더 모양의 미러)을 환경 변수로 준다.

4. CI 와 게시

상황	job	동작
MR(위 파일이 바뀐 경우)	workspace_image_test	빌드·검사·취약점 보고서, 게시하지 않는다
develop	dev_workspace	빌드·검사 뒤 evo-workspace:<X.Y.Z>-dev.<N> 을 Nexus 에 push(evo-api 와 같은 버전 규칙)
릴리스 태그 vX.Y.Z	release_workspace	빌드·검사 뒤 evo-workspace:<X.Y.Z> 를 Nexus 에 push(latest 태그 없음)

• 게시에는 evo-api 와 같은 CI/CD 변수(NEXUS_DOCKER_PUSH_REGISTRY, NEXUS_USER, NEXUS_PASSWORD)를 쓰고, 이미지 빌드·push job 과 같은 공통 태그 docker-build 러너에서 돈다.
• 개발서버 배포: compose 의 workspace 프로필 서비스가 이 이미지를 쓴다(, workspace-deploy.md 4절). 앱·화면 배포는 프로필 밖이라 실행기를 건드리지 않는다. 실행기 이미지 태그는 배포 env 의 EVOMIND_WORKSPACE_IMAGE 를 사람이 바꿔 다시 올린다(자동 갱신 없음).
• 같은 버전 이미지는 덮어쓰지 않는다(릴리스 불변). 릴리스 번들에는 WORKSPACE_IMAGE 를 주었을 때만 들어간다.