보안 점검에서 Viya 4 환경의 PostgreSQL 바이너리에 CVE 가 걸렸다는 보고가 나온다. 스캔 결과의 경로를 보면 대개 컨테이너 런타임의 오버레이 파일시스템이다.
/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/.../usr/bin/postgres
/var/lib/docker/overlay2/.../usr/pgsql-16/bin/postgres
즉 Kubernetes 노드의 파일시스템에 저장된 이미지 레이어를 직접 스캔한 결과다.
노드 파일시스템에는 다음이 함께 남아 있다.
따라서 노드 스캔 결과가 곧 실행 중인 컨테이너의 취약점이라고 단정할 수 없다. 실제 실행 이미지의 출처는 레지스트리이므로 미러 레지스트리의 이미지를 기준으로 스캔하는 것이 정확하다.
SAS 공식 레지스트리 -> 이미지 전달 -> 사내 미러 레지스트리 -> Kubernetes pull -> 노드 파일시스템
미러 레지스트리에 한 릴리스의 이미지 세트만 올려 두고 그 서버를 SAS 전용으로 쓰는 폐쇄망이라면, 노드 스캔 결과와 레지스트리 스캔 결과가 사실상 같다. 이 경우 "노드 스캔은 부정확하다" 는 논리만으로는 고객을 설득할 수 없다.
그래도 스캔 기준을 레지스트리로 옮기는 것은 의미가 있다. 옛 레이어가 남아 있을 가능성을 배제하고, 이후 업그레이드 때 동일한 기준으로 비교할 수 있기 때문이다.
취약점 등급과 실제 노출 가능성은 다른 문제다. Viya 의 PostgreSQL 은 사용자 접속용 데이터베이스가 아니라 플랫폼 내부 메타데이터 저장소이고, 일반적으로 클러스터 내부 서비스로만 노출된다.
클라이언트 -> SAS 서비스 -> 내부 서비스 -> PostgreSQL
외부에서 직접 도달하는 경로가 없다는 점, 해당 바이너리가 컨테이너 이미지 안에 포함된 것이라는 점을 함께 적어야 고객이 위험도를 평가할 수 있다. 다만 이것은 완화 요인이지 취약점이 없다는 뜻은 아니다.
컨테이너 이미지 안의 패키지는 개별 패치로 고칠 수 없다. SAS 가 수정된 패키지를 포함한 새 이미지를 릴리스해야 한다.
1) 미러 레지스트리 이미지를 기준으로 다시 스캔한다
2) 해당 CVE 가 수정된 릴리스를 확인한다
3) 그 릴리스로 업그레이드한다
어느 릴리스에서 수정됐는지는 해당 CVE 번호로 SAS 보안 공지를 확인한다 (확인 필요).
논리를 순서대로 제시하지 않으면 "업그레이드하면 된다" 만 남고 나머지가 전달되지 않는다.
The vulnerability was detected from the Kubernetes node filesystem image snapshot.
Scanning the node filesystem does not necessarily represent the vulnerabilities in the
running container images, because the node may contain cached or unused image layers.
To determine whether the vulnerability exists in this environment, the container images
stored in the mirror registry should be scanned.
If it is confirmed there, upgrading to the release where the CVE is fixed resolves it.