VPN에 필요한 것보다 특권 모드가 더 넓은 이유

컨테이너가 터널을 열지 않아서 특권 플래그를 넣었더니 이제 동작한다. 그 순서가 증명한 것은 적어도 하나의 권한이 빠졌다는 것뿐이며, 어느 것인지에 대해서는 아무것도 말하지 않는다. 특권 모드는 터널 인터페이스에 필요한 것보다 훨씬 넓은 권한 집합과 장치 접근을 부여한다.

플래그가 실제로 바꾸는 것

특권 컨테이너는 광범위한 권한과 호스트 장치 접근을 받는데, 이는 네트워크 경로가 요구하는 것보다 훨씬 큰 허용이다. 정확한 집합은 속설이 아니라 실행 환경이 문서화하며, Docker의 컨테이너 실행 문서가 사용 가능한 특권 옵션을 설명한다. 한 번 읽으면 터널이 전체의 작은 부분이라는 것을 알 수 있다.

더 좁은 두 가지 요구 사항이 대부분의 VPN 컨테이너를 덮는다. 인터페이스를 구성하려면 네트워크 관리 권한이 필요하고, 터널 장치를 열려면 그 특정 장치 노드에 대한 접근이 필요하다. 이것은 별개의 허용이며, 둘을 모두 주어도 포괄 옵션보다는 좁다. 특권 집합의 나머지는 터널과 아무 관련이 없다. 호스트 수준 접근이 정말 필요한 워크로드를 위해 존재하며, VPN 컨테이너는 보통 그중 하나가 아니다.

각 오류를 하나의 전제 조건에 맞추십시오

오류 메시지는 그것을 억제하기 전에 읽으면 어느 전제 조건이 빠졌는지 알려준다. 장치 노드에 관한 메시지는 장치를 지목하고, 허용되지 않은 작업에 관한 메시지는 권한을 지목하며, 모듈이나 sysctl에 관한 메시지는 커널 지원을 지목한다. 각각 고치는 방법이 다르고, 그중 권한인 것은 하나뿐이다.

빠진 구성 파일은 모든 권한을 부여한 뒤에도 빠진 채로 남으며, 그래서 특권 모드가 아무것도 바꾸지 못할 때가 있다. 컨테이너는 시작되고 터널은 여전히 실패하며, 진짜 오류는 처음부터 권한에 관한 것이 아니었다. 커널 지원은 세 번째 경우이며 가장 잘못 읽기 쉽다. 호스트에 로드되지 않은 모듈은 비특권 컨테이너 안에서 로드할 수 없고, 컨테이너 안에서 권한을 더 주어도 호스트의 상태는 바뀌지 않는다.

증상이 아니라 요구 사항을 확인하십시오

이미지가 문서화한 최소 호출에서 시작해 실행하고, 실패의 정확한 텍스트를 남긴다. 그다음 한 번에 하나씩 허용을 추가하고 어떤 추가가 결과를 바꿨는지 기록한다.

ls -l /dev/net/tun
docker run --rm --cap-add NET_ADMIN --device /dev/net/tun image:tag
ip -br link show type tun

장치를 볼 수 있고 권한도 있지만 여전히 실패하는 컨테이너는 문제가 다른 곳에 있다고 말해 준다. 그것은 유용한 결과이며, 특권 모드는 그것을 숨겼을 것이다.

올바르게 부여된 장치 노드라도 그룹 소유권이 잘못되면 허용이 빠진 것과 같은 오류가 나므로 호스트의 장치 권한도 확인하십시오.

동작하는 가장 좁은 허용을 기록하십시오

배포에 필요한 모든 장치와 권한을 그것을 정당화한 오류와 함께 적는다. 그 기록이 다음 사람이 무언가를 안전하게 제거할 수 있게 해 주고, 컨테이너가 특권으로 보고될 때 감사자가 요구하는 것도 바로 그것이다.

호스트 네트워킹, 호스트 마운트, 실행 환경 옵션은 각각 허용의 영향을 넓힐 수 있으므로 주변 맥락도 검토하십시오. 그 모두를 결합한 격리된 실험실 호출은 아무리 잘 동작했더라도 운영 구성이 아니다. 배포를 끝났다고 부르기 전에 애플리케이션, 그 DNS 동작, 터널 실패를 시험하십시오. 인터페이스를 만드는 허가는 송출 정책이 아니며, 완벽하게 터널링하는 컨테이너도 애플리케이션이 보내는 모든 것을 여전히 라우팅한다.