바인드 마운트가 홈 서버에서 컨테이너 보안에 어떤 영향을 미치나요?

바인드 마운트는 컨테이너 내부 프로세스에 홈 서버의 실제 경로에 대한 직접 접근 권한을 부여하여 컨테이너 보안을 변경합니다. 이 접근은 일회용 컨테이너 파일 시스템 경계 일부를 우회하며, 호스트 파일, 소유권 규칙, 라벨, 마운트 옵션이 컨테이너 보안 모델의 일부가 됩니다.

마운트가 자동으로 위험한 것은 아닙니다. 위험은 노출된 호스트 경로, 컨테이너가 쓰기 가능한지 여부, 프로세스가 실행되는 사용자, 도커 소켓, 구성 디렉터리, 백업 폴더 같은 민감한 경로 포함 여부에 따라 달라집니다.

바인드 마운트는 어떤 경계를 넘나요?

컨테이너는 보통 자체 계층화된 파일 시스템과 선택된 관리 볼륨만 봅니다. 바인드 마운트는 실제 호스트 경로를 노출하므로, 해당 경로를 통해 생성되거나 변경된 파일은 호스트 파일 시스템의 변경입니다.

컨테이너는 여전히 네임스페이스와 호스트 커널을 사용하지만, 마운트된 디렉터리는 더 이상 이미지의 쓰기 가능한 레이어 뒤에 격리되어 있지 않습니다. 애플리케이션은 호스트 서비스, 백업 도구 또는 다른 컨테이너가 사용할 수 있는 동일한 파일과 상호작용할 수 있습니다.

이로 인해 보안 질문이 '이미지 안에 무엇이 있나?'에서 '이 프로세스가 접근할 수 있는 호스트 객체는 무엇인가?'로 바뀝니다. 작은 미디어 디렉터리와 서버 루트 파일 시스템은 동일한 컨테이너 이미지라도 매우 다른 노출 범위를 만듭니다.

왜 쓰기 권한이 폭발 범위를 확장하나요?

바인드 마운트는 별도로 설정하지 않는 한 일반적으로 쓰기 가능 상태입니다. 쓰기 가능한 마운트는 컨테이너 프로세스가 컨테이너 권한으로 호스트 파일을 수정할 수 있음을 의미합니다.

손상된 미디어 서버는 마운트된 라이브러리를 암호화하거나, 구성을 변경하거나, 스크립트를 교체하거나, 컨테이너 제거 후에도 남아 있을 파일을 삭제할 수 있습니다. 데이터가 컨테이너 레이어 외부에 존재하기 때문에 피해가 지속됩니다.

스냅샷과 백업도 도움이 될 수 있지만, 반드시 건강한 이전 상태를 포함해야 합니다. 스냅샷은 이미 손상된 데이터를 보존할 수 있습니다, 따라서 마운트 설계는 버전 기록이 필요하기 전에 피해를 제한해야 합니다.

읽기 전용 마운트는 어떻게 위험을 줄이나요?

읽기 전용 바인드 마운트는 호스트 가시성을 유지하면서 해당 마운트를 통한 일반 쓰기를 차단합니다. 구성, 미디어 입력, 인증서 또는 참조 데이터를 위해 읽기 전용 마운트는 애플리케이션이 필요한 파일을 숨기지 않으면서 파일 시스템 변경을 제한합니다.

읽기 전용은 피해 범위를 크게 줄이지만 완전한 격리는 아닙니다. 마운트된 경로가 너무 넓으면 컨테이너가 여전히 비밀, 개인 파일, 메타데이터 또는 자격 증명을 읽을 수 있습니다.

애플리케이션은 데이터베이스, 업로드, 캐시 또는 로그를 위한 명시적 쓰기 가능한 위치도 필요합니다. 그 좁은 디렉터리만 쓰기 가능하게 마운트하는 것이 전체 애플리케이션 트리나 사용자 홈 디렉터리를 노출하는 것보다 안전합니다.

왜 UID, GID, 그리고 라벨이 여전히 중요한가요?

바인드 마운트는 호스트 파일 시스템의 소유권과 접근 규칙을 유지합니다. 컨테이너 프로세스는 추상 볼륨 권한을 얻지 못하며, 볼륨 마운트는 잘못된 라벨과 접근 규칙으로 호스트 정보를 노출할 수 있습니다.

