Snyk Broker - 컨테이너 레지스트리 에이전트
기능 가용성
Snyk Broker 컨테이너 레지스트리 에이전트는 엔터프라이즈(Enterprise) 플랜에서만 사용할 수 있습니다. 자세한 내용은 플랜 및 가격을 참조하십시오.
Snyk Broker 컨테이너 레지스트리 에이전트를 사용하면 네트워크가 제한된 컨테이너 레지스트리에 연결하여 Snyk 서비스를 통해 이러한 레지스트리를 스캔할 수 있습니다.
컨테이너 레지스트리 에이전트를 사용하면 Snyk은 사용자가 호스팅하는 프라이빗 컨테이너 레지스트리와 통합할 수 있으며, 해당 레지스트리의 컨테이너 이미지를 더 효과적으로 보호하도록 돕습니다. 프라이빗 컨테이너 레지스트리와의 통합을 통해 다음이 가능합니다.
액세스 토큰과 같은 민감한 데이터를 프라이빗 네트워크 내에 유지하고 Snyk과 공유하지 않습니다.
Snyk에 대한 네트워크 액세스를 제어하여 Snyk의 액세스 및 수행 가능한 작업을 제한합니다.
이 페이지에서는 컨테이너 레지스트리 에이전트를 사용하여 이 페이지에 나열된 지원되는 오픈소스 컨테이너 레지스트리와 Broker를 통해 통합하는 방법을 설명합니다. 이 통합 방법은 이미지를 Snyk 서비스 내부가 아닌 자체 환경에서 스캔해야 하는 사용자를 위해 설계되었습니다.
이미지를 자체 환경에서 스캔할 필요가 없는 경우 컨테이너 레지스트리 에이전트를 사용할 필요가 없습니다. 계정의 통합 페이지에서 지원되는 컨테이너 레지스트리와 통합할 수 있습니다. 자세한 내용은 Snyk Container 보안 통합을 참조하십시오.
네트워크 제한 컨테이너 레지스트리 솔루션의 구성 요소
네트워크 제한 컨테이너 레지스트리에는 다음 구성 요소가 필요합니다.
Broker 서버: Snyk SaaS 백엔드에서 실행됩니다.
Broker 클라이언트 및 컨테이너 레지스트리 에이전트: 사용자의 인프라에 배포된 두 개의 Docker 이미지로, 보안 방식으로 컨테이너 레지스트리를 샘플링하고 허용된 정보를 Snyk에 전송하는 역할을 하는 두 개의 별도 서비스입니다.
Broker 클라이언트는 컨테이너 레지스트리 에이전트에 연결 세부 정보를 제공합니다. 에이전트는 이러한 세부 정보를 사용하여 컨테이너 레지스트리에 연결하고, 이미지를 스캔하며, 콜백을 사용하여 브로커 통신을 통해 스캔 결과를 보냅니다. 브로커 통신은 Broker 클라이언트가 사용자의 Broker ID를 사용하여 Snyk 환경에서 실행되는 Broker 서버에 연결할 때 발생합니다. 자세한 내용은 Snyk Broker 소개 정보를 참조하십시오.
지원되는 컨테이너 레지스트리
Snyk Broker 컨테이너 레지스트리 에이전트를 사용하여 Snyk을 다음 오픈소스 컨테이너 레지스트리와 통합할 수 있습니다.
JFrog 컨테이너 레지스트리 (Artifactory) (유형: artifactory-cr)
Harbor 레지스트리 (유형: harbor-cr)
Azure Container Registry (유형: acr)
Google Cloud Container Registry (GCR) (유형: gcr)
Amazon Elastic Container Registry (ECR) (유형: ecr)
Google Artifact Registry (유형: google-artifact-cr)
Docker Hub 레지스트리 (유형: docker-hub). 참고: Snyk Broker는 OCI Distribution의 자체 호스팅 인스턴스(예:
docker.io/registry)에 연결할 수 없습니다.RedHat Quay 컨테이너 레지스트리 (유형: quay-cr)
Nexus 레지스트리 (유형: nexus-cr)
GitHub 컨테이너 레지스트리 (유형: github-cr)
DigitalOcean 컨테이너 레지스트리 (유형: digitalocean-cr)
GitLab 컨테이너 레지스트리 (유형: gitlab-cr)
Artifactory 및 Nexus는 Broker 옵션이 있는 프라이빗 패키지 리포지토리로도 사용할 수 있습니다. 컨테이너 레지스트리에 필요한 Broker는 snyk/broker:artifactory 또는 snyk/broker:nexus용 Broker가 아니라 컨테이너 레지스트리 에이전트를 위한 사전 준비 사항에 명시된 것이어야 합니다.
GitHub 컨테이너 레지스트리 및 GitLab 컨테이너 레지스트리는 Docker v2 API를 따르지 않으며 /v2/_catalog 엔드포인트가 없습니다. 따라서 리포지토리의 이미지를 나열하는 것이 불가능하며 스캔하려는 이미지를 수동으로 지정해야 합니다.
컨테이너 레지스트리 에이전트를 위한 사전 준비 사항
컨테이너 레지스트리 에이전트가 작동하려면 인프라에 두 개의 별도 컨테이너가 배포되어 두 개의 별도 서비스를 생성해야 합니다. 자세한 내용은 네트워크 제한 컨테이너 레지스트리 솔루션의 구성 요소를 참조하십시오.
Snyk Broker 컨테이너 레지스트리 에이전트를 설정하고 실행하기 위한 시스템 및 소프트웨어 요구 사항은 다음과 같습니다.
Broker 클라이언트 머신 시스템 요구 사항: CPU 1개, RAM 256MB
컨테이너 레지스트리 에이전트 머신 시스템 요구 사항 (MAX_ACTIVE_OPERATIONS=1인 경우):
CPU: 1 vcpu
메모리: 2Gb (노드 메모리 설정에 반영되어야 함)
스토리지: 5Gb
이미지 목록 보기(list) 및 가져오기(pull) 권한이 있는 컨테이너 레지스트리 자격 증명
Broker와 에이전트 간의 연결
에이전트와 레지스트리 간의 HTTPS 연결. HTTP 전용 레지스트리의 경우 에이전트와 컨테이너 레지스트리 사이에 리버스 프록시를 배포하십시오.
Docker용 클래식 Broker를 사용하는 경우 Broker 클라이언트를 배포할 때
snyk/broker:container-registry-agent이미지를 사용하십시오.Universal Broker를 사용하는 경우: Docker의 경우 Broker 클라이언트를 배포할 때
snyk/broker:universal이미지를 사용하십시오.Docker용 컨테이너 레지스트리 에이전트 이미지 다운로드 후 Docker를 사용하는 경우
snyk/container-registry-agent:latest명령을 사용하십시오.
스캔 용량 조절을 위한 스케일링
1 vCPU 및 2GB RAM 구성의 경우, 한 번의 실행에 약 350MB 크기의 이미지 160개를 스캔할 수 있습니다. 이미지 크기에 따라 이를 확장할 수 있습니다. 스케일링이 불가능하거나 제한 사항에 맞지 않는 특정 사용 사례가 있는 경우 Snyk 지원팀에 문의하십시오.
Docker를 사용하여 컨테이너 레지스트리 에이전트를 위한 원격 연결 설정
컨테이너 레지스트리 에이전트 구성 및 실행
Universal 및 클래식 Broker 모두 해당 배포의 구성 입력(컨테이너 레지스트리 에이전트 URL)이 필요하므로 컨테이너 레지스트리 에이전트를 먼저 배포할 것을 권장합니다. 사전 준비 사항에 제공된 링크를 사용하여 Docker Hub에서 컨테이너 레지스트리 에이전트 이미지를 가져올 수 있습니다.
컨테이너 레지스트리 에이전트를 구성하기 위해 다음 환경 변수를 사용할 수 있습니다.
SNYK_PORT- 컨테이너 레지스트리 에이전트가 연결을 수락하는 로컬 포트 (기본값: 17500).SNYK_MAX_IMAGE_SIZE_IN_BYTES- Snyk이 스캔할 수 있는 이미지의 최대 크기 (선택 사항, 기본값: 2147483648).
관련 구성을 사용하여 컨테이너 레지스트리 에이전트 컨테이너를 실행합니다.
Universal Broker
Universal Broker 페이지에 있는 설치 지침에 따라 Universal Broker를 배포하십시오. snyk-broker-config CLI 도구는 Broker 클라이언트를 컨테이너 레지스트리 에이전트 및 컨테이너 레지스트리에 연결하는 데 필요한 모든 구성 세부 정보를 제출하고 저장하는 과정을 안내합니다.
연결을 생성하는 동안 다음 세부 정보를 제공해야 합니다.
CR_AGENT_URL- 위에서 배포한 컨테이너 레지스트리 에이전트의 URL(스키마 및 포트 포함)로, Broker 클라이언트가 요청을 라우팅하는 위치입니다 (예: "http://my.container-registry-agent:8081").CR_BASE- 연결할 컨테이너 레지스트리 API의 호스트 이름 (예: "cr.host.com").CR_USERNAME- 컨테이너 레지스트리 API 인증을 위한 사용자 이름.CR_PASSWORD- 컨테이너 레지스트리 API 인증을 위한 비밀번호 자격 증명 참조.CR_TOKEN- 특정 연결 유형에 필요한 경우 인증 토큰 자격 증명 참조.
클래식 Broker
Snyk 클래식 Broker 및 컨테이너 레지스트리 에이전트를 설정하려면 Broker 토큰이 있어야 합니다. Broker 토큰을 얻으려면 Snyk 지원팀에 문의하십시오.
컨테이너 레지스트리 에이전트를 위한 Broker 클라이언트 구성 및 실행
컨테이너 레지스트리 에이전트 배포와 함께 Broker 클라이언트를 사용하려면, 사전 준비 사항에서 수행하지 않았다면 docker pull snyk/broker:container-registry-agent를 실행하십시오.
Broker 클라이언트를 구성하려면 다음 환경 변수가 필요합니다.
DigitalOcean 컨테이너 레지스트리, Google Cloud 컨테이너 레지스트리, Google Artifact Registry 및 Artifactory의 경우 컨테이너 레지스트리별 구성이 필요합니다. Elastic Container Registry(ECR)의 경우 추가 설정이 필요하며, 특정 구성도 제공됩니다.
BROKER_TOKEN- Snyk 지원팀에서 제공하는 컨테이너 레지스트리 통합에서 얻은 Snyk Broker 토큰.BROKER_CLIENT_URL- 컨테이너 레지스트리 에이전트가 브로커 연결을 통해 Snyk으로 콜백하는 데 사용되는 Broker 클라이언트의 URL(스키마 및 포트 포함) (예: "http://my.broker.client:8000").여기에는
http://와 포트 번호가 포함되어야 합니다.클라이언트를 HTTPS로 구성하려면 추가 설정이 필요합니다.
CR_AGENT_URL- Broker 클라이언트가 요청을 라우팅하는 컨테이너 레지스트리 에이전트의 URL(스키마 및 포트 포함) (예: "http://my.container-registry-agent:8081").CR_TYPE- 이 페이지의 지원되는 컨테이너 레지스트리에 나열된 컨테이너 레지스트리 유형 (예: "docker-hub", "gcr", "artifactory-cr").CR_BASE- 연결할 컨테이너 레지스트리 API의 호스트 이름 (예: "cr.host.com").CR_USERNAME- 컨테이너 레지스트리 API 인증을 위한 사용자 이름.CR_PASSWORD- 컨테이너 레지스트리 API 인증을 위한 비밀번호.CR_TOKEN- DigitalOcean 컨테이너 레지스트리를 위한 인증 토큰.PORT- Broker 클라이언트가 연결을 수락하는 로컬 포트 (기본값: 7341).선택 사항 -
BROKER_CLIENT_VALIDATION_URL- 컨테이너 레지스트리 에이전트를 위해/systemcheck를 구성하는 URL. 자세한 내용은 이 페이지의 systemcheck 구성 및 사용을 참조하십시오.
관련 구성을 사용하여 Broker 클라이언트 컨테이너를 실행합니다.
컨테이너 레지스트리별 구성
다음 컨테이너 레지스트리에는 특정 환경 변수나 설정 또는 둘 다 필요하며, Universal 및 클래식 Broker 모두에 유효합니다.
DigitalOcean 컨테이너 레지스트리
DigitalOcean 컨테이너 레지스트리용 Broker 클라이언트를 설정하는 데 CR_USERNAME 및 CR_PASSWORD는 필요하지 않습니다. 대신 Digital Ocean 인증 토큰인 CR_TOKEN을 지정하십시오.
GCR 및 Google Artifact Registry
앞의 모든 정보가 이러한 컨테이너 레지스트리용 Broker 클라이언트 설정에 적용됩니다. CR_USERNAME 값은 고정되어 있으며 _json_key여야 하고, CR_PASSWORD 값은 Google 인증에 사용되는 JSON 키여야 합니다.
JFrog 컨테이너 레지스트리 (Artifactory)
Docker 액세스 방법으로 Repository path를 사용하는 경우, CR_BASE 변수에 컨테이너 레지스트리 호스트 이름을 <your artifactory host>/artifactory/api/docker/<artifactory-repo-name> 구조로 설정하십시오.
Artifactory에서 프로젝트를 가져오기 위해 카탈로그 엔드포인트 /artifactory/api/docker/<artifactory-repository>/v2/_catalog는 필요하지 않습니다. 카탈로그 엔드포인트는 이미지 리포지토리를 나열하는 데 사용됩니다.
자세한 내용은 JFrog Artifactory 컨테이너 레지스트리 통합 구성을 참조하십시오.
Elastic Container Registry (ECR)
ECR 및 기타 컨테이너 레지스트리에서 통신 방식은 동일합니다. 에이전트는 컨테이너 레지스트리에 동기식 호출을 하여 이미지를 나열하고 가져옵니다. 그런 다음 에이전트는 이미지를 스캔하고 콜백을 사용하여 Broker 클라이언트에 결과를 보냅니다. ECR에는 에이전트에 IAM 역할(Role) 또는 사용자(User) 설정이 필요한 특별한 인증 메커니즘이 있습니다.
ECR 사용 시 필요한 AWS 리소스
ECR 설정에는 다음과 같은 종류의 IAM 리소스 생성이 필요합니다.
컨테이너 레지스트리 에이전트 IAM 역할 또는 IAM 사용자: 에이전트가 ECR에 액세스할 수 있는 교차 계정 역할을 맡기 위해 사용하는 IAM 역할 또는 IAM 사용자입니다. 여기에는 "
sts:AssumeRole" 권한이 있어야 합니다.Snyk ECR 서비스 역할: 컨테이너 레지스트리 에이전트 IAM 역할 또는 IAM 사용자가 ECR에 대한 읽기 전용 액세스 권한을 얻기 위해 맡는 ECR 액세스 권한이 있는 IAM 역할. ECR 서비스 역할에는 다음 권한이 있어야 합니다.
ECR 설정 단계
설명된 리소스는 다음과 같이 사용될 수 있으며, 이를 통해 단일 컨테이너 레지스트리 에이전트 인스턴스가 서로 다른 계정에 있는 ECR 리포지토리에 액세스할 수 있습니다.
이 단계는 한 번만 실행하십시오. 컨테이너 레지스트리 에이전트 IAM 역할 또는 IAM 사용자를 생성하고 이를 사용하여 컨테이너 레지스트리 에이전트를 실행하십시오. IAM 역할 또는 IAM 사용자는 AWS 문서에 설명된 방법 중 하나를 사용하여 컨테이너 레지스트리 에이전트에 제공될 수 있습니다.
각 ECR 계정에 대해 별도의 Broker 인스턴스를 사용하여 다음 단계를 수행하십시오.
ECR이 있는 AWS 계정에서 ECR에 대한 읽기 권한이 있는 Snyk ECR 서비스 역할을 생성하고, 일회성 단계에서 생성된 특정 컨테이너 레지스트리 에이전트 IAM 역할 또는 IAM 사용자만 이 역할을 맡을 수 있도록 신뢰 관계를 편집합니다.
컨테이너 레지스트리 에이전트 IAM 역할 또는 IAM 사용자가 Snyk ECR 서비스 역할만 맡을 수 있도록 제한합니다.
Broker 클라이언트에 Snyk ECR 서비스 역할의 Role ARN(Amazon 리소스 이름)과 ECR 지역(region)을 제공합니다. Broker 클라이언트는 이 Role ARN을 컨테이너 레지스트리 에이전트에 전달하고, 에이전트는 이를 맡아 ECR에 액세스합니다. 다음 환경 변수가 필요합니다.
CR_ROLE_ARN=<SnykEcrServiceRole의 Role ARN>
CR_REGION=<ECR의 AWS 지역>
CR_EXTERNAL_ID=<선택 사항. 신뢰 관계 조건에서 발견된 외부 ID>
systemcheck 구성 및 사용
Broker 클라이언트의 /systemcheck 엔드포인트를 사용하여 Broker 클라이언트, 컨테이너 레지스트리 에이전트 및 컨테이너 레지스트리 간의 연결을 확인할 수 있습니다.
이 엔드포인트를 사용하려면 Broker 클라이언트에 다음 환경 변수를 제공하십시오. BROKER_CLIENT_VALIDATION_URL=<agent-url>/systemcheck
Broker 클라이언트의 /systemcheck 엔드포인트를 호출하면, Broker 클라이언트에 제공된 자격 증명을 사용하여 컨테이너 레지스트리 에이전트의 /systemcheck 엔드포인트에 요청을 보내기 위해 BROKER_CLIENT_VALIDATION_URL을 사용합니다. 그런 다음 컨테이너 레지스트리 에이전트는 연결을 확인하기 위해 컨테이너 레지스트리에 요청을 보냅니다.
브로커 통합이 작동하기 위해 /systemcheck 엔드포인트가 필수적인 것은 아닙니다. 자세한 내용은 Systemcheck 문서를 참조하십시오.
컨테이너 레지스트리 에이전트 디버깅 방법
컨테이너 레지스트리 에이전트 및 Broker 클라이언트의 원하는 로그 레벨을 제어하기 위해 LOG_LEVEL 환경 변수를 설정할 수 있습니다. 기본값은 info입니다. 허용되는 값은 debug, info, warn, error입니다.
타사 라이브러리에 대한 디버깅을 활성화하는 것은 운영 환경에서 권장되지 않습니다. Snyk에서 관리하지 않는 로그(예: HTTP 요청 헤더)에 민감한 정보가 노출될 수 있기 때문입니다.
타사 HTTP 요청 라이브러리인 Needle에서 디버그 로그를 활성화하려면 환경 변수 NODE_DEBUG=needle을 설정하십시오.
모든 타사 라이브러리에서 디버그 로그를 활성화하려면 환경 변수 DEBUG=* 및 NODE_DEBUG=*를 설정하십시오.
DEBUG 환경 변수는 Debug 패키지 출력을 제어합니다. NODE_DEBUG 환경 변수는 Node.js util.debuglog 출력을 제어합니다.
Last updated