Azure Container Registry에서 연속 패치 구성

이 문서에서는 연속 패치를 설치, 사용 및 구성하는 방법을 알아봅니다. 컨테이너 레지스트리에 대해 사용하도록 설정된 경우 연속 패치는 컨테이너 이미지에 대한 OS(운영 체제) 수준 취약성을 자동으로 검색하고 수정합니다.

필수 조건

  • Azure Cloud Shell 또는 Azure CLI의 로컬 설치를 2.15.0 이상의 최소 버전으로 사용할 수 있습니다.
  • ACR(Azure Container Registry)이 있는 기존 리소스 그룹이 있습니다.
  • ACR 작업을 사용하도록 설정된 Azure Container Registry가 있습니다(ACR 작업은 ACR의 무료 계층에서 지원되지 않음).

다음 명령을 실행하여 CLI 확장을 설치합니다.

    az extension add -n acrcssc

연속 패치 워크플로 사용

  1. az login을 사용하여 Azure CLI에 로그인합니다.

    az login
    
  2. ACR에 로그인합니다.

    az acr login -n <myRegistry>
    
  3. 다음 명령을 실행하여 이름이 인 파일을 만듭니다 continuouspatching.json.

    cat <<EOF > continuouspatching.json
    {
        "version": "v1",
        "tag-convention" : "<incremental|floating>",
        "repositories": [{
            "repository": "<Repository Name>",
            "tags": ["<comma-separated-tags>"],   
            "enabled": <true|false>
        }] 
    }
    EOF
    

    스키마는 배열 형식으로 특정 리포지토리 및 태그를 수집합니다. 각 변수는 다음과 같이 정의됩니다.

    • version 를 사용하면 ACR 팀이 현재 사용 중인 스키마 버전을 추적할 수 있습니다. 지시하지 않는 한 이 변수를 변경하지 마세요.

    • tag-convention 는 선택적 필드입니다. 허용되는 값은 "증분" 또는 "부동"입니다. 자세한 내용은 연속 패치의 주요 개념을 참조하세요.

    • repositories 는 자세한 리포지토리 및 태그 정보로 구성된 배열입니다.

      • repository 는 리포지토리 이름을 참조합니다.
      • tags 는 쉼표로 구분된 태그 배열입니다. 와일드카드 * 는 해당 리포지토리 내의 모든 태그를 나타내는 데 사용할 수 있습니다.
      • enabled 은 지정된 리포지토리를 사용할 수 있는지 여부를 확인하는 true 또는 false의 부울 값입니다.

    아래 예제는 고객이 리포지토리 python 내의 모든 태그(기호 * 사용)를 패치하고, 리포지토리 jammy-20240111에서 jammy-20240125ubuntu 태그를 구체적으로 패치하려는 경우의 구성을 보여줍니다.

    {
    "version": "v1",
    "tag-convention" : "incremental",
    "repositories": [{
            "repository": "python",
            "tags": ["*"],
            "enabled": true
        },
        {
            "repository": "ubuntu",
            "tags": ["jammy-20240111", "jammy-20240125"],
         "enabled": true, 
        }]
    }
    
  4. 구성 파일을 만든 후 드라이 런을 실행하여 JSON 기준에 따라 의도한 아티팩트가 선택되었는지 확인합니다. 드라이 런에는 연속 패치 주기가 실행되는 빈도를 지정하는 매개 변수가 schedule필요합니다. 일정 플래그는 일 단위로 측정되며, 최소값은 1일, 최대값은 30일입니다. 예를 들어 이미지를 매일 패치하려면 일정을 1일로 1d지정합니다. 일주일에 한 번의 주간 패치를 원하는 경우, 일정을 7일 또는 7d로 설정합니다.

    az acr supply-chain workflow create -r myRegistry -g myResourceGroup -t continuouspatchv1 --config ./continuouspatching.json --schedule 1d --dry-run   
    

    플래그는 --dry-run JSON 파일 구성으로 지정된 모든 아티팩트 출력합니다. 올바른 아티팩트가 선택되어 있는지 확인합니다. 샘플 ubuntu 구성을 사용하면 다음 결과가 출력으로 표시되어야 합니다.

    Ubuntu: jammy-20240111
    Ubuntu: jammy-20240125
    
  5. 드라이런 결과에 만족하면, --dry-run 플래그 없이 create 명령을 다시 실행하여 연속 패치 워크플로를 생성합니다.

    비고

    매개 변수는 --schedule 해당 월의 1일부터 시작하는 일정한 일수의 배수를 따릅니다. 즉, 다음을 의미합니다.

    • 3일에 --schedule 7d를 지정하고 명령을 실행하면, 다음 예약 실행은 7일에 이루어집니다. 이는 7이 해당 월의 1일부터 시작하여 3일 이후에 오는 첫 번째 7의 배수이기 때문입니다.
    • 3d이고 오늘이 7일이면 --schedule 다음으로 예정된 실행은 9일에 발생합니다. 9는 7 뒤에 오는 3의 다음 배수이기 때문에.
    • 플래그 --run-immediately를 추가하는 경우 즉시 패치 실행을 트리거합니다. 이후 예약된 실행은 귀하의 --schedule 값에 따라 월의 첫 번째 날부터 가장 가까운 날짜 배수에 맞춰 계속 정렬됩니다.
    • 일정 카운터 는 매달 다시 설정됩니다 . 지정된 일정에 관계없이 워크플로는 매월 첫 번째 날짜에 실행된 다음, 해당 월의 나머지 부분에 대해 지정된 일정 값을 따릅니다. 내 패치가 1월 28일에 실행되고 일정이 7일인 경우 다음 패치는 2월 1일, 그리고 2월 8일에 실행되며 7일마다 계속됩니다.
    az acr supply-chain workflow create -r myRegistry -g myResourceGroup -t continuouspatchv1 --config ./continuouspatching.json --schedule 1d --run-immediately
    

    명령이 성공하면(포함 --run-immediately여부) 워크플로 작업이 큐에 대기 중임을 확인하는 성공 메시지가 표시됩니다. 또한 워크플로의 다음 실행이 예약된 시기를 나타내는 출력 매개 변수가 표시되므로 패치가 다시 발생하는 시기를 정확하게 추적할 수 있습니다.

