Offcanvas
Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.
Offcanvas
1111Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.
클라우드

쿠버네티스 SW 공급망 보안을 강화하는 방법

Simon Bisson | InfoWorld 2021.12.21
현대 소프트웨어 개발 방식의 확산으로 소프트웨어 공급망을 보호하는 것이 예전보다 훨씬 더 중요해졌다. 코드는 오픈소스 라이브러리에 종속성이 있고 오픈소스 라이브러리는 다른 라이브러리에 종속성이 있고, 이런 식으로 계속 이어진다. 자신이 개발하지 않았고 컴파일하지 않았으며 대부분의 경우 출처도 알 수 없는 코드가 사슬처럼 엮여 있다.
 
ⓒ Getty Images Bank

이 코드 중에는 거의 모든 곳에 사용되는 코드도 있다. 업계를 발칵 뒤집어 놓은 로그포셸(Log4Shell) 익스플로잇은 흔히 사용되는 자바 로깅 구성요소인 로그포제이(log4j)에 있는 오래된 버그를 기반으로 한다. 결국 지금 업계는 거인의 어깨 위가 아니라, 소수의 애플리케이션 및 구성요소 유지관리자의 어깨 위에 올라가 있다. 전 세계 인프라가 이들이 한가한 시간에 선의로 하는 일에 의존해 굴러간다.
 

분산 개발로 위험 가중

유지관리자의 일을 깎아내리는 것이 아니다. 이들은 현대 소프트웨어 공급망의 필수적인 요소다. 소소한 모듈부터 전체 컨테이너 기반 플랫폼까지 모든 것을 제공한다. 이렇게 중요한 코드를 만들지만 그에 상응하는 인정도, 보상도 받지 못한다. 안타깝게도 지금까지 악의적 행위자가 유지관리 코드를 넘겨받아 악성코드를 추가한 사례가 여러 번 있었다. 오래 신뢰를 받아온 코드이므로, 설치할 가능성이 높다고 공격자가 판단했기 때문이다.

코드가 그룹 작업의 결과물이 되는 경우가 증가하고 있으므로 이와 같은 공격은 앞으로 더 늘어날 것이다. 이제 우리 스스로와 애플리케이션을 보호하려면 어떻게 해야 할까? 무엇보다 소프트웨어 공급망이 실제로 존재한다는 것, 그리고 코드가 서로 격리된 채 개발되던 시절이 오래전에 끝났다는 것을 이해해야 한다. 오픈소스와 서드파티 라이브러리는 현재 소프트웨어를 만드는 과정에서 필수적이며 그 중요성은 갈수록 더 커질 것이다.

소프트웨어 공급망을 보호하기 위해 취할 수 있는 조치는 무엇일까? 코드에서 라이브러리 스캔하기, 정적 및 동적 분석 사용하기, 코드에 디지털 서명 및 해시 추가하기, 모든 요소를 관리형 리포지토리에 집어넣기 등 그동안 소프트웨어 명세서 관리 툴을 제공하려는 큰 노력이 이어졌다. 그러나 이 그림에는 한 가지 요소가 빠졌다. 그 작업과 우리가 사용하는 코드를 어떻게 검증할 것인지다. 보안 분야의 오랜 격언인 “신뢰하되 검증하라”는 여전히 유효하다.
 

소프트웨어 공급망 보호하기

사용하는 코드를 신뢰해야 하지만 코드의 신뢰성을 검증해야 할 필요성도 있다. 또한 검증할 수 있는 시간도 제한된다. 리포지토리의 코드가 변경되면 클라우드 네이티브 코드도 새 빌드로 바뀌기 때문이다. 여기서 핵심은 현대적 개발이 가진 자동화 특성이다. 깃허브와 같은 플랫폼이 소프트웨어 라이프사이클의 중심에 위치하면서 지속적 통합과 지속적 제공(CI/CD)이 일상화됐다.

또한 마이크로서비스 아키텍처와 컨테이너 등 ‘이리저리 끼워 맞추는’ 방식으로 설계된 쿠버네티스와 같은 기술을 사용할 경우 상황은 더 복잡해진다. 코드는 격리된 컨테이너에서 실행될 수 있지만 중첩된 추상화된 유저랜드(userland)에서 실행되고, 각 도커파일(dockerfile)이 일련의 종속성을 수집하며, 그러한 종속성의 상당수는 제대로 문서화되지 않았기 때문이다. 그렇다면 우리가 사용하는 컨테이너의 명세서를 어떻게 신뢰할 수 있을까?
 

래티파이: 아티팩트 검증 워크플로우

마이크로소프트의 클라우드 네이티브 오픈소스팀은 이 문제에 도움이 될 새로운 사양을 개발하고 있다. 래티파이(Ratify)는 쿠버네티스 애플리케이션에 모인 다양한 아티팩트를 지원하는 검증 프레임워크다. 신뢰성이 확인된 보안 메타데이터 집합과 서명된 명세서를 사용해 현재 배포하는 모든 요소가 원래 의도한 요소가 맞는지를 확인한다.

