보안 및 강화

신원 및 신뢰 경계

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

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

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

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

root는 워크스페이스를 소유할 수 없습니다. 워크스페이스 컨테이너는 비root Linux 사용자로 실행되어야 하므로 root 계정은 자체 워크스페이스를 생성하거나 시작할 수 없습니다. 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는 함께 설정되어야 합니다.

포트 가드

소유자 인식 루프백 포트 가드는 기본으로 켜져 있습니다. 워크스페이스 소유자는 자신에게 할당된 localhost 또는 SSH 포워딩 포트를 사용할 수 있지만, 다른 Linux 사용자의 접근은 거부합니다. 따라서 워크스페이스 앱 트래픽은 인증된 LabPod 게이트웨이를 거칩니다. 서버는 기본값처럼 root로 실행되어야 하며 nft가 있어야 합니다.

# 보호되지 않은 같은 호스트 접근을 의도적으로 허용할 때만 끄세요:
LABPOD_PORT_GUARD=none

nftables를 사용할 수 없거나 지원하지 않으면 LabPod는 경고를 남기고 계속 실행합니다. 일반 런처와 사용자 포트 링크는 계속 사용할 수 있습니다.

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

Ubuntu / Debian Rocky / RHEL / AlmaLinux / Fedora

sudo labpod admin doctor

# Run these as root
labpod admin doctor

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

LabPod가 리버스 프록시 뒤에 있다면 프록시 헤더 전달을 켜고 각 LabPod 리스너에 연결하는 직접 peer를 선언하십시오:

# 같은 호스트의 nginx, Caddy, OpenResty:
LABPOD_TRUST_PROXY_HEADERS=true
LABPOD_TRUSTED_PROXY_PEERS=loopback,unix

# 별도 edge 네트워크라면 LabPod가 보는 source 주소 또는 CIDR을 사용하세요.
# LABPOD_TRUSTED_PROXY_PEERS=10.40.8.0/24,2001:db8:40::/64

LabPod가 인터넷에 직접 노출되지 않을 때만 이 옵션을 활성화하십시오. 플래그가 꺼져 있으면 전달 헤더를 무시합니다. 켜져 있어도 정확한 IP 주소, CIDR, loopback, unix peer만 전달 메타데이터를 제공할 수 있으며 호스트명은 허용되지 않습니다. 백엔드 포트는 이 peer들만 접근할 수 있게 방화벽으로 제한하고, 프록시는 클라이언트가 보낸 전달 헤더를 덧붙이지 말고 교체하도록 구성하세요. 두 설정 중 어느 하나를 바꾼 뒤에는 labpod.service를 재시작하세요.

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

LABPOD_WS_ALLOWED_ORIGINS=https://labpod.example.com