운영용 컨테이너 스캐닝

Tier: Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated

지원되는 아키텍처

GitLab Kubernetes 에이전트 v16.10.0부터 GitLab 에이전트 Helm 차트 버전 v1.25.0으로 운영용 컨테이너 스캐닝 (OCS)은 linux/arm64linux/amd64을 지원합니다. 이전 버전에서는 linux/amd64만 지원됩니다.

운영용 컨테이너 스캐닝 활성화

클러스터 내 컨테이너 이미지를 보안 취약점을 스캔하기 위해 OCS를 사용할 수 있습니다. GitLab 에이전트 릴리스 16.9부터 OCS는 취약점을 스캔하기 위해 Trivy를 둘러싼 래퍼 이미지를 사용합니다. GitLab 16.9 이전에는 OCS가 직접 Trivy 이미지를 사용했습니다.

OCS는 에이전트 구성 또는 프로젝트의 스캔 실행 정책을 사용하여 주기적으로 실행하도록 구성할 수 있습니다.

note
에이전트 구성스캔 실행 정책의 둘 다 구성된 경우 스캔 실행 정책의 구성이 우선합니다.

에이전트 구성을 통한 활성화

에이전트 구성에 container_scanning 구성 블록을 추가하여 Kubernetes 클러스터 내 이미지를 스캔하도록 구성합니다. cadence 필드에는 스캔이 실행되는 CRON 표현식이 포함되어야 합니다.

container_scanning:
  cadence: '0 0 * * *' # 매일 00:00에 실행 (Kubernetes 클러스터 시간)

cadence 필드는 필수입니다. GitLab은 cadence 필드에 대해 다음 유형의 CRON 구문을 지원합니다.

  • 매 시간 특정 시간마다 매일 실행되는 유형, 예시: 0 18 * * *
  • 매주 특정 요일과 시간에 매주 한 번 실행되는 유형, 예시: 0 13 * * 0
note
cron 의존성을 지원하는 경우 cadence 필드에서 CRON 구문의 다른 요소는 작동할 수 있지만, GitLab은 해당 기능에 대해 공식적으로 테스트하거나 지원하지 않습니다.
note
CRON 표현식은 Kubernetes-에이전트 pod의 시스템 시간을 사용하여 UTC에서 평가됩니다.

운영용 컨테이너 스캐닝은 기본적으로 어떠한 워크로드에 대한 취약점을 스캔하지 않습니다. vulnerability_report 블록을 설정하여 namespaces 필드를 사용하여 스캔할 네임스페이스를 선택할 수 있습니다. 예를 들어, default, kube-system 네임스페이스만 스캔하려면 다음과 같이 구성할 수 있습니다.

container_scanning:
  cadence: '0 0 * * *'
  vulnerability_report:
    namespaces:
      - default
      - kube-system

대상 네임스페이스마다 다음의 워크로드 리소스 내의 모든 이미지가 스캔됩니다:

  • Pod
  • ReplicaSet
  • ReplicationController
  • StatefulSet
  • DaemonSet
  • CronJob
  • Job

스캔 실행 정책을 통한 활성화

스캔 실행 정책을 사용하여 Kubernetes 클러스터 내 모든 이미지를 스캔하도록 활성화하려면 스캔 실행 정책 편집기를 사용합니다. 새로운 스케줄 규칙을 생성할 수 있습니다.

note
실행 중인 컨테이너 이미지를 스캔하려면 Kubernetes 에이전트가 클러스터에서 실행 중이어야 합니다.

다음은 Kubernetes 에이전트가 연결된 클러스터 내에서 운영용 컨테이너 스캐닝을 가능하게 하는 정책의 예시입니다:

- name: default 및 kube-system 네임스페이스를 통해 연결된 클러스터에서 운영용 컨테이너 스캐닝 강제 적용
  enabled: true
  rules:
  - type: schedule
    cadence: '0 10 * * *'
    agents:
      <agent-name>:
        namespaces:
        - 'default'
        - 'kube-system'
  actions:
  - scan: container_scanning

스케줄 규칙의 키는 다음과 같습니다:

  • cadence (필수): 스캔이 실행되는 CRON 표현식
  • agents:<agent-name> (필수): 스캔에 사용할 에이전트 이름
  • agents:<agent-name>:namespaces (선택적): 스캔할 Kubernetes 네임스페이스. 생략하면 모든 네임스페이스가 스캔됩니다.
note
cron 의존성을 지원하는 경우 cadence 필드에서 CRON 구문의 다른 요소는 작동할 수 있지만, GitLab은 해당 기능에 대해 공식적으로 테스트하거나 지원하지 않습니다.
note
CRON 표현식은 Kubernetes-에이전트 pod의 시스템 시간을 사용하여 UTC에서 평가됩니다.

스캔 실행 정책 설명서에서 전체 스키마를 확인할 수 있습니다.

스캐너 리소스 요구 사항 구성

기본적으로 스캐너 pod의 기본 리소스 요구 사항은 다음과 같습니다:

requests:
  cpu: 100m
  memory: 100Mi
limits:
  cpu: 500m
  memory: 500Mi

resource_requirements 필드로 사용자 정의할 수 있습니다.

container_scanning:
  resource_requirements:
    requests:
      cpu: '0.2'
      memory: 200Mi
    limits:
      cpu: '0.7'
      memory: 700Mi

CPU에 대한 분수 값을 사용할 때는 값을 문자열 형식으로 지정해야 합니다.

note
리소스 요구 사항은 에이전트 구성을 사용하여만 설정할 수 있습니다. 운영용 컨테이너 스캐닝스캔 실행 정책을 통해 활성화한 경우 리소스 요구 사항을 에이전트 구성 파일 내에서 정의해야 합니다.

클러스터 취약점 보기

GitLab에서 취약점 정보를 보려면:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 에이전트 구성 파일을 포함하는 프로젝트를 찾습니다.
  2. 운영 > 쿠버네티스 클러스터를 선택합니다.
  3. 에이전트 탭을 선택합니다.
  4. 취약점을 보려면 에이전트를 선택합니다.

클러스터 에이전트 보안 탭 UI

이 정보는 또한 운영상 취약점에서 찾을 수 있습니다.

note
적어도 개발자 역할이 있어야 합니다.

개인 이미지 스캔

개인 이미지를 스캔하려면, 스캐너는 이미지를 끌어오기 위해 이미지 풀 시크릿(직접 참조 및 서비스 계정에서)에 의존합니다.

제한 사항

GitLab Agent 16.9부터 운영 컨테이너 스캔:

  • 최대 100MB의 Trivy 보고서를 처리합니다. 이전 릴리스의 경우 이 제한은 10MB입니다.
  • GitLab Agent가 fips 모드에서 실행될 때 비활성화됩니다.

문제 해결

Trivy 스캔 실행 중 오류. 컨테이너 종료 사유: OOMKilled

너무 많은 리소스를 스캔해야 하거나 스캔 중인 이미지가 큰 경우 OCS가 OOM 오류로 실패할 수 있습니다. 이를 해결하려면 스캐너 리소스 요구 사항 구성하여 사용 가능한 메모리 양을 늘리십시오.