컨테이너 보안 기본 사항: 작업량

이 시리즈를 처음 접하는 분이라면 처음부터 시작해 보세요. 
컨테이너 보안 기본 사항: 소개
컨테이너 보안 기본 사항: 관로
컨테이너 보안 기본 사항: 관현악법

워크로드는 애플리케이션을 설명하는 데 자주 사용되는 비교적 최근의 용어이지만 인프라 서비스를 지칭하기도 합니다. 이는 개발자가 반드시 수행하지 않는 다양한 '작업 부하'가 컨테이너 클러스터에서 실행될 수 있기 때문에 중요합니다. 컨테이너 환경 내에서 다양한 목적을 위해 무료 및 오픈 소스 서비스를 사용하는 경우가 늘어나고 있습니다. 실제로 이는 IT 운영 전반에 해당하는데, 이는 지난해 무료 및 오픈 소스 소프트웨어 다운로드에서 가장 많이 사용된 범주였습니다.

따라서 워크로드 보안이란 컨테이너 환경에 다운로드, 개발 또는 배포한 모든 소프트웨어를 의미합니다. 영사를 생각해 보세요. 쿠버네티스 자체에 대해 생각해 보세요. Prometheus 와 Elasticsearch를 생각해 보세요. NGINX 와 istio에 대해 생각해 보세요.

그리고 Kubernetes 환경을 지원하기 위해 배포한 모든 API 게이트웨이, 캐시 및 인그레스 컨트롤러도 해당 목록에 추가합니다. 여기서 철저한 자재 목록이 중요한 이유와, 안전한 환경을 유지하기 위해 정기적으로 재고를 파악하는 것이 중요한 이유입니다.

목록을 작성했다면 이제 주요 워크로드 보안 문제를 해결할 차례입니다.

• 1. 인증은 선택 사항이 아닙니다
  이 시리즈를 처음부터 끝까지 따라오셨다면 이미 익숙한 내용일 겁니다. 컨테이너 보안의 모든 측면에서 공통적으로 언급되는 주제 중 하나는 '앞문을 잠그세요'입니다.
  
  이러한 모든 서비스는 클러스터에서 워크로드로 실행됩니다. 이는 종종 API 및 데이터에 액세스하기 위한 기본 자격 증명 또는 "개방형" 초기 구성을 의미합니다. 워크로드 보안에는 애플리케이션 기능 과 운영 에 필요한 모든 구성 요소, 소프트웨어 및 애플리케이션 서비스가 포함됩니다. 
  
  

• 2. 악성 콘텐츠는 악성입니다
  자격 증명을 요구하고 접근 제어를 적용하여 문을 잠근 후에도 여전히 악성 콘텐츠에 대해 걱정해야 합니다. 이는 사용 중인 애플리케이션, 마이크로서비스, 운영 서비스에도 해당됩니다. 사용자(운영자든 소비자든)에게 인터페이스를 제공하는 모든 업무는 잠재적으로 위험에 노출되어 있습니다.

  여기서는 스캐닝과 연기가 필수입니다. HTTP나 애플리케이션 로직 등 애플리케이션 계층의 취약점을 찾는 것이 첫 번째 단계입니다. 문제를 찾았다면 이제 문제를 해결하기 위한 조치를 취해야 할 때입니다. 맞춤형 앱인 경우 개발팀으로 다시 보내세요. 타사 구성 요소인 경우 패치/업그레이드 버전이 있는지 확인하세요. 타사 구성 요소는 종종 컨테이너 이미지로 제공되며, Snyk가 2019년 오픈 소스 보안 상태 보고서에서 언급한 대로 그 중 44%는 알려진 취약점을 가지고 있으며 이에 대한 보다 새롭고 안전한 기본 이미지를 사용할 수 있습니다.
  
  다시 한번 말씀드리자면, 조치를 취하지 않고 검사를 실행하면 보안이 향상되는 데 아무런 도움이 되지 않습니다.
  
  벽에 구멍이 있어서 도둑이 잠긴 문을 쉽게 뚫을 수 있다면 그 구멍을 패치하면 됩니다. 그러니 가상 벽에 있는 가상 구멍을 패치하세요.
  
  웹 애플리케이션 방화벽이나 API 보안 게이트웨이를 사용하면 개발자가 취약점을 즉시 해결할 수 없거나 타사 공급자가 아직 해결하지 못한 경우 취약점을 수정할 수 있는 수단을 제공할 수 있습니다.
  
  이는 "통화를 검토한다"는 말로 요약할 수 있는데, 이는 모든 작업 부하에 대한 요청을 수락하기 전에 검사하고 평가하는 것을 의미합니다.
  
  