이미지 및 기타 구성요소는 노터리(Notary) V2 서명 및 검증 툴ORAS(OCI Registry As Storage) 아티팩트 사양을 활용한다. ORAS는 오픈 컨테이너 이니셔티브(Open Container Initiative) 레지스트리 정의의 일부로, 컨테이너뿐만 아니라 모든 저장으로 이 정의를 확장 적용한다. 소프트웨어 명세서를 작성하는 수단으로 효과적이다. 흥미로운 부분은 빈들(Bindle) 분산 애플리케이션 설치 관리자 정의와 ORAS 매니페스트 간에는 공통적인 부분이 있어서 SBOM에서 검증된 분산 애플리케이션 설치 관리자로 간단히 건너갈 수 있다는 점이다. 이 둘은 쿠버네티스 클러스터 내에서 검증 체계의 일부로 사용 가능한 공급망 그래프를 제공한다.

래티파이는 이들 개념을 하나로 묶고 소프트웨어 명세서에 정책을 적용하기 위한 워크플로우 엔진을 추가해 코드 및 코드의 종속성 전반에서 여러 다양한 공급망을 검증한다. 래티파이의 중심은 컨테이너 이미지 전반의 정책 워크플로우를 관리하는 코디네이터다. 래티파이는 확장 가능하므로 퍼블릭/프라이빗 레지스트리에서 작동하며, 쿠버네티스에 사용되는 것과 비슷한, 익숙한 플러그인 모델을 사용한다.
 

정책 기반 승인

래티파이에 사용되는 정책 모델은 친숙한 툴을 기반으로 한다. 자체 구성을 사용하는 기본적인 정책은 물론 오픈 폴리시 에이전트(Open Policy Agent)를 사용해 작성된 더 복잡한 정책도 빠르게 실행할 수 있다. 또한 애플리케이션 개발 라이프 사이클의 다양한 지점에서 작동하면서 CI/CD 시스템에 연결돼 빌드 시점에 아티팩트를 검증하고 쿠버네티스에 연결돼 빌드와 실행 사이에 코드가 변경되지 않았음을 확인한다. 이런 방식으로 검증 모드가 스택 전반에서 작동하면서 빌드, 리포지토리와 레지스트리, 그리고 런타임 코드에서 발생할 수 있는 공급망 공격을 피하는 것이 중요하다.

핵심은 하나의 툴로 소프트웨어 라이프 사이클 전반의 검증을 처리하는 것이다. 그렇게 하면 정책을 한 번만 쓰면 된다. 다양한 시나리오마다 다른 툴을 사용할 경우 정책을 옮겨 작성하거나 변환할 때 오류가 발생할 위험이 더 커진다. 하나의 툴과 하나의 정책 형식을 사용하면 이 위험을 피하는 데 도움이 된다. 또한 코드를 제공하기 전에 '만약의 경우(what if)'를 조사하는 데 유용한 외부 정책 테스트 툴도 사용할 수 있다.
 

래티파이 정책 만들기

래티파이팀의 깃허브 리포지토리를 보면 쿠버네티스에서 게이트키퍼(Gatekeeper)와 함께 래티파이를 사용하는 방법을 보여주는 데모 코드가 있다. 래티파이는 헬름(Helm) 차트를 사용해 설치되며 몇 가지 샘플 구성 템플릿도 제공한다. 이 템플릿을 사용하면 예를 들어 서명이 없는 모든 이미지를 차단하는 등의 래티파이 작업을 테스트할 수 있다. 이 경우 게이트키퍼는 서명되지 않은 모든 컨테이너 이미지를 거부하고 실행을 차단한다.

정책 파일은 YAML로 작성되므로 비주얼 스튜디오 코드 또는 기타 툴에서 코드 서식 툴을 활용해 편집할 수 있다. 정책 파일로 간단한 규칙 엔진을 만들어 아티팩트를 단계별로 검증할 수 있다. 출처가 승인된 레지스트리인가? 다양한 서명에 대해 두 번 이상 아티팩트를 검사하고 있는가? 자체 비공개 레지스트리의 아티팩트를 공개 레지스트리의 아티팩트보다 더 신뢰하는가? 여러 번의 검사에서 모든 검증 엔진이 같은 결과를 산출하는가? 런타임 검증을 위한 규칙을 정의하기는 매우 간단하지만, 온갖 신뢰 루트의 서명이 있는 많은 아티팩트의 상태를 확인해야 하는 CI/CD 시스템에서 실행되는 규칙은 간단하지 않을 가능성이 높다.

현재의 래티파이는 소프트웨어 명세서의 모든 요소를 관리할 수 있는 툴 모음을 위한 흥미로운 초기 제안이다. 장기간 발견되지 않은 버그에 제로데이가 영향을 미치는 경우를 차단할 수는 없지만 어떤 코드가 영향을 받았는지를 신속하게 확인해 그 코드의 사용 및 실행을 차단하는 규칙을 만들 수 있다.

공급망 위험이 부각되는 상황에서 업계가 이와 같은 제안에 관심을 기울이고 공개 영역에서 이를 다루는 것이 중요하다. 마이크로소프트가 클라우드 네이티브 컴퓨팅 재단(Cloud Native Computing Foundation)과 전격적으로 래티파이를 공유한 것은 바람직한 선택이다. 덕분에 래티파이는 래티파이를 필요로 하는 더 넓은 쿠버네티스 개발 커뮤니티로부터 엄격한 심사를 받게 될 것이다. editor@itworld.co.kr
 Tags 쿠버네티스 보안
Sponsored

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2022 International Data Group. All rights reserved.