고객은 인스턴스 컨테이너 안에서 root 권한을 받습니다. 공급자 서버가 있는 내부망과 서버 자신을 고객 인스턴스로부터 지키기 위해 설치 스크립트와 에이전트가 무엇을 하고, 무엇은 하지 않는지 정리했습니다.
1. 설치 스크립트가 추가하는 방화벽 규칙
확인 범위
이 절차는 Ubuntu 24.04 판정 환경(GPU 없음)에서 확인했습니다. 실제 GPU 서버에서의 확인은 진행 중입니다.
설치 스크립트는 10 단계에서 iptables에 WattWorks 전용 체인 두 개를 만들고, 적용 전에 아래 요약을 보여 주며 「이 규칙을 적용할까요?」라고 묻습니다.
적용할 규칙 (기존 INPUT 정책 · 규칙은 바꾸지 않습니다):
· INPUT 맨 앞 → WW-NODE-INPUT
허용 tcp <인스턴스 포트 범위> (인스턴스) · tcp 30443 (노드 HTTPS)
인스턴스 컨테이너(br-wwi-+) → 이 서버 접속 차단 (응답은 통과)
그 밖은 기존 INPUT 규칙으로 넘깁니다 (SSH 등 그대로)
· DOCKER-USER 맨 앞 → WW-ISOLATION
인스턴스 컨테이너 → 사설망 · 메타데이터(169.254) · 루프백 · 메일 포트(25·465·587) 차단WW-NODE-INPUT— 인스턴스 포트 범위와 노드 HTTPS30443을 허용하고, 인스턴스 컨테이너가 이 서버 자신에 접속하는 것을 막습니다.WW-ISOLATION— 인스턴스 컨테이너가 공급자의 내부망(NAS · PC · 공유기 관리 화면), 클라우드 메타데이터 주소, 루프백, 메일 발송 포트로 나가는 것을 막습니다. 밖에서 시작된 연결의 응답은 통과합니다.- 규칙은
wattworks-firewall.service가 서버가 켜질 때마다 다시 적용합니다.
에이전트는 인스턴스마다 별도 네트워크를 만들고, 컨테이너의 권한(capability)을 최소한으로 줄여 실행합니다. 호스트 네트워크나 privileged 모드는 쓰지 않습니다.
2. 막지 않는 것 — 공급자가 맡는 것
- 서버에 이미 있는 INPUT 정책과 규칙은 바꾸지 않습니다. SSH를 포함한 서버 자체 서비스의 접근 제한은 공급자가 관리합니다.
- 인스턴스가 인터넷으로 나가는 연결은 막지 않습니다(메일 발송 포트 제외). 고객이 모델과 데이터를 받아야 하기 때문입니다.
ufw·firewalld가 켜져 있으면 설치 스크립트가 멈춥니다(종료 코드6). 스크립트는 이 도구들을 끄지 않으니, 비활성화한 뒤에는 서버 방화벽 정책을 공급자가 직접 iptables로 관리해야 합니다.
아직 실제 GPU 서버에서 확인하지 않았습니다. ufw · firewalld를 끈 뒤의 동작은 판정 환경에서만 확인했습니다.
방화벽 서비스를 멈추지 마세요
wattworks-firewall.service를 멈추면 전용 체인이 제거되어 인스턴스 격리가 풀립니다. 유닛에 아래 줄이 있기 때문입니다. 서버를 운영하는 동안에는 이 서비스를 켜 두세요.
ExecStop=/usr/local/sbin/wattworks-firewall remove이 설정은 바꾸지 마세요
고객의 데이터 반환과 디스크를 지키는 설정입니다.
/etc/wattworks/agent.env의WW_EXPORT_RESERVE_GIB를 200 미만으로 낮추지 마세요. 내려받기 파일이 고객에게 판 디스크 자리를 침범할 수 있습니다./etc/wattworks/caddy/의Caddyfile사이트 블록에log를 더하지 마세요. 접근 로그에 고객의 내려받기 주소(토큰)가 남습니다./etc/wattworks/caddy/routes/와/data/exports/는 root 만 쓸 수 있게 두세요. 다른 사용자에게 쓰기 권한을 주지 마세요.
3. 격리 자체 점검 — 매시간
에이전트는 한 시간마다 격리 규칙이 실제로 막고 있는지 잽니다. 규칙이 목록에 있는지가 아니라, 인스턴스 자리에서 내부망 주소로 실제로 닿는지 걸어 봅니다.
- 점검에 실패하면 그 노드에는 새 인스턴스를 배치하지 않습니다.
- 연속으로 실패하면 노드가 정지됩니다. 이미 실행 중인 고객 인스턴스는 점검 결과 하나로 종료하지 않습니다.
- 격리 실패로 정지된 노드는 점검이 다시 통과한 뒤에만 관리자가 정지를 풀 수 있습니다.
점검 실패의 흔한 원인은 누군가 iptables 규칙을 지웠거나 방화벽 서비스를 멈춘 경우입니다. 토큰 없이 설치 명령을 다시 실행하면 규칙을 새로 쌓습니다.
4. IPv6
설치 스크립트는 IPv6 규칙을 만들지 않습니다. 요약 끝의 「IPv6(ip6tables) 규칙은 만들지 않습니다」가 그 뜻입니다. 서버에 IPv6 주소가 있다면 IPv6로 들어오고 나가는 연결은 위 두 체인이 다루지 않으니, 서버 방화벽에서 직접 관리하세요.
아직 실제 GPU 서버에서 확인하지 않았습니다. IPv6가 켜진 서버에서 인스턴스 격리가 어떻게 동작하는지는 확인 범위 밖입니다.
5. 등록 토큰과 노드 키
- 설치 스크립트는 등록 토큰을 에이전트에 표준 입력으로만 넘기고, 설정 파일 · 서비스 유닛 · 로그에 쓰지 않습니다.
- 명령에 붙인 토큰은 실행 중에는 프로세스 인자로, 끝난 뒤에는 셸 히스토리에 남습니다. 토큰은 한 번 쓰면 다시 쓸 수 없고, 쓰지 않았어도 24시간 뒤 만료됩니다.
- 등록이 끝나면 결과 끝에 「등록 토큰은 이미 쓰였습니다 — 셸 히스토리에 남아도 다시 쓸 수 없습니다.」가 나옵니다.
- 등록하면 노드 키가 서버에 저장되고, 에이전트는 이 키로 WattWorks에 연결합니다. 재발급한 토큰으로 재등록이 성공하는 순간 옛 키는 무효가 됩니다.
- WattWorks 서버는 NVIDIA 장치가 없는 테스트용(Mock) 노드의 등록을 받지 않습니다.