• 3. 공유 자원은 공유 위험을 의미합니다
  기존 가상화와 마찬가지로 컨테이너는 완전히 격리되어 있지 않습니다. 컨테이너는 궁극적으로 동일한 물리적 OS를 공유합니다. 즉, 공유 OS의 취약점은 공유 취약점을 뜻합니다.

공격자가 OS 구성 요소의 취약점을 악용하면 하나 이상의 작업 부하를 손상시킬 수 있습니다. 이러한 취약점은 '문 잠금'이나 '통화 차단'에 실패하면 노출될 수 있습니다. CVE-2019-5736 에서 보았듯이 OS 계층의 runc 취약점으로 인해 인터넷이 패닉에 빠졌던 것처럼 이는 터무니없는 시나리오가 아닙니다. 

여기서 핵심 보안 원칙은 SELinux 및 RedHat 컨테이너 보안 전문가인 Dan Walsh가 다음과 같이 유명하게 언급했습니다 . "컨테이너는 포함하지 않습니다." 

노드 외부의 서비스 및 사용자와의 모든 네트워크 트래픽은 호스트 OS를 통과해야 한다는 점을 기억하는 것이 중요합니다. 노드 상의 포드와 컨테이너 간의 네트워킹은 가상 브릿지를 이용한 가상 네트워킹과 iptables의 뛰어난 사용을 통해 달성됩니다. 하지만 궁극적으로 트래픽은 해당 물리적 노드를 떠나야 하며, 이는 호스트 OS에서 처리된다는 것을 의미합니다. 에이전트, 플러그인 및 기타 데몬은 보안 또는 가시성 목적으로 해당 트래픽을 관찰하거나 캡처할 수 있습니다. 파이프라인 보안 에 대해 읽은 후 수집하기 시작한 목록에 추가해야 할 잠재적인 침해 지점은 다음과 같습니다.

• 4. 민감한 세부 정보 로깅
  컨테이너 보안에 대한 논의에 로그에 대한 경고가 포함될 것이라고는 예상하지 못했을 수도 있습니다. 하지만 그럴 수도 있는데, 그 이유는 때로 민감한 정보가 로그 파일에 저장되기 때문입니다. 인증 토큰, 암호화 공급자 키, 자격 증명. 모든 것은 실수로 stderr 에 작업 부하로 인해 기록되거나 표시될 수 있습니다. 이는 인증 오류로 인해 문제를 추적해야 하기 때문에 발생하는 경우가 많습니다. 일반적으로 시스템에 비밀이 기록되는 것을 막고, 가능하다면 허용하지 않는 것이 좋습니다.
  
  개발자가 이러한 위험을 인식하도록 돕기 위해 로깅 설계 가이드를 제공하고 로그에 기록하는 것이 허용되는 사항과 허용되지 않는 사항을 지정하는 것을 고려하세요.

컨테이너 컨텍스트에서 워크로드 보안의 대부분은 프로덕션 환경에서 실행되는 다른 애플리케이션 워크로드의 보안과 동일합니다. 액세스를 제어하고 강력한 인증을 요구하며, 악성 콘텐츠를 감시하고 공유 및 플랫폼 수준의 취약성을 인식하세요.