- 지원되는 아키텍처
- 운영 컨테이너 스캐닝 활성화
- OCS 취약점 해결을 위한 다중 클러스터 구성
- 스캐너 리소스 요구 사항 구성
- Trivy K8s Wrapper의 사용자 지정 저장소
- 클러스터 취약점 보기
- 개인 이미지 스캔
- 제한 사항
- 문제 해결
운영 컨테이너 스캐닝
상세 정보: Tier: Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated
- 이미 사용되지 않는 버전의 starboard 지시문은 15.4에서 사용이 중단되었습니다. starboard 지시문은 16.0에서 제거 예정입니다.
지원되는 아키텍처
GitLab 쿠버네티스 에이전트 16.10.0 및 이후 버전 및 GitLab 에이전트 Helm 차트 1.25.0 및 이후 버전에서는 운영 컨테이너 스캐닝 (OCS)이 linux/arm64
및 linux/amd64
를 지원합니다. 이전 버전의 경우, linux/amd64
만 지원됩니다.
운영 컨테이너 스캐닝 활성화
클러스터 내 컨테이너 이미지를 보안 취약점으로 스캔하는 데 OCS를 사용할 수 있습니다. GitLab 에이전트 16.9 및 이후 버전에서 OCS는 보안 취약점을 스캔하기 위해 Trivy를 둘러싼 래퍼 이미지를 사용합니다. GitLab 16.9 이전에는 OCS가 직접 Trivy 이미지를 사용했습니다.
OCS는 에이전트 구성
또는 프로젝트의 스캔 실행 정책을 사용하여 주기적으로 실행되도록 구성할 수 있습니다.
에이전트 구성
및 스캔 실행 정책
이 모두 구성된 경우 스캔 실행 정책
에서 구성이 우선됩니다.에이전트 구성을 통한 활성화
에이전트 구성에 cadence
필드를 추가하여 클러스터 내 이미지 스캔을 가능하게 하려면 container_scanning
구성 블록을 추가합니다. 여기에는 스캔이 실행되는 CRON 식을 포함하는 cadence
필드가 있어야 합니다.
container_scanning:
cadence: '0 0 * * *' # 매일 00:00에 실행 (쿠버네티스 클러스터 시간)
cadence
필드가 필요합니다. GitLab은 다음 유형의 CRON 구문을 지원합니다.
- 매 시간 특정 시간마다 일일 cadence, 예를 들어:
0 18 * * *
- 매주 특정 요일과 시간별로 1주일 cadence, 예를 들어:
0 13 * * 0
cadence
필드에서 지원될 수 있지만, GitLab이 공식적으로 테스트 또는 지원하지는 않습니다.기본적으로 운영 컨테이너 스캐닝은 취약점을 스캔하지 않습니다.
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 에이전트가 연결된 클러스터에서 운영 중인 컨테이너 스캐닝을 가능하게 하는 정책 예시가 있습니다:
- name: 기본 및 kube-system 네임스페이스를 통해 연결된 my-gitlab-agent 클러스터에서 컨테이너 스캐닝 강제
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
(선택적): 스캔할 쿠버네티스 네임스페이스. 입력하지 않으면 모든 네임스페이스가 스캔됩니다.
cadence
필드에서 지원될 수 있지만, GitLab이 공식적으로 테스트 또는 지원하지는 않습니다.스캔 실행 정책 문서 내에서 완전한 스키마를 확인할 수 있습니다 스캔 실행 정책 문서.
OCS 취약점 해결을 위한 다중 클러스터 구성
OCS의 정확한 취약점 추적을 위해 각 클러스터마다 OCS를 활성화한 별도의 GitLab 프로젝트를 생성해야 합니다. 여러 클러스터가 있다면 각 클러스터에 대해 프로젝트를 사용해야 합니다.
OCS는 현재의 스캔 취약점과 이전에 감지된 취약점을 비교하여 스캔 후 클러스터에서 더 이상 발견되지 않는 취약점을 해결합니다. 동일 프로젝트에서 여러 클러스터를 구성하면 (예: 프로젝트 A의 취약점을 해결하는 OCS 스캔으로 인해 프로젝트 B의 이전에 발견된 취약점이 해결되는 경우) 부정확한 취약점 보고가 발생할 수 있습니다.
스캐너 리소스 요구 사항 구성
기본적으로 스캐너 파드의 기본 리소스 요구 사항은 다음과 같습니다:
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에 대한 분수 값을 사용할 때 값은 문자열로 포맷합니다.
참고:
리소스 요구 사항은 에이전트 구성을 통해서만 설정할 수 있습니다. 스캔 실행 정책
을 통해 운영용 컨테이너 스캐닝
을 활성화한 경우, 리소스 요구 사항을 에이전트 구성 파일 내에서 정의해야 합니다.
Trivy K8s Wrapper의 사용자 지정 저장소
스캔 중에 OCS는 Trivy K8s Wrapper 저장소에서 이미지를 사용하여 Trivy Kubernetes에서 생성된 취약점 보고서를 OCS로 전송합니다.
클러스터 방화벽이 Trivy K8s Wrapper 저장소의 액세스를 제한하는 경우, OCS를 구성하여 이미지를 사용자 지정 저장소에서 가져오도록 설정할 수 있습니다. 사용자 정의 저장소가 호환성을 위해 Trivy K8s Wrapper 저장소를 반영하도록 하세요.
container_scanning:
trivy_k8s_wrapper_image:
repository: "your-custom-registry/your-image-path"
클러스터 취약점 보기
GitLab에서 취약점 정보를 보려면:
- 왼쪽 사이드바에서 검색 또는 이동을 선택하고 에이전트 구성 파일이 포함된 프로젝트를 찾습니다.
- 운영하기 > Kubernetes 클러스터를 선택합니다.
- 에이전트 탭을 선택합니다.
- 클러스터 취약점을 보려면 에이전트를 선택합니다.
이 정보는 또한 운영용 취약점에서 찾을 수 있습니다.
참고: 최소한 Developer 역할이 있어야 합니다.
개인 이미지 스캔
- GitLab 16.4에서 도입.
개인 이미지를 스캔하려면, 스캐너는 이미지를 가져오기 위해 이미지 pull secrets(직접 참조 및 서비스 계정에서)에 의존합니다.
제한 사항
GitLab 에이전트 16.9 이상에서 운영용 컨테이너 스캐닝:
- 최대 100MB까지의 Trivy 보고서를 처리합니다. 이전 릴리스에서는 이 제한이 10MB입니다.
- GitLab 에이전트가
fips
모드에서 실행될 때 비활성화됩니다.
문제 해결
Trivy 스캔 실행 중 오류. 컨테이너 종료 사유: OOMKilled
OCS는 스캔해야 하는 리소스가 너무 많거나 스캔 중인 이미지가 크기가 큰 경우 OOM 오류로 실패할 수 있습니다. 이를 해결하려면 사용 가능한 메모리 양을 늘리기 위해 리소스 요구 사항을 구성하세요.