VPN Compose 파일을 공유하시나요? 렌더링된 사본에서 비밀을 지우세요

Compose 파일을 공유할 때마다 두 개의 산출물이 존재한다: 당신이 작성한 것과 도구가 변수를 치환한 뒤 렌더링하는 것이다. 두 번째가 첫 번째보다 민감한 경우가 많고, 사람들이 읽지 않고 문제 보고서에 붙여 넣는 것도 바로 이쪽이다. 원본 파일만 검토한다면 잘못된 문서를 검토하는 셈이다.

무엇을 지울지 결정하기 전에 각 사본이 무엇을 담을 수 있는지 비교하라.

렌더링된 모델은 다른 문서다

Compose는 환경 변수를 해석하고 오버라이드 파일을 병합하며, 독자가 손으로 쓴 값과 더 이상 구별할 수 없는 실효 설정을 만들어 낸다. 원본의 변수 이름 같은 참조가 출력에서는 계정 토큰 자체가 된다. 파일을 진단에 쓸모 있게 만드는 구조는 그 변환을 견디며, 애초에 있어서는 안 될 것들도 함께 견딘다.

첨부하기 전에 파일을 직접 렌더링하고, 그 출력을 검토 대상 산출물로 다뤄라. 렌더링할 수 없다면 무엇을 게시하려는지 알 수 없다.

비밀은 키 필드보다 더 많은 곳에 있다

분명한 것부터 시작하라: 개인 키, 사전 공유 키, 토큰, 비밀번호, 자격 증명이 포함된 연결 URL이다. 참조는 삭제가 아니므로, 그다음 파일이 가리키는 모든 것을 보라. 서비스에 마운트된 env 파일, 호스트에서 바인드 마운트된 설정 파일, 토큰을 담은 라벨, 비밀번호가 들어간 명령 인수는 YAML이 깨끗해 보여도 배포와 함께 이동한다. 안심되는 이름의 변수에 붙여 넣은 키도 여전히 키다.

호스트 경로와 서비스 이름은 두 번째 종류의 정보를 흘린다. 홈 디렉터리 이름, 내부 호스트 이름, 네트워크 대역은 자격 증명을 하나도 담지 않고도 개인이나 조직을 식별할 수 있으며, 그 맥락도 같은 이유로 지울 가치가 있다.

비밀의 선언은 비밀이 아니다

Compose의 비밀 객체는 선언과 재료를 분리한다: 서비스는 경로나 대상을 받고, 내용은 다른 곳에 산다. 검토자는 비밀이 존재한다는 것과 그것이 어떻게 마운트되는지를 봐야 하므로, 재료를 바꾸면서 선언을 유지하는 것이 보통 옳은 거래다. 살아남으면 안 되는 것은 내용 자체다.

라벨과 주석도 같은 대접을 받아야 한다. 어떤 볼트 경로가 운영 키를 보관하는지 적은 주석은 키를 담고 있지 않아도 공격자에게 어디를 봐야 하는지 알려 준다.

형태를 유지해 파일이 여전히 진단하도록 하라

네트워크 모드, 이미지 버전, 기능 설정을 제거하는 삭제는 아무도 디버깅할 수 없는 파일을 만든다. 민감한 값만 바꾸고 관계(어느 서비스가 무엇을 마운트하는지, 어느 네트워크에 합류하는지, 어떤 장치가 필요한지)는 유지하라. 독자가 사라진 경로나 사용할 수 없는 장치를 설명하는 데 쓰는 부분이 바로 이것이다. 동료가 자신의 작동 중인 배포와 비교할 수 있는 것도 이 판본이다.

docker compose -f compose.yaml config > rendered.yaml
grep -nE 'PRIVATE_KEY|PASSWORD|TOKEN|PSK|PrivateKey|passphrase' rendered.yaml
wc -l rendered.yaml

삭제한 사본을 마치 작동하는 원본인 것처럼 배포하지 마라. 그것은 설명이며, 안전해 보이도록 편집된 설명은 설정 오류처럼 보이는 방식으로 실패할 것이다.

재료가 노출되었다면 교체하라

첨부를 지운다고 다른 사람이 이미 만든 사본이 사라지지는 않으며, 미러와 캐시는 각자의 사본을 보관한다. 유출된 모든 것에 대해 발급자의 폐기와 교체 절차를 사용하고, 그다음 배포를 갱신하라. 순서가 중요한데, 먼저 교체하고 나중에 폐기하면 유효한 자격 증명이 둘인 창이 남기 때문이다.

지원 스레드에서는 정확한 오류, 이미지 버전, 네트워크 모드, 그리고 중요한 비밀이 아닌 설정 하나를 먼저 제시하라. 그 조합이 사라진 장치나 끊긴 경로를 키보다 훨씬 자주 설명한다.