쿠버네티스 파이프라인의 보안을 자동화하는 10단계

쿠버네티스 파이프라인을 대상으로 한 위협의 범위가 끊임없이 확장되면서 이제 애플리케이션 라이프사이클 전반적으로 더 통합되고 자동화된 보안이 필요하다. 빌드와 레지스트리, 테스트, 스테이징, 그리고 특히 피해가 큰 프로덕션 환경에 이르기까지 파이프라인의 어느 단계에서나 치명적인 취약점이 발생할 수 있다. 

효과적인 쿠버네티스 파이프라인 보안을 가로막는 큰 장애물 중 하나는 시간을 투자해야 한다는 점이다. 컨테이너를 사용하는 목적은 릴리스 주기의 속도를 높이고 더 최신 코드와 더 나은 기능, 더 높은 리소스 안정화를 실현하는 것이다. 이 파이프라인에 보안을 집어넣기 위해 어떤 형태로든 수작업이 개입되면 속도가 저하되고 컨테이너 전략의 이점을 제대로 누리지 못하게 될 수 있다.

데브옵스팀에게 파이프라인의 속도 저하는 용납할 수 없는 일이다. 그런 이유로 자동화는 필수적일 뿐만 아니라, 컨테이너 보안을 위한 가장 현실적인 방법이기도 하다. 
 

쿠버네티스 파이프라인 개요

간략하게 본 쿠버네티스 파이프라인과 각 단계에서의 주요 위협은 다음과 같다.
 

새로운 취약점은 이르면 빌드 단계부터 발생할 수 있다. 오픈소스 툴이 이전까지 알려지지 않은 공격 표면을 더하는 원인이 되는 경우가 많다. 레지스트리에서는 빌드 단계에서 성공적으로 취약점을 제거하고 깨끗한 이미지를 저장했더라도 이 이미지에 영향을 미치는 치명적인 취약점이 나중에 발견될 수도 있다. 프로덕션에서 실행되는 컨테이너에도 같은 상황이 발생할 수 있으며, 실제로 종종 발생한다. 프로덕션 환경에서 컨테이너, 핵심 툴 또는 쿠버네티스 자체가 공격을 받을 수 있다. 

작년에 발생했던 치명적인 API 서버 취약점이 그 사례다. 이런 인프라는 모두 자동으로 모니터링하고 보호해야 하는 공격 영역이다. 또한 취약점을 잘 제거했더라도 제로데이 공격, 알려지지 않은 취약점 또는 내부자 공격의 위험은 여전히 남아 있다. 긍정적인 점은 쿠버네티스 파이프라인 전반에서 보안 전략을 통합 및 자동화할 수 있다는 것이다.
 

컨테이너 라이프사이클을 보호하기 위한 10단계

데브옵스 팀이 쿠버네티스 파이프라인의 라이프사이클 전반에서 보안을 통합하고 자동화할 수 있는 10가지 구체적인 방법은 다음과 같다.
 

1단계. 빌드 단계 중 검사
이 단계는 간단히 자동화할 수 있으며, 취약점이나 문제가 있으면 개발자에게 빌드를 돌려보낸다. 

2단계. 레지스트리 검사
레지스트리에서 새로운 취약점이 발견되는 경우에도 경보와 함께 수정을 위해 개발팀에 돌려보낸다. 한 가지 유의해야 할 점은 취약점 수정 방안이 없어 프로덕션 배포를 허용해야 할 수도 있다는 것이다. 이 때문에 프로덕션 취약점 검사와 규정 준수 평가도 마찬가지로 중요하다.

3단계. 런타임 중에 검사, 규정 준수 검사
프로덕션의 취약점 검사는 컨테이너만 대상으로 하는 것이 아니다. 호스트와 오케스트레이터 플랫폼(쿠버네티스, 오픈시프트 등)에서도 항상 취약점을 검사해야 한다. 도커 벤치(Docker Bench)와 쿠버네티스 CIS 벤치마크는 간단히 자동으로, 지속적으로 실행할 수 있다. 새 컨테이너가 배포되거나 새 호스트가 추가되거나 패치될 때마다 알려준다. 

