21.02.23.면담.md

이미지 스캐닝

• 정적 이미지 취약점 분석

  • 통상적으로는 이미지 내의 CVE (Common Vulnerabilities Exposure) 탐색
    (- 동적 분석은 Sandbox 환경에서 컨테이너 이미지 실행 & indicators of compromise (IOC) 확인)

• Clair vs Anchroe vs Trivy

  • 큰 틀에서는 모두 같음. CVE 데이터베이스 긁어와서 쌓아놓고 레이어 .tar 까서 파일시스템 비교.
  • Ubuntu/Debian/Centos/Alpine 등등에 대한 CVE 검사는 동일
    (- Trivy의 경우 npm, pip, maven 패키지에 대한 CVE 검색도 가능)

• Clair 선택 이유? - Quay, OpenShift에서 씀, 가장 많이 쓰임 (깃헙 스타 가장 많음ㅋㅋ)

• Clair 내부 구조

  • Server-Client 구조.
  • Server는 PostgreSQL을 같이 띄우고 있어서 공개된 CVE 데이터베이스를 주기적으로 긁어와 저장.
  • 이 데이터베이스 정보에는 OS 이름, 버전, 패키지 이름, 버전, 심각도를 포함. (e.g., CVE-1은 Ubuntu Os의 16.04 버전 안의 gcc 패키지 5.1 버전에 존재하는 취약점이고 심각도는 Critical이다)
    (- 심각도는 CVSS 점수 기반으로 Critical, High, Medium, Low 등으로 나뉨)
    (- CVSS (Common Vulnerability Scoring System) 점수는 Attack Vector, Attack Complexity, Scope, ...등에 의해 결정됨)

• Clair로 이미지 스캔이 이뤄지는 과정

  • 도커 허브 같은 원격 레지스트리에 저장된 이미지를 대상으로 함
  • 일반적으로 원격 레지스트리에서 Image Pull해올 때는 맨 처음 레지스트리에서 manifest 정보를 불러옴.
  • 그 manifest 정보에는 해당 이미지의 모든 레이어 정보들을 담고 있음.
  • 각 레이어의 파일시스템을 담고 있는 .tar 파일을 다운로드 받아 압축을 풂.

  1. Client에서

     1. 이미지 Pull 과정 중 .tar 파일을 다운받기 전까지 수행함
     2. Manifest 가져와 레이어 순서대로 Clair 서버로 POST 요청. (이 요청에는 레이어 ID, 해당 레이어의 부모 레이어 ID, .tar 파일을 다운받을 수 있는 URL을 같이 넘겨줌.)

  2. Server에서

     1. 해당 레이어 파일시스템 .tar 파일을 다운받아서 extract
     2. 해당 레이어가 어떤 OS 기반인지 판단 (/etc/centos-release, /etc/redhat-release, ...등등 있는지)
     • 상위 레이어면 이런 파일이 없을텐데 그럴 경우 부모 레이어의 OS를 따라감
     3. 해당 OS의 패키지 매니저 경로에 어떤 패키지의 어떤 버전이 설치되어있는지 Feature Version 리스트를 작성, PostgreSQL에 저장. 여기까지가 POST에 대한 응답

  3. Client에서

     1. 해당 이미지의 최상위 레이어에 대한 Vulnerability GET 요청

  4. Server에서

     1. 서버쪽에서는 요청 온 레이어와 그 모든 부모 레이어의 Feature Version 리스트를 가져옴.
     2. 이 Feature Version 리스트를 CVE 데이터베이스에 저장돼있는 CVE들의 패키지 버전과 비교하면서 유효한 취약점 리스트 뽑아내 클라이언트로 응답

• Clair 적용 방법

  • CI/CD 파이프라인에 내장

    • 이미지 빌드하고 Staging 레지스트리에 푸쉬
    • Staging 레지스트리에 푸쉬된 이미지에 대한 스캔 요청
    • 스캔 검사 결과에 따라 Critical한 취약점 없으면 Production 레지스트리로 복사. 있으면 파이프라인 실패 종료
    • 이 방법의 경우 Staging 레지스트리가 필요하고, Push가 두 번 이뤄진다는 단점이 있지만, Production 레지스트리에 취약한 이미지는 존재하지 않는다는 장점 존재.

  • 레지스트리에 웹훅 걸어서 이미지 Push될 때마다 Scan 수행

    • 레지스트리에 취약한 이미지가 존재할 수 있지만, 별도의 Staging 레지스트리가 필요 없고 한 번의 푸쉬로 스캔까지 진행할 수 있다는 장점 있음.

• 신한 PoC, 하이퍼클라우드 적용

  • CI/CD 파이프라인에 통합 적용함

    • 파이프라인 순서 - S2I, Image Build, Staging 레지스트리에 Push, Scan, 성공 시 Production 레지스트리에 Push

  • CI/CD를 통하지 않고 사용자가 직접 이미지를 레지스트리에 Push할 수도 있기 때문에 사용자가 직접 Scan 요청할 수도 있도록 함

  • ImageScanRequest라는 CRD, Operator 개발 완료

    • 사용자 입장에서는 ImageScanRequest라는 리소스를 만들면서 이미지 주소만 입력해주고 해당 리소스의 상태가 Succeeded로 바뀌길 기다리면 됨!
    • 해당 리소스의 상태가 Succeeded로 바뀌면 status에 취약점 결과 요약 기재됨. Critical 몇개, Medium 몇개...
    • 자세한 결과는 HyperCloud Web Console의 해당 레지스트리 메뉴에서 확인 가능
    • ElasticSearch로 결과 전송해 Kibana에서 통합 확인도 가능

• 개선점

  • Staging 레지스트리 대체 (inline image scanning)
    • 신한 poc에는 사용자가 직접 staging 레지스트리를 만들고 스캔 요청하도록 가이드
    • 여러가지 방안 존재
      1. 중앙화된 staging 레지스트리 두고 scan
      2. (CI/CD 파이프라인 내부에서) 레지스트리 mock up해 layer .tar 파일을 해당 mock up 서버에서 가져가도록 - 단점은 클러스터 외부의 Clair 서버를 사용할 수 없음 (하려면 Service, Ingress 만들고 난리쳐야할듯)
  • Trivy 도입 검토
    • 어플리케이션 패키지도 스캔 가능...
    • Staging 레지스트리 없앨 수도 있...