Azure Portal을 사용하여 워크플로 작업 보기

  1. 워크플로가 성공하면 Azure Portal로 이동하여 실행 중인 작업을 확인합니다. 서비스 메뉴의 서비스 아래에서 리포지토리를 선택합니다. 라는 csscpolicies/patchpolicy새 리포지토리가 표시됩니다. 이 리포지토리는 연속 패치를 위해 지속적으로 참조되는 JSON 구성 아티팩트 호스트합니다.

  2. 다음으로 서비스 아래에서 작업을 선택합니다. 세 가지 새 작업이 표시됩니다.

    • cssc-trigger-workflow - 이 작업은 구성 파일을 검색하고 각 이미지에서 검사 작업을 호출합니다.
    • cssc-scan-image - 이 작업은 이미지에서 운영 체제 취약성을 검사합니다. 이 작업은 운영 체제 취약성이 발견된 경우에만 패치 작업을 트리거합니다.
    • cssc-patch-image - 이 작업은 이미지를 패치합니다.

    이러한 작업은 연속 패치 워크플로를 실행하기 위해 함께 작동합니다.

  3. 특정 작업 실행을 보려면 실행을 선택합니다. 여기에서 디버그 로그 보기와 함께 작업이 성공했는지 또는 실패했는지에 대한 상태 정보를 볼 수 있습니다.

연속 패치를 위해 실행되는 작업을 보여 주는 스크린샷.

CLI를 사용하여 워크플로 작업 보기

다음 CLI 표시 명령을 실행하여 각 작업 및 일반 워크플로에 대한 자세한 내용을 볼 수도 있습니다. 이 명령은 마지막으로 수정한 날짜와 같은 일정, 생성 날짜 및 시스템 데이터를 출력합니다.

다음은 그 예입니다.

az acr supply-chain workflow show -r myRegistry -g myResourceGroup -t continuouspatchv1 

모든 필수 및 선택적 플래그를 보려면 도움말 명령을 사용합니다.

az acr supply-chain workflow show --help