기업에서는 대부분 규정 준수 보고와 관리도 중요하다. 여기에는 일부 산업의 규정 준수를 위해 반드시 필요한 자동 분할(segmentation)도 포함된다. 이 부분에서는 어차피 수동 방식이 적합하지 않다. 규정 준수를 위해서는 런타임 검사와 규정 준수 확인을 자동화해야 하는 경우가 많기 때문이다. 예를 들어 결제 카드 산업의 PCI 보안 표준을 준수하려면 범위 내 및 범위 외 CDE 트래픽을 분할하고 방화벽을 적용해야 한다. 호스트에서 범위 내에 실행되는 팟(pod)을 배포하면서 수동으로 방화벽 규칙을 변경할 수는 없다. 따라서 PCI (및 다른) 규정 준수를 위해서는 자동화된 네트워크 분할이 필요하다.

4단계. 위험 보고서 실행
모든 데브옵스팀이 알고 있듯이 위험 보고서는 전체 취약점 보호 프로세스를 관리는 데 있어 매우 중요하다. 이를 자동화하면 프로세스를 훨씬 더 빠르게 해서 필요한 교정 작업의 속도를 높일 수 있다.

5단계. 보안 정책 코드화
6단계. 행동 학습 구현
코드화한 보안 정책(security policy as code)과 행동 학습은 함께 사용해야 한다. 이를 통해 데브옵스팀은 개발 프로세스의 극초기에 워크로드 보안 정책을 만들어 구축하고 프로덕션 환경까지 이어갈 수 있다. 자동화의 필수적인 요소이며, 새 애플리케이션을 보호하기 위한 규칙을 수동으로 만들 필요를 없애 준다. 수작업으로 유발되는 속도 저하도 방지한다.

구현 가능한 워크플로우는 이렇다. 데브옵스와 QA팀이 테스팅/QA 환경에 애플리케이션을 배포한다. 이 환경에는 행동 학습이 가능한 컨테이너 방화벽이 있다. 컨테이너 방화벽은 애플리케이션의 컨테이너 프로세스와 정상적인 파일 동작을 모두 학습하고 정책 규칙을 만든다. 개발팀은 이 규칙을 내보내 검토하고 필요에 따라 수정할 수 있다. 예를 들어 앱이 사용하는 프로토콜, 필요한 연결 또는 앱에서 실행되는 프로세스를 수정해야 할 수 있다. 이를 보안 대원칙으로 만들고 프로덕션 배포에 앞서 다시 테스트할 수 있다. 이와 같은 방법으로 워크플로우별 정책뿐만 아니라 “컨테이너에는 SSH가 허용되지 않음”과 같은 전역적인 보안 정책도 정의할 수 있다.

7단계. 승인 제어 설정
승인 제어를 파이프라인에 통합하는 것은 자동화된 보안을 완성하기 위한 핵심적인 단계다. 무단 배포 또는 취약한 배포가 프로덕션 환경으로 유입되지 않도록 차단하는 진입 통제 규칙을 만들 수 있는 기능을 구현해야 한다.

8단계. 컨테이너 방화벽 구축.
9단계. 컨테이너 워크로드와 호스트 보안 자동화
앞서 설명했듯이 컨테이너 방화벽을 구현, 적용해서 컨테이너 워크로드와 호스트 보안을 적용하면 파이프라인을 위한 필수적인 보호 기능을 자동화할 수 있다. 이 자동화에는 런타임에 보호를 강제할 수 있는 기능이 포함되어야 한다. 컨테이너 또는 호스트에서 무단 네트워크 연결, 프로세스 또는 파일 활동을 자동으로 차단한다. 또한 네트워크 DLP를 활용해서 컨테이너 트래픽에서 PII, 신용카드 데이터, 계좌 데이터와 기타 민감한 정보를 검사하고 암호화되지 않은 데이터 전송 시도를 차단할 수도 있다.

10단계. 경보와 포렌식 설정
마지막으로, 포렌식 기능과 경보 대응을 통합하고 자동화하는 것이 중요하다. 해킹 가능성이 있는 의심스러운 팟에서 자동화된 패킷 캡처 시작하기, 또는 컨테이너를 격리해 해당 컨테이너를 드나드는 모든 트래픽 차단하기 등이 이 단계에 해당한다. 

이를 위해서는 컨테이너에서 패킷 캡처 또는 격리가 개시되는 조건을 지정하는 정책 규칙을 설정한다. 쿠버네티스 파이프라인의 모든 단계는 철저한 보호 대책이 없으면 취약하다. 그러나 데브옵스팀이 자동화해야 하는 대상과 자동화가 중요한 이유와 자동화하는 방법을 알면 컨테이너화된 배포가 제공하는 속도를 희생할 필요가 없다.

*Gary Duan은 뉴벡터(NeuVector)의 공동 설립자이자 CTO이다.
editor@itworld.co.kr