핵심 정리
bash
node \
--permission \
--allow-fs-read="/app/config" \
--allow-fs-write="/app/tmp" \
--allow-net="api.example.com:443" \
server.jsjavascript
if (!process.permission?.has("fs.read", "/app/config/app.json")) {
throw new Error("설정 파일 읽기 권한 없음");
}권한 경계
먼저 머릿속에 잡아 둘 기본형은 아래입니다.
- 권한 모델 활성화:
node --permission app.js - 파일 읽기 허용:
--allow-fs-read - 파일 쓰기 허용:
--allow-fs-write - 네트워크 허용:
--allow-net - 런타임 확인:
process.permission.has(scope, reference)
보안 옵션보다 실행 경계로 읽는다
Permission Model의 핵심은 앱이 접근 가능한 파일, 네트워크, 자식 프로세스 범위를 실행 시점에 줄이는 것입니다. Node 20에서 도입됐고, 22.13+/23.5+부터는 더 이상 experimental이 아닙니다.
기본값은 닫고 필요한 것만 연다
--permission을 켜면 허용하지 않은 리소스는 막힙니다. 필요한 경로와 호스트를 먼저 인벤토리하는 작업이 중요합니다.
process.permission.has()는 더 좋은 오류 메시지를 위한 카드다
권한이 없어 예외가 터지기 전에, 어떤 권한이 비어 있는지 더 명확하게 보여주고 싶을 때 쓸 만합니다.
이 모델은 보안 경계라기보다 seat belt에 가깝다
권한 모델은 신뢰한 코드가 실수로 너무 넓은 자원에 접근하는 일을 줄이는 데 유용합니다. 반대로 악성 코드까지 완전히 막는 강한 샌드박스로 읽으면 과대평가가 됩니다.
child process와 worker는 같은 제약을 자동으로 물려받지 않는다
권한 모델을 켰다고 모든 실행 경계가 자동으로 같은 제약을 이어받는 것은 아닙니다. Node 문서의 제약 사항 기준으로도 child Node process와 worker thread에는 이 모델이 자동 상속되지 않습니다. 그래서 자식 프로세스, 워커, 런타임 플래그 경계까지 같이 읽는 편이 더 정확합니다.
언제 켤까
체크포인트
- 파일 읽기 허용:
--allow-fs-read - 파일 쓰기 허용:
--allow-fs-write - 네트워크 허용:
--allow-net - 자식 프로세스 허용:
--allow-child-process - worker 허용:
--allow-worker - 런타임 확인:
process.permission.has(...) - 강한 샌드박스가 아니라 실행 seat belt로 읽기
주의할 점
--permission을 켜지 않으면 이 모델은 적용되지 않는다. 또 이 기능을 강한 보안 샌드박스로 과대평가하면 운영 판단이 어긋날 수 있다. 공식 문서도 악성 코드를 막는 보안 경계로 보지 말라고 설명하므로, 필요한 권한을 좁히는 실행 seat belt로 읽는 편이 맞다.
참고 링크
1 sources