연속 패치 워크플로 업데이트

연속 패치 워크플로를 편집하려면 업데이트 명령을 사용합니다. CLI 업데이트 명령을 사용하여 일정 또는 JSON 구성 스키마를 직접 업데이트할 수 있습니다. 다음은 그 예입니다.

az acr supply-chain workflow update -r myRegistry -g myResourceGroup -t continuouspatchv1 --config ./continuouspatching.json --schedule 1d

일정을 업데이트하려면 일정에 대한 새 입력으로 이전 명령을 실행합니다. JSON 구성을 업데이트하려면 파일을 변경하고, 드라이 런을 실행한 다음, 업데이트 명령을 실행하는 것이 좋습니다.

연속 패치 워크플로 삭제

연속 패치 워크플로를 삭제하려면 다음 CLI 명령을 실행합니다.

az acr supply-chain workflow delete -r myregistry -g myresourcegroup -t continuouspatchv1

워크플로가 성공적으로 삭제되면 리포지토리 "csscpolicies/patchpolicy"가 자동으로 삭제됩니다. 워크플로를 실행하는 세 가지 작업도 현재 큐에 대기 중인 실행과 함께 삭제됩니다.

연속 패치 문제 해결

이러한 팁을 검토하여 지속적인 패치로 발생할 수 있는 문제를 해결합니다.

실행 중인 작업 나열

중요한 디버깅 정보를 가져오려면 다음 명령을 사용하여 가장 최근에 실행된 연속 패치 작업을 나열합니다.

az acr supply-chain workflow list -r <registryname> -g <resourcegroup> [--run-status <failed || successful || running>] -t continuouspatchv1

성공적인 결과는 다음 정보를 반환합니다.

  • 이미지 이름 및 태그
  • 워크플로 유형
  • 검사 상태
  • 마지막 검사 날짜 및 시간(상태가 실패하면 날짜는 비워 집니다.)
  • 검사 작업 ID(추가 디버깅용)
  • 패치 상태
  • 마지막 패치 날짜 및 시간(상태가 실패한 경우 날짜는 비워 집니다.)
  • 패치된 이미지 이름 + 태그
  • 패치 작업 ID(추가 디버깅용)

[--run-status]를 사용하여 지정된 필터와 일치하는 모든 작업 상태를 반환합니다. 예를 들어 지정 --run-status failed하는 경우 패치에 실패한 이미지만 나열됩니다.

실행 중인 작업 취소

특정 시나리오에서는 현재 실행 중이거나 실행 대기 중인 작업을 취소해야 할 수 있습니다. 예를 들어 패치 작업이 완료될 때까지 기다리지 않고 바로 수정하려는 잘못된 구성이 표시될 수 있습니다.

실행 중인 작업을 취소하려면 다음 CLI 명령을 사용합니다.

az acr supply-chain workflow cancel-run -r <registryname> -g <resourcegroup> --type <continuouspatchv1>

이 명령은 현재 일정에 대해 상태 Running, Queued, 또는 Started인 모든 지속적 패치 작업을 취소합니다. 예를 들어 일별 일정(--schedule 1d)에 따라 작업을 취소하는 경우 해당 상태의 작업은 해당 날짜에 대해 취소된 다음 다음 날로 다시 예약됩니다. 일정이 매주인 경우 취소된 작업이 다음 주에 다시 표시됩니다.

실패한 작업 찾기

작업 목록 명령을 사용하여 실패한 모든 작업을 출력하세요. 명령을 지정하는 cssc-patch 것이 실패에 가장 적합합니다.

예를 들어 이 명령은 실패한 상위 10개 패치 작업을 반환합니다.

az acr task list-runs -r <registryname> -n cssc-patch-image --run-status Failed --top 10

특정 오류를 조사하려면 이 명령에서 반환된 runID 오류를 확인하고 다음을 실행합니다.

az acr task logs -r <registryname> --run-id <run-id>

잘못 구성된 워크플로 취소

취소 명령을 사용하여 대기 중 작업을 취소합니다.

az acr supply-chain workflow cancel-run -r <registryname> -g <resourcegroup> --type <continuouspatchv1>