컨테이너 위협

컨테이너는 애플리케이션과 해당 종속 항목을 함께 패키징하여 어디서나 동일한 방식으로 실행되게 합니다.

도커와 같은 도구는 가상 머신에 비해 컨테이너가 빠르게 시작되고 가볍기 때문에 컨테이너를 대중화했습니다.

가상 머신과 달리 같은 호스트에서 실행되는 컨테이너는 운영 체제 커널을 공유합니다.

공격자가 컨테이너에서 탈출하면 공유 커널이 호스트와 다른 컨테이너로 이어지는 경로가 될 수 있습니다.

많은 팀이 공개 레지스트리에서 이미지를 가져옵니다.

출처를 알 수 없는 제작자의 이미지에는 악성 코드, 백도어 또는 숨겨진 암호화폐 채굴기가 포함될 수 있습니다. 이미지를 어디에서 가져왔는지 항상 확인해야 합니다.

신뢰할 수 있는 이미지라도 오래된 상태라면 위험할 수 있습니다.

몇 달 전에 만들어진 기본 이미지에는 상위 프로젝트에서 오래전에 패치한 라이브러리의 알려진 취약점이 남아 있을 수 있습니다.

흔한 실수는 이미지에 암호나 API 키를 직접 기록하는 것입니다.

이미지를 가져오는 사람은 누구나 해당 비밀 정보를 읽을 수 있습니다. 레이어를 검사하면 쉽게 드러납니다:

기본적으로 컨테이너 내부의 프로세스는 흔히 루트로 실행됩니다.

해당 프로세스가 침해되면 공격자는 컨테이너 내부에서 루트 수준의 권한을 얻으므로, 탈출이 훨씬 더 위험해집니다.

추가 권한을 부여하는 플래그는 공격 표면을 넓힙니다.

컨테이너를 특권 모드로 실행하면 격리가 대부분 제거됩니다:

절대적으로 필요한 경우가 아니라면 사용하지 않습니다.

컨테이너는 네트워크 포트를 공개하는 경우가 많습니다.

인터넷에 노출된 데이터베이스처럼 불필요하게 열린 포트는 공격자에게 직접적인 표적이 됩니다. 실제로 필요한 포트만 공개합니다.

이미지가 암호화되지 않았거나 인증되지 않은 레지스트리를 통해 전송되면 공격자가 전송 중에 이미지를 변조할 수 있습니다.

신뢰할 수 있는 레지스트리와 TLS 및 접근 제어를 사용합니다.

제한이 없는 컨테이너는 호스트의 CPU와 메모리를 모두 사용할 수 있습니다.

이로 인해 다른 작업에 서비스 거부가 발생합니다. 한 컨테이너가 나머지 작업의 자원을 고갈시키지 않도록 리소스 제한을 설정합니다.

컨테이너 위험은 전체 수명 주기에 걸쳐 발생합니다:

• 기반으로 삼는 이미지
• 이미지를 가져오는 레지스트리
• 실행할 때 사용하는 권한
• 공유하는 호스트

각 단계에 주의를 기울여야 합니다.

컨테이너 탈출이 VM 탈출보다 더 심각한 경우가 많은 이유는 무엇인가요?

컨테이너 위협에는 신뢰할 수 없는 이미지, 오래된 기본 이미지, 이미지에 포함된 비밀 정보, 루트로 실행하기, 특권 모드, 노출된 포트 및 공유 커널이 포함됩니다.

이러한 위험을 아는 것이 컨테이너 배포 환경을 보호하는 첫 단계입니다.