Azure Container Registry의 연속 패치 기능은 컨테이너 이미지에서 운영 체제(OS) 수준 취약성의 검색 및 수정을 자동화합니다. Trivy를 사용하여 정기적인 검사를 예약하고 Copa를 사용하여 보안 수정을 적용하면 소스 코드 또는 빌드 파이프라인에 액세스할 필요 없이 레지스트리에서 안전하고 up-to날짜 이미지를 유지할 수 있습니다. ACR(Azure Container Registry) 환경을 안전하고 규정을 준수하도록 일정 및 대상 이미지를 자유롭게 사용자 지정
사용 사례
다음은 연속 패치를 사용하는 몇 가지 시나리오입니다.
- 컨테이너 보안 및 위생 적용: 연속 패치를 사용하면 사용자가 업스트림에서 완전히 다시 빌드할 필요 없이 OS 컨테이너 CVE(일반적인 취약성 및 노출)를 신속하게 수정할 수 있습니다.
- 사용 속도: 연속 패치는 패키지를 자동으로 업데이트하여 특정 이미지에 대한 업스트림 업데이트에 대한 종속성을 제거합니다. 취약성은 매일 나타날 수 있지만 인기 있는 이미지 게시자는 한 달에 한 번만 새 릴리스를 제공할 수 있습니다. 연속 패치를 사용하면 최신 OS 취약성 집합이 검색되는 즉시 레지스트리 내의 컨테이너 이미지가 패치되도록 할 수 있습니다.
가격 책정
연속 패치는 소비 기반 모델에 따라 작동합니다. 각 패치는 작업 실행당 $0.0001/초의 기본 ACR 작업 요금에 따라 청구되는 컴퓨팅 리소스를 활용합니다. 자세한 내용은 ACR 가격 책정 페이지에서 확인할 수 있습니다.
미리 보기 제한 사항
연속 패치는 현재 공개 미리 보기로 제공됩니다. 다음과 같은 제한 사항이 적용됩니다.
- Windows 기반 컨테이너 이미지는 지원되지 않습니다.
- 시스템 패키지에서 발생하는 "OS 수준" 취약성만 패치됩니다. 여기에는 "apt" 및 "yum"과 같은 OS 패키지 관리자가 관리하는 컨테이너 이미지의 시스템 패키지가 포함됩니다. Go, Python 및 NodeJS와 같은 프로그래밍 언어에서 사용되는 패키지와 같은 애플리케이션 패키지에서 발생하는 취약성은 패치할 수 없습니다.
- EOSL(서비스 수명 종료) 이미지는 연속 패치에서 지원되지 않습니다. EOSL 이미지는 기본 운영 체제가 더 이상 업데이트, 보안 패치 및 기술 지원을 제공하지 않는 이미지를 나타냅니다. 예를 들어 Debian 8 및 Fedora 28과 같은 이전 운영 체제 버전을 기반으로 하는 이미지가 있습니다. EOSL 이미지는 취약성이 있음에도 불구하고 패치에서 건너뛰습니다. 권장되는 방법은 이미지의 기본 운영 체제를 지원되는 버전으로 업그레이드하는 것입니다.
- 다중 아치 이미지는 지원되지 않습니다.
- 연속 패치를 위해 100 이미지 제한이 적용됩니다.
- 연속 패치는 ABAC(특성 기반 액세스 제어) 사용 레지스트리와 호환되지 않으며 PTC(캐시를 통해 끌어오기) 규칙이 설정된 리포지토리와 호환되지 않습니다.
- 무료 평가판 계정에 ACR 작업 액세스 권한이 없기 때문에 무료 크레딧을 사용하는 "평가판"의 Azure 구독은 지원 되지 않습니다 .
주요 개념
ACR의 연속 패치는 패치당 새 이미지를 만들기 때문에 ACR은 태그 규칙을 사용하여 패치된 이미지를 버전화하고 식별합니다. 두 가지 주요 방식은 점진적 및 유동적입니다.
점진적 태그 지정
작동 방식:
새 패치마다 원래 태그의 숫자 접미사(예: -1등 -2)가 증가합니다. 예를 들어, 기본 이미지가 python:3.11일 경우, 첫 번째 패치는 python:3.11-1를 생성하며, 같은 기본 태그에 대한 두 번째 패치는 python:3.11-2을 생성합니다.
특수 접미사 규칙:
-
-1to-999: 패치 태그로 간주됩니다. -
-xwherex > 999: 패치 태그로 해석되지 않고, 대신 전체 접미사가 원래 태그의 일부로 처리됩니다. (예:ubuntu:jammy-20240530패치된 태그가 아닌 원래 태그로 간주됩니다.) 즉, 실수로 끝나는-1새 태그를-999푸시하면 연속 패치가 패치된 이미지처럼 처리됩니다.-1부터-999까지의 접미사를 사용하여 패치하려는 태그를 푸시하지 않는 것을 권장합니다.-999버전의 패치된 이미지에 문제가 생기면, 연속 패치가 오류를 반환하게 됩니다.
부동 태그 지정
작동 방식:
변경 가능한 단일 태그 -patched는 항상 최신 패치 버전의 이미지를 참조합니다. 예를 들어 기존 이미지 태그가 python:3.11이면, 첫 번째 패치가 python:3.11-patched을(를) 생성합니다. 각 후속 패치를 사용하면 태그가 -patched 가장 최근에 패치된 버전을 가리키도록 자동으로 업데이트됩니다.
어떤 것을 사용해야 하나요?
증분(기본값): 각 새 패치가 고유 태그로 명확하게 식별되므로 감사 가능성 및 롤백이 중요한 환경에 적합합니다.
부동: CI/CD 파이프라인에 대한 최신 패치에 대한 단일 포인터를 선호하는 경우에 이상적입니다. 패치당 다운스트림 애플리케이션에서 참조를 업데이트할 필요가 없도록 하여 복잡성을 줄이지만 엄격한 버전 관리를 희생하여 롤백하기가 어렵습니다.