컨테이너 루트가 호스트 루트에 직접 매핑될 때, 쓰기 가능한 경로는 특히 위험할 수 있습니다. 애플리케이션을 비루트 UID로 실행하면 접근이 좁아지지만, UID와 GID 값이 일치하지 않으면 사용자가 과도한 chmod 설정으로 '해결'하는 권한 실패가 발생할 수 있습니다.

SELinux 또는 다른 강제 접근 제어 시스템은 유닉스 모드 비트 외에 두 번째 결정을 추가합니다. 올바른 라벨은 숫자 소유권이 접근을 허용하는 것처럼 보여도 컨테이너를 제한할 수 있으며, 라벨링을 비활성화하면 그 보호가 사라질 수 있습니다.

왜 일부 호스트 경로가 훨씬 더 위험할까요?

위험은 파일 수뿐만 아니라 권한에 의해 결정됩니다. 도커 소켓을 마운트하면 데몬 제어 권한이 노출되어 침해된 컨테이너가 권한 있는 컨테이너를 생성하거나 추가 호스트 경로를 마운트할 수 있습니다.

서버 루트, `/etc`, SSH 키, 패키지 구성 또는 애플리케이션 비밀을 마운트하면 하나의 컨테이너 침해가 더 넓은 호스트 접근으로 이어질 수 있습니다. 실행 가능한 스크립트가 포함된 마운트는 다른 호스트 프로세스가 해당 파일을 실행할 경우 지속 경로가 될 수도 있습니다.

일반 데이터 경로도 여전히 민감할 수 있습니다. 가족 사진, 비밀번호 관리자 내보내기, 세금 기록, 백업은 공격자가 컨테이너를 탈출하는 데 도움이 되지 않더라도 무단 읽기나 삭제는 이미 심각한 보안 실패입니다.

홈 서버 설계에서 바인드 마운트는 어떻게 해야 할까요?

애플리케이션 요구를 충족하는 가장 작은 호스트 디렉터리부터 시작하세요. 마운트 네임스페이스는 파일 시스템 뷰를 격리하며, 각 바인드 마운트는 그 뷰에 대한 의도된 예외로 취급해야 합니다.

입력에는 읽기 전용 접근을 선호하고, 컨테이너는 전용 비루트 사용자로 실행하며, 비밀 정보는 넓은 데이터 마운트 밖에 두고, 애플리케이션이 진정으로 필요하지 않으면 소켓이나 시스템 디렉터리는 피하세요.

심볼릭 링크, 권한, 라벨이 적용된 후 실제 경로를 검토하세요. 안전한 설계는 한 컨테이너의 제거 또는 손상이 오직 그 컨테이너의 좁은 데이터 경계에만 영향을 미치도록 해야 하며, 독립적인 백업은 또 다른 복구 경계를 유지합니다.

자주 묻는 질문

바인드 마운트가 Docker 볼륨보다 덜 안전한가요?

자동으로 그렇지는 않습니다. 바인드 마운트는 선택된 호스트 경로를 직접 노출하는 반면, 관리되는 볼륨은 더 추상화되어 있습니다. 보안은 경로 범위, 쓰기 권한, 프로세스 신원, 라벨에 따라 달라집니다.

읽기 전용이 민감한 마운트를 안전하게 만들까요?

해당 마운트를 통한 일반적인 수정은 막지만, 컨테이너는 여전히 경로가 노출하는 모든 것을 읽을 수 있습니다. 비밀 정보와 개인 파일은 필요하지 않으면 마운트하지 않아야 합니다.

비루트 컨테이너가 바인드 마운트된 파일을 손상시킬 수 있나요?

네, UID나 그룹이 호스트 경로에 쓰기 권한을 가질 때 그렇습니다. 비루트 사용자는 권한을 줄이지만 실제 소유권과 접근 규칙을 무시하지는 않습니다.

왜 Docker 소켓 마운트가 위험한가요?

소켓은 Docker 데몬을 제어합니다. 접근 권한이 있으면 컨테이너가 권한이 부여된 작업을 시작하거나, 비밀 정보를 검사하거나, 추가 호스트 디렉터리를 마운트할 수 있습니다.

최종 요점

바인드 마운트는 컨테이너 파일 시스템 경계를 의도적으로 뚫는 구멍입니다. 그 보안성은 호스트 경로가 노출하는 기능에 따라 달라집니다: 읽기 전용 데이터, 쓰기 가능한 애플리케이션 상태, 민감한 비밀 정보, 또는 관리 제어. 좁은 경로, 읽기 전용 기본값, 비루트 사용자, 올바른 라벨, 독립적인 백업은 한 컨테이너가 홈 서버 전체의 실패로 이어지는 것을 막습니다.