보안 및 강화

신원 및 신뢰 경계

LabPod는 각 플랫폼 계정을 호스트의 Linux 계정에 매핑합니다. 루트리스 Podman은 모든 워크스페이스를 소유자의 Linux 사용자로 실행합니다. root로도, 공유 서비스 계정으로도 실행하지 않습니다.

관리자가 할 수 있는 것과 할 수 없는 것:

관리자가 할 수 있는 것	관리자가 할 수 없는 것
모든 워크스페이스 및 리소스 사용량 조회	다른 사용자의 터미널 세션 접속
다른 사용자의 워크스페이스 강제 중지	다른 사용자의 워크스페이스 시작, 수정, 삭제 또는 접속
사용자 생성 및 삭제	LabPod를 통해 다른 사용자의 파일 접근

관리자 경계는 의도적입니다. 강제 중지는 컨테이너와 예약된 리소스를 회수하며, 그보다 깊은 작업에는 직접 호스트 접근이 필요합니다.

root는 워크스페이스를 소유할 수 없습니다. 워크스페이스 컨테이너는 비root Linux 사용자로 실행되어야 하므로 root 계정은 자체 워크스페이스를 생성하거나 시작할 수 없습니다.

컨테이너 강화

LabPod가 실행하는 모든 워크스페이스 컨테이너에는 다음 플래그가 포함됩니다:

플래그	역할
`--userns=keep-id`	호스트 UID = 컨테이너 UID, 파일이 자연스러운 소유권을 가집니다
`--cap-drop=ALL`	모든 Linux 기능 드롭
`--security-opt no-new-privileges`	setuid 권한 상승 방지
`--init`	좀비 프로세스 정리를 위해 `catatonit`을 PID 1로 실행
`--shm-size <half-of-memory>`	PyTorch DataLoader가 64 MB 기본값에 도달하는 것을 방지
`127.0.0.1:<port>` 바인드	워크스페이스 포트는 루프백에만 바인드되어 직접 노출되지 않습니다

워크스페이스 트래픽은 전달 전에 세션 쿠키 인증을 적용하는 LabPod 리버스 프록시를 통과합니다. 템플릿 런처는 /ws/<id>/<launcher>/, 사용자 선언 포트는 /ws/<id>/_user/<name>/ 경로를 사용합니다. 네임스페이스가 분리되어 런처와 사용자 포트의 이름이 같아도 됩니다.

워크스페이스 게이트웨이는 웹 앱의 서비스 워커 범위도 해당 앱 URL 아래로 제한합니다. 런처나 사용자 추가 앱은 같은 게이트웨이 출처에 있는 다른 앱이나 워크스페이스를 제어하는 광범위한 서비스 워커를 등록할 수 없습니다.

Podman으로 직접 시작한 컨테이너는 워크스페이스 신뢰 경계 밖에 있습니다. LabPod는 읽기 전용 안전 및 용량 계산을 위해 이 컨테이너를 조사할 수 있지만, 프록시 연결이나 런처, 터미널, 로그, 선언 포트, 생명주기 작업은 제공하지 않습니다. 기존 /ws/c:<container>/ 및 /ws/_discovered/ 형식에는 404를 반환합니다.

실행 모델

기본 systemd unit은 LabPod를 root로 실행합니다(User=root). 그렇더라도 루트리스 워크스페이스는 소유자의 Linux 계정으로 실행됩니다. 서버는 argv 배열을 구성하고 sudo -u <owner> 또는 같은 사용자 컨텍스트 명령으로 Podman을 실행합니다. 사용자 입력을 넣어 bash -c로 실행하지 않습니다.

TLS

기본적으로 LabPod는 포트 24680에서 일반 HTTP로 서비스합니다. HTTPS를 위한 옵션:

옵션 1: 자체 서명 인증서 (private LAN 사용 시):

# In /etc/labpod/labpod.env:
LABPOD_TLS_SELF_SIGNED=true
LABPOD_TLS_HOSTS=192.168.1.10,labpod.lan    # optional extra SANs

첫 번째 시작 시 LabPod는 /var/lib/labpod/tls/에 자체 서명 인증서를 생성하고 캐시합니다. 인증서는 만료가 다가오면 자동으로 갱신됩니다.

데스크톱 런처의 TOFU(Trust On First Use) 핀을 위한 SHA-256 지문을 가져오려면:

Ubuntu / Debian Rocky / RHEL / AlmaLinux / Fedora

sudo labpod admin tls-fingerprint

# Run these as root
labpod admin tls-fingerprint

옵션 2: 운영자 제공 인증서:

LABPOD_TLS_CERT=/etc/labpod/tls/server.crt
LABPOD_TLS_KEY=/etc/labpod/tls/server.key

LABPOD_TLS_CERT와 LABPOD_TLS_KEY는 함께 설정되어야 합니다.

포트 가드 (공유 호스트에 권장)

여러 사용자가 함께 쓰는 Linux 호스트에서는 워크스페이스 앱 트래픽이 인증된 LabPod 게이트웨이를 거치도록 루프백 포트 가드를 활성화하십시오:

# In /etc/labpod/labpod.env:
LABPOD_PORT_GUARD=nft

서버가 시작될 때 nftables 규칙을 설치하여 워크스페이스 포트로 향하는 직접 루프백 연결을 제한합니다. 일반 런처 및 사용자 포트 링크는 그대로 사용할 수 있습니다. 서버는 root로 실행해야 하며 기본 설치가 이 방식입니다.

doctor는 포트 가드가 올바르게 설치되었는지 보고합니다:

Ubuntu / Debian Rocky / RHEL / AlmaLinux / Fedora

sudo labpod admin doctor

# Run these as root
labpod admin doctor

리버스 프록시 및 신뢰된 헤더

LabPod가 리버스 프록시(nginx, Caddy, Cloudflare Tunnel) 뒤에 있다면 프록시 헤더 전달을 활성화하십시오:

LABPOD_TRUST_PROXY_HEADERS=true

LabPod가 인터넷에 직접 노출되지 않을 때만 이 옵션을 활성화하십시오. 이 플래그가 꺼진 기본값 상태에서는 클라이언트가 보낸 X-Forwarded-Host와 X-Forwarded-Proto를 무시합니다. 직접 배포 시에는 이 동작이 올바릅니다.

WebSocket 터미널 엔드포인트에서는 사용자가 서버 주소와 다른 도메인 이름으로 연결할 때 신뢰할 출처를 추가하십시오:

LABPOD_WS_ALLOWED_ORIGINS=https://labpod.example.com