여기에는 항상 의심스러운 앱들이 올라옵니다. 솔직히 말해서, 문제는 '바이브 코딩(vibecoding)' 자체라기보다는, 이 앱들이 악성적이거나 무능하여 사용자의 데이터를 개발자 서버로 업로드하며 유출할 수 있다는 점입니다. 솔직히 저는 모든 것을 검토할 시간이 없지만, 종종 뭔가를 시도해 보고 싶습니다. Docker를 사용한다면, 마음의 평화를 얻을 수 있는 다소 간단한 기술이 있습니다. 이 접근 방식을 사용하면 어떤 신뢰할 수 없는 서비스라도 실행할 수 있지만, 외부로 연결하는 것이 허용되지 않습니다. 오직 들어오는 요청에만 응답할 수 있습니다. 대부분의 앱에는 충분합니다. 본질적으로, 서비스를 평소처럼 실행하는 docker-compose 파일을 작성하되, 아웃바운드 트래픽을 차단하는 게이트웨이 역할을 하는 두 번째 서비스 뒤에 배치합니다. (참고: 많은 저장소들이 컨테이너에서 실행하기 위한 'docker run' 예시를 제공하는 끔찍한 결정을 내립니다. 어떤 LLM에게도 '다음 docker run 명령어를 docker compose 파일로 변환해 줘'라고 요청하세요. 저는 어쨌든 평생 compose 파일을 사용하는 것을 추천합니다. 이는 쉬운 반복성 + 백업 가능성/git 커밋 + 그리고 여기에서 필요한 하나의 파일에 여러 서비스를 포함하는 것과 같은 더 많은 기능을 가진 'docker run' 방식입니다. 그런 다음 ~/dockerstuff/someapp/로 이동하여 'docker compose up'을 실행하기만 하면 됩니다.) 예를 들어, 원래의 신뢰할 수 없는 앱의 compose 파일이 다음과 같다고 가정해 봅시다. 예시는 포트 8000에서 서비스하는 untrustedservice: image: python:latest container_name: untrustedservice ports: - "0.0.0.0:8000:8000" command: [python, -m, http.server, "8000", --directory, /srv] 대신 이것을 사용합니다. 여기서 우리는 다음 작업을 수행합니다. 1) 신뢰할 수 없는 서비스를 메인 네트워크에서 격리하고, 2) untrusted 서비스에 도달하기 위한 단방향 게이트웨이로 socat을 사용합니다. socat은 작고 오픈 소스인 바이너리로, 추가 컨테이너가 필요한 RAM은 1.2MB에 불과합니다.

services:

socat 게이트웨이 untrustedservice_gateway:

image: alpine/socat:latest
container_name: untrustedservice_gateway
init: true

들어오는 포트 8000 연결을 untrustedservice의 포트 8000으로 리디렉션

command: TCP4-LISTEN:8000,fork,reuseaddr
TCP4:offline_untrustedservice:8000
ports:
-"0.0.0.0:8000:8000"
networks:

이 게이트웨이만 두 네트워크에 연결됨

• public_network
• isolated_network
  depends_on:

untrustedservice

확장된 untrusted 서비스 정의