- 지원 아키텍처
- 운영 컨테이너 스캐닝 활성화
- 다중 클러스터 구성에 대한 OCS 취약점 해결
- 스캐너 리소스 요구 사항 구성
- Trivy K8s Wrapper용 사용자 지정 리포지토리
- 클러스터 취약점 보기
- 개인 이미지 스캔
- 제한 사항
- 문제 해결
운영 컨테이너 스캐닝
- Deprecated GitLab 15.4에서 starboard 지시어가 사용 중단되었습니다. starboard 지시어는 GitLab 16.0에서 제거될 예정입니다.
지원 아키텍처
GitLab agent for Kubernetes 16.10.0 이상 및 GitLab agent Helm Chart 1.25.0 이상에서 운영 컨테이너 스캐닝(OCS)은 linux/arm64 및 linux/amd64를 지원합니다. 이전 버전에서는 linux/amd64만 지원됩니다.
운영 컨테이너 스캐닝 활성화
클러스터 내에서 보안 취약점을 위해 컨테이너 이미지를 스캔하기 위해 OCS를 사용할 수 있습니다.
GitLab agent 16.9 이후, OCS는 취약점 스캔을 위해 Trivy 주위에 wrapper image를 사용합니다.
GitLab 16.9 이전에는 OCS가 Trivy 이미지를 직접 사용했습니다.
OCS는 agent config 또는 프로젝트의 스캔 실행 정책을 사용하여 주기적으로 실행되도록 구성할 수 있습니다.
agent config와 scan execution policies가 모두 구성된 경우, scan execution policy의 구성이 우선합니다.에이전트 구성으로 활성화
에이전트 구성을 통해 Kubernetes 클러스터 내의 이미지 스캔을 활성화하려면, 에이전트 구성에 cadence 필드를 포함하는 container_scanning 구성 블록을 추가합니다.
이 필드는 스캔이 실행되는 시점을 위한 CRON 표현식을 포함해야 합니다.
container_scanning:
cadence: '0 0 * * *' # 매일 00:00 (Kubernetes 클러스터 시간)
cadence 필드는 필수입니다. GitLab은 cadence 필드에 대해 다음과 같은 CRON 구문 유형을 지원합니다:
- 특정 시간에 매시간 한 번의 일일 주기, 예:
0 18 * * * - 특정 날과 특정 시간에 매주 한 번의 주간 주기, 예:
0 13 * * 0
기본적으로 운영 컨테이너 스캐닝은 어떤 작업에 대해서도 취약점을 스캔하지 않습니다.
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 클러스터 내의 모든 이미지를 스캔하려면, 우리는 스캔 실행 정책 편집기를 사용할 수 있습니다.
새로운 스케줄 규칙을 생성할 수 있습니다.
다음은 Kubernetes 에이전트가 연결된 클러스터 내에서 운영 컨테이너 스캔을 활성화하는 정책의 예입니다:
- name: my-gitlab-agent를 통해 연결된 클러스터에서 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 네임스페이스. 생략할 경우 모든 네임스페이스가 스캔됩니다.
스캔 실행 정책 문서 내에서 전체 스키마를 볼 수 있습니다: 스캔 실행 정책 문서.
다중 클러스터 구성에 대한 OCS 취약점 해결
OCS와 함께 정확한 취약점 추적을 보장하기 위해, 각 클러스터에 대해 OCS가 활성화된 별도의 GitLab 프로젝트를 생성해야 합니다. 여러 클러스터가 있는 경우 각 클러스터에 대해 하나의 프로젝트를 사용해야 합니다.
OCS는 각 스캔 후 현재 스캔 취약점과 이전에 감지된 취약점을 비교하여 클러스터에서 더 이상 발견되지 않는 취약점을 해결합니다. 현재 스캔에서 더 이상 존재하지 않는 이전 스캔의 취약점은 GitLab 프로젝트에 대해 해결됩니다.
같은 프로젝트에 여러 클러스터가 구성되어 있으면, 한 클러스터(예: 프로젝트 A)에서의 OCS 스캔이 다른 클러스터(예: 프로젝트 B)에서 이전에 감지된 취약점을 해결하여 잘못된 취약점 보고가 발생할 수 있습니다.
스캐너 리소스 요구 사항 구성
디폴트로 스캐너 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에 대해 소수 값을 사용할 때, 값을 문자열 형식으로 포맷하세요.
스캔 실행 정책을 통해 운영 컨테이너 스캔을 활성화한 경우, 에이전트 구성 파일 내에서 리소스 요구 사항을 정의해야 합니다.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에서 취약점 정보를 보려면:
- 왼쪽 사이드바에서 Search or go to를 선택하고 에이전트 구성 파일이 포함된 프로젝트를 찾습니다.
- 운영 > Kubernetes 클러스터를 선택합니다.
- 에이전트 탭을 선택합니다.
- 클러스터 취약점을 보려면 에이전트를 선택합니다.
이 정보는 운영 취약점에서도 찾을 수 있습니다.
참고: 최소한 개발자 역할이 있어야 합니다.
개인 이미지 스캔
- GitLab 16.4에 도입됨(Introduced).
개인 이미지를 스캔하기 위해 스캐너는 이미지를 가져오기 위해 이미지 풀 비밀(직접 참조 및 서비스 계정으로부터)을 사용합니다.
제한 사항
GitLab 에이전트 16.9 및 이후 버전에서는 운영 컨테이너 스캔이:
- 최대 100MB의 Trivy 보고서를 처리합니다. 이전 릴리즈에서는 이 제한이 10MB였습니다.
- GitLab 에이전트가
fips모드로 실행될 때 비활성화됩니다.
문제 해결
Error running Trivy scan. Container terminated reason: OOMKilled
스캔할 리소스가 너무 많거나 스캔되는 이미지가 큰 경우 OCS가 OOM 오류와 함께 실패할 수 있습니다.
이를 해결하려면 리소스 요구 사항 구성을 통해 사용 가능한 메모리 양을 늘려야 합니다.
도움말