Cloud Build 및 GKE를 사용한 Binary Authorization 구현

이 튜토리얼에서는 Google Kubernetes Engine(GKE)에서 Binary Authorization을 설정, 구성, 사용하는 방법을 보여줍니다. Binary Authorization은 이미지를 GKE에 배포하기 전에 특정 기준의 충족 여부를 확인할 목적으로 컨테이너 이미지에 대한 증명을 만드는 프로세스입니다.

예를 들어 Binary Authorization에서는 앱의 단위 테스트 합격 여부 또는 앱 빌드 시 특정 시스템 세트 사용 여부 등을 확인할 수 있습니다. 자세한 내용과 사용 사례는 Google Kubernetes Engine을 통한 소프트웨어 공급망 보호 지원을 참조하세요.

이 가이드는 컨테이너 취약점 스캔 및 Binary Authorization을 비롯해 CI/CD 파이프라인에서 이 두 가지를 구현하고 적용하는 방법을 보다 정확히 이해하고 싶어하는 전문가들을 대상으로 작성되었습니다.

이 가이드에서는 사용자가 다음 주제와 기술에 대해 잘 알고 있다고 가정합니다.

  • 지속적 통합 및 지속적 배포
  • Common Vulnerabilities and Exposures(CVE) 취약점 스캔
  • GKE
  • Container Registry
  • Cloud Build
  • Cloud Key Management Service(Cloud KMS)

목표

  • 스테이징 및 프로덕션에 GKE 클러스터를 배포합니다.
  • 다수의 증명자 및 증명을 만듭니다.
  • Cloud Build를 사용해 CI/CD 파이프라인을 배포합니다.
  • 배포 파이프라인을 테스트합니다.
  • 긴급 상황 프로세스를 개발합니다.

비용

이 가이드에서는 비용이 청구될 수 있는 다음과 같은 Google Cloud 구성요소를 사용합니다.

프로젝트 사용량을 기준으로 예상 비용을 산출하려면 가격 계산기를 사용하세요. Google Cloud를 처음 사용하는 사용자는 무료 체험판을 사용할 수 있습니다.

이 가이드를 마치면 만든 리소스를 삭제하여 비용이 계속 청구되지 않게 할 수 있습니다. 자세한 내용은 삭제를 참조하세요.

시작하기 전에

  1. Google Cloud 계정에 로그인합니다. Google Cloud를 처음 사용하는 경우 계정을 만들고 Google 제품의 실제 성능을 평가해 보세요. 신규 고객에게는 워크로드를 실행, 테스트, 배포하는 데 사용할 수 있는 $300의 무료 크레딧이 제공됩니다.
  2. Google Cloud Console의 프로젝트 선택기 페이지에서 Google Cloud 프로젝트를 선택하거나 만듭니다.

    프로젝트 선택기로 이동

  3. Cloud 프로젝트에 결제가 사용 설정되어 있는지 확인합니다. 프로젝트에 결제가 사용 설정되어 있는지 확인하는 방법을 알아보세요.

  4. Binary Authorization, Cloud Build, Cloud KMS, GKE, Container Registry, Container Analysis, Resource Manager, and Cloud Source Repositories API를 사용 설정합니다.

    API 사용 설정

  5. Cloud Console에서 Cloud Shell을 활성화합니다.

    Cloud Shell 활성화

    Cloud Console 하단에 Cloud Shell 세션이 시작되고 명령줄 프롬프트가 표시됩니다. Cloud Shell은 gcloud 명령줄 도구가 포함되고 Cloud SDK가 사전 설치된 셸 환경으로, 현재 프로젝트의 값이 이미 설정되어 있습니다. 세션이 초기화되는 데 몇 초 정도 걸릴 수 있습니다.

  6. 이 가이드의 모든 명령어는 Cloud Shell에서 실행됩니다.

CI/CD 파이프라인 아키텍처

소프트웨어 개발 수명 주기(SDLC)에서는 조직의 승인된 프로세스에 따라 앱을 배포할 수 있도록 보장하고 이행하는 것이 중요합니다. 이러한 점을 확인하고 균형을 유지할 수 있는 한 가지 방법으로 GKE의 Binary Authorization이 있습니다. 먼저 Binary Authorization은 컨테이너 이미지에 메모를 연결합니다. 그런 다음 GKE에서 앱을 배포하기 전에 필요한 메모가 있는지 확인합니다.

이러한 메모 또는 증명은 이미지에 대한 구문을 만듭니다. 증명은 완전히 구성 가능하며, 몇 가지 일반적인 예시는 다음과 같습니다.

  • 앱이 단위 테스트를 통과했습니다.
  • 품질보증(QA) 팀에서 앱을 확인했습니다.
  • 앱에서 취약점을 검사했으며 발견된 항목이 없습니다.

다음 다이어그램은 알려진 취약점 없이 완료된 취약점 검색 후 단일 증명이 적용되는 SDLC를 보여줍니다.

단일 증명이 적용된 SDLC 아키텍처

이 가이드에서는 Cloud Source Repositories, Cloud Build, Container Registry, GKE를 사용하여 CI/CD 파이프라인을 구축합니다. 다음 다이어그램은 CI/CD 파이프라인을 보여줍니다.

Google Cloud 제품 세 가지가 포함된 CI/CD 파이프라인 아키텍처

이 CI/CD 파이프라인은 다음 단계로 구성됩니다.

  1. 앱 소스 코드로 컨테이너 이미지 빌드

  2. 컨테이너 이미지를 Container Registry로 푸시

  3. 컨테이너 분석: 컨테이너 이미지를 스캔하여 알려진 보안 취약점 또는 CVE의 유무 확인

이미지에 심각도 점수가 5점보다 높은 CVE가 없을 경우 해당 이미지는 치명적인 CVE가 없는 것으로 증명되어 스테이징 환경에 자동으로 배포됩니다. 5점보다 높은 점수는 중급 취약점부터 치명적인 취약점의 존재를 나타내며, 따라서 증명되거나 배포되지 않습니다.

QA 팀에서 스테이징 클러스터의 앱을 검사합니다. 요구사항이 충족되면 컨테이너 이미지의 품질이 프로덕션에 배포하기에 충분한지 여부를 직접 증명합니다. 그런 다음 프로덕션 매니페스트가 업데이트되고 앱이 프로덕션 환경의 GKE 클러스터에 배포됩니다.

GKE 클러스터는 컨테이너 이미지에서 증명 유무를 검사하도록 구성되어 있으며, 필요한 증명이 없으면 배포가 거부됩니다. 스테이징 GKE 클러스터에는 취약점 스캔 증명만 필요하지만 프로덕션 GKE 클러스터에는 취약점 스캔과 QA 증명이 모두 필요합니다.

이 가이드에서는 CI/CD 파이프라인에서 장애를 유도하는 이 조치를 테스트하고 확인합니다. 마지막으로 긴급 상황의 경우 GKE에서 이러한 배포 확인을 우회하기 위해 긴급 상황 처리 절차를 구현합니다.

환경 설정

이 가이드에서는 다음과 같은 환경 변수를 사용합니다. 이러한 값은 요구사항에 맞춰 변경할 수 있지만 이 가이드의 모든 단계에서는 이러한 환경 변수가 존재하고 유효한 값이 포함되어 있다고 가정합니다.

  1. Cloud Shell에서 이 가이드에 사용된 모든 리소스를 배포하고 관리하는 Cloud 프로젝트를 설정합니다.

    export PROJECT_ID="${DEVSHELL_PROJECT_ID}"
    
  2. 다음 리소스를 배포할 리전을 설정합니다.

    export REGION="us-central1"
    

    GKE 클러스터와 Cloud KMS 키는 이 리전에 있습니다. 이 가이드에서 리전은 us-central1입니다. 리전에 대한 자세한 내용은 위치 및 리전을 참조하세요.

  3. Cloud Build 프로젝트 번호를 설정합니다.

    export PROJECT_NUMBER="$(gcloud projects describe "${PROJECT_ID}" \
      --format='value(projectNumber)')"
    
  4. Cloud Build 서비스 계정 이메일을 설정합니다.

    export CLOUD_BUILD_SA_EMAIL="${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com"
    

GKE 클러스터 만들기

GKE 클러스터 2개를 만든 후 Cloud Build에서 GKE에 앱을 배포하도록 Identity and Access Management(IAM) 권한을 부여합니다. GKE 클러스터를 만드는 데 몇 분 정도 걸릴 수 있습니다.

  1. Cloud Shell에서 스테이징 환경에 배포할 GKE 클러스터를 만듭니다.

    gcloud container clusters create "staging-cluster" \
      --project "${PROJECT_ID}" \
      --machine-type "n1-standard-1" \
      --region "${REGION}" \
      --num-nodes "1" \
      --enable-binauthz
    
  2. 프로덕션 환경에 배포할 GKE 클러스터를 만듭니다.

    gcloud container clusters create "prod-cluster" \
      --project "${PROJECT_ID}" \
      --machine-type "n1-standard-1" \
      --region "${REGION}" \
      --num-nodes "1" \
      --enable-binauthz
    
  3. Cloud Build 서비스 계정에 GKE에 대한 배포 권한을 부여합니다.

    gcloud projects add-iam-policy-binding "${PROJECT_ID}" \
      --member "serviceAccount:${CLOUD_BUILD_SA_EMAIL}" \
      --role "roles/container.developer"
    

서명 키 만들기

증명 서명을 위해 2개의 Cloud KMS 비대칭 키를 만듭니다.

  1. Cloud Shell에서 binauthz라는 Cloud KMS 키링을 만듭니다.

    gcloud kms keyrings create "binauthz" \
      --project "${PROJECT_ID}" \
      --location "${REGION}"
    
  2. 취약점 스캔 증명을 서명하고 확인하는 데 사용할 vulnz-signer라는 비대칭 Cloud KMS 키를 만듭니다.

    gcloud kms keys create "vulnz-signer" \
      --project "${PROJECT_ID}" \
      --location "${REGION}" \
      --keyring "binauthz" \
      --purpose "asymmetric-signing" \
      --default-algorithm "rsa-sign-pkcs1-4096-sha512"
    
  3. qa-signer라는 비대칭 Cloud KMS 키를 만들어 QA 증명에 서명하고 확인합니다.

    gcloud kms keys create "qa-signer" \
      --project "${PROJECT_ID}" \
      --location "${REGION}" \
      --keyring "binauthz" \
      --purpose "asymmetric-signing" \
      --default-algorithm "rsa-sign-pkcs1-4096-sha512"
    

증명 구성

컨테이너 이미지에 연결된 메모를 만든 다음 Cloud Build 서비스 계정에 메모를 보고, 메모를 연결하고, 이전 단계의 키를 사용하여 증명자를 만들 수 있는 권한을 부여합니다.

취약점 스캐너 증명 만들기

  1. Cloud Shell에서 vulnz-note라는 컨테이너 분석 메모를 만듭니다.

    curl "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/?noteId=vulnz-note" \
      --request "POST" \
      --header "Content-Type: application/json" \
      --header "Authorization: Bearer $(gcloud auth print-access-token)" \
      --header "X-Goog-User-Project: ${PROJECT_ID}" \
      --data-binary @- <<EOF
        {
          "name": "projects/${PROJECT_ID}/notes/vulnz-note",
          "attestation": {
            "hint": {
              "human_readable_name": "Vulnerability scan note"
            }
          }
        }
    EOF
    
  2. Cloud Build 서비스 계정에 vulnz-note 메모를 보고 컨테이너 이미지에 연결할 수 있는 권한을 부여합니다.

    curl "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/vulnz-note:setIamPolicy" \
      --request POST \
      --header "Content-Type: application/json" \
      --header "Authorization: Bearer $(gcloud auth print-access-token)" \
      --header "X-Goog-User-Project: ${PROJECT_ID}" \
      --data-binary @- <<EOF
        {
          "resource": "projects/${PROJECT_ID}/notes/vulnz-note",
          "policy": {
            "bindings": [
              {
                "role": "roles/containeranalysis.notes.occurrences.viewer",
                "members": [
                  "serviceAccount:${CLOUD_BUILD_SA_EMAIL}"
                ]
              },
              {
                "role": "roles/containeranalysis.notes.attacher",
                "members": [
                  "serviceAccount:${CLOUD_BUILD_SA_EMAIL}"
                ]
              }
            ]
          }
        }
    EOF
    
  3. 취약점 스캔 증명자를 만듭니다.

    gcloud container binauthz attestors create "vulnz-attestor" \
      --project "${PROJECT_ID}" \
      --attestation-authority-note-project "${PROJECT_ID}" \
      --attestation-authority-note "vulnz-note" \
      --description "Vulnerability scan attestor"
    
  4. 증명자의 서명 키에 대한 공개 키를 추가합니다.

    gcloud beta container binauthz attestors public-keys add \
      --project "${PROJECT_ID}" \
      --attestor "vulnz-attestor" \
      --keyversion "1" \
      --keyversion-key "vulnz-signer" \
      --keyversion-keyring "binauthz" \
      --keyversion-location "${REGION}" \
      --keyversion-project "${PROJECT_ID}"
    
  5. Cloud Build 서비스 계정에 vulnz-attestor에서 수행한 증명을 확인할 수 있는 권한을 부여합니다.

    gcloud container binauthz attestors add-iam-policy-binding "vulnz-attestor" \
      --project "${PROJECT_ID}" \
      --member "serviceAccount:${CLOUD_BUILD_SA_EMAIL}" \
      --role "roles/binaryauthorization.attestorsViewer"
    
  6. Cloud Build 서비스 계정에 vulnz-signer 키를 사용하여 객체에 서명할 수 있는 권한을 부여합니다.

    gcloud kms keys add-iam-policy-binding "vulnz-signer" \
      --project "${PROJECT_ID}" \
      --location "${REGION}" \
      --keyring "binauthz" \
      --member "serviceAccount:${CLOUD_BUILD_SA_EMAIL}" \
      --role 'roles/cloudkms.signerVerifier'
    

QA 증명 만들기

  1. Cloud Shell에서 qa-note라는 컨테이너 분석 메모를 만듭니다.

    curl "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/?noteId=qa-note" \
      --request "POST" \
      --header "Content-Type: application/json" \
      --header "Authorization: Bearer $(gcloud auth print-access-token)" \
      --header "X-Goog-User-Project: ${PROJECT_ID}" \
      --data-binary @- <<EOF
        {
          "name": "projects/${PROJECT_ID}/notes/qa-note",
          "attestation": {
            "hint": {
              "human_readable_name": "QA note"
            }
          }
        }
    EOF
    
  2. Cloud Build 서비스 계정에 qa-note 메모를 보고 컨테이너 이미지에 연결할 수 있는 권한을 부여합니다.

    curl "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/qa-note:setIamPolicy" \
      --request POST \
      --header "Content-Type: application/json" \
      --header "Authorization: Bearer $(gcloud auth print-access-token)" \
      --header "X-Goog-User-Project: ${PROJECT_ID}" \
      --data-binary @- <<EOF
        {
          "resource": "projects/${PROJECT_ID}/notes/qa-note",
          "policy": {
            "bindings": [
              {
                "role": "roles/containeranalysis.notes.occurrences.viewer",
                "members": [
                  "serviceAccount:${CLOUD_BUILD_SA_EMAIL}"
                ]
              },
              {
                "role": "roles/containeranalysis.notes.attacher",
                "members": [
                  "serviceAccount:${CLOUD_BUILD_SA_EMAIL}"
                ]
              }
            ]
          }
        }
    EOF
    
  3. QA 증명자를 만듭니다.

    gcloud container binauthz attestors create "qa-attestor" \
      --project "${PROJECT_ID}" \
      --attestation-authority-note-project "${PROJECT_ID}" \
      --attestation-authority-note "qa-note" \
      --description "QA attestor"
    
  4. 증명자의 서명 키에 대한 공개 키를 추가합니다.

    gcloud beta container binauthz attestors public-keys add \
      --project "${PROJECT_ID}" \
      --attestor "qa-attestor" \
      --keyversion "1" \
      --keyversion-key "qa-signer" \
      --keyversion-keyring "binauthz" \
      --keyversion-location "${REGION}" \
      --keyversion-project "${PROJECT_ID}"
    
  5. Cloud Build 서비스 계정에 qa-attestor에서 수행한 증명을 확인할 수 있는 권한을 부여합니다.

    gcloud container binauthz attestors add-iam-policy-binding "qa-attestor" \
      --project "${PROJECT_ID}" \
      --member "serviceAccount:${CLOUD_BUILD_SA_EMAIL}" \
      --role "roles/binaryauthorization.attestorsViewer"
    
  6. QA 팀에 증명에 서명할 수 있는 권한을 부여합니다.

    gcloud kms keys add-iam-policy-binding "qa-signer" \
      --project "${PROJECT_ID}" \
      --location "${REGION}" \
      --keyring "binauthz" \
      --member "group:qa-team@example.com" \
      --role 'roles/cloudkms.signerVerifier'
    

Binary Authorization 정책 설정

--enable-binauthz를 사용하여 GKE 클러스터를 만든 경우에도 클러스터에서 바이너리를 실행하는 데 필요한 증명에 대해 GKE에 지시하는 정책을 작성해야 합니다. Binary Authorization 정책은 프로젝트 수준에서 존재하지만 클러스터 수준의 구성을 포함합니다.

다음 정책은 아래와 같은 방식으로 기본 정책을 변경합니다.

  • 기본 evaluationModeALWAYS_DENY로 변경합니다. 필요한 증명이 포함된 예외 이미지 또는 이미지만 클러스터에서 실행할 수 있습니다.

  • Google에서 제공하는 시스템 이미지만 포함되도록 기본 허용 목록을 변경하는 globalPolicyEvaluationMode를 사용 설정합니다.

  • 다음 클러스터 허용 규칙을 정의합니다.

    • staging-cluster에는 vulnz-attestor의 증명이 필요합니다.

    • prod-cluster에는 vulnz-attestorqa-attestor의 증명이 필요합니다.

Binary Authorization 정책에 대한 자세한 내용은 정책 YAML 참조를 참조하세요.

  1. Cloud Shell에서 Cloud 프로젝트의 Binary Authorization 정책을 설명하는 YAML 파일을 만듭니다.

    cat > ./binauthz-policy.yaml <<EOF
    admissionWhitelistPatterns:
    - namePattern: docker.io/istio/*
    defaultAdmissionRule:
      enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
      evaluationMode: ALWAYS_DENY
    globalPolicyEvaluationMode: ENABLE
    clusterAdmissionRules:
      # Staging cluster
      ${REGION}.staging-cluster:
        evaluationMode: REQUIRE_ATTESTATION
        enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
        requireAttestationsBy:
        - projects/${PROJECT_ID}/attestors/vulnz-attestor
    
      # Production cluster
      ${REGION}.prod-cluster:
        evaluationMode: REQUIRE_ATTESTATION
        enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
        requireAttestationsBy:
        - projects/${PROJECT_ID}/attestors/vulnz-attestor
        - projects/${PROJECT_ID}/attestors/qa-attestor
    EOF
    
  2. 새 정책을 Cloud 프로젝트에 업로드합니다.

    gcloud container binauthz policy import ./binauthz-policy.yaml \
      --project "${PROJECT_ID}"
    

취약점 스캔 검사기 만들기 및 API 사용 설정

Cloud Build에서 빌드 단계로 사용되는 컨테이너 이미지를 만듭니다. 이 컨테이너는 감지된 취약점의 심각도 점수를 구성된 기준과 비교합니다. 점수가 기준 범위 내에 있으면 Cloud Build가 컨테이너에 증명을 만듭니다. 점수가 기준 범위를 벗어나면 빌드가 실패하고 증명이 생성되지 않습니다.

  1. Cloud Shell에서 Binary Authorization 도구와 샘플 애플리케이션 소스를 클론합니다.

    git clone https://github.com/GoogleCloudPlatform/gke-binary-auth-tools ~/binauthz-tools
    
  2. cloudbuild-attestor라는 취약점 스캔 증명자 컨테이너를 빌드하여 Container Registry로 푸시합니다.

    gcloud builds submit \
      --project "${PROJECT_ID}" \
      --tag "gcr.io/${PROJECT_ID}/cloudbuild-attestor" \
      ~/binauthz-tools
    
  3. 취약점 스캐너 API를 사용 설정합니다.

    gcloud services enable containerscanning.googleapis.com
    

Cloud Build 파이프라인 설정

샘플 앱 및 Kubernetes 매니페스트를 저장할 Cloud Source Repositories 저장소와 Cloud Build 트리거를 만듭니다.

hello-app Cloud Source Repositories 만들기

  1. Cloud Shell에서 샘플 앱을 저장할 Cloud Source Repositories 저장소를 만듭니다.

    gcloud source repos create hello-app \
      --project "${PROJECT_ID}"
    
  2. 로컬에서 저장소를 클론합니다.

    gcloud source repos clone hello-app ~/hello-app \
      --project "${PROJECT_ID}"
    
  3. 샘플 코드를 저장소에 복사합니다.

    cp -R ~/binauthz-tools/examples/hello-app/* ~/hello-app
    

hello-app Cloud Build 트리거 만들기

  1. Cloud Console에서 트리거 페이지로 이동합니다.

    트리거로 이동

  2. 트리거 만들기를 클릭합니다.

  3. 트리거 설정 창에서 다음 세부정보를 입력합니다.

    • 저장소 필드의 메뉴에서 hello-app을 선택합니다.
    • 이름 필드에 build-vulnz-deploy를 입력합니다.
    • 트리거 유형으로 분기를 선택합니다.
    • 분기(정규식) 필드에 main를 입력합니다.
    • 구성에서 Cloud Build 구성 파일(yaml 또는 json)을 선택합니다.
    • Cloud Build 구성 파일 위치 필드에 /cloudbuild.yaml(기본값)을 입력합니다.
  4. 다음 치환 변수 쌍을 추가합니다.

    • _COMPUTE_REGION과 값 us-central1(또는 앞에서 선택한 리전)
    • _KMS_KEYRING과 값 binauthz
    • _KMS_LOCATION과 값 us-central1(또는 앞에서 선택한 리전)
    • _PROD_CLUSTER와 값 prod-cluster
    • _QA_ATTESTOR와 값 qa-attestor
    • _QA_KMS_KEY와 값 qa-signer
    • _QA_KMS_KEY_VERSION와 값 1
    • _STAGING_CLUSTER와 값 staging-cluster
    • _VULNZ_ATTESTOR와 값 vulnz-attestor
    • _VULNZ_KMS_KEY와 값 vulnz-signer
    • _VULNZ_KMS_KEY_VERSION과 값 1
  5. 트리거 만들기를 클릭합니다.

Cloud Build 파이프라인 테스트

샘플 앱을 커밋하고 Cloud Source Repositories 저장소에 푸시하여 CI/CD 파이프라인을 테스트합니다. Cloud Build가 변경을 감지하고 앱을 빌드하여 staging-cluster에 배포합니다. 그러면 파이프라인은 QA 확인이 끝날 때까지 최대 10분 동안 대기합니다. QA 팀에서 배포 확인을 마치면 프로세스는 계속 진행되어 프로덕션 환경의 Kubernetes 매니페스트가 업데이트되고 Cloud Build는 앱을 prod-cluster에 배포합니다.

  1. Cloud Shell에서 hello-app 파일을 커밋하고 Cloud Source Repositories 저장소에 푸시하여 빌드를 트리거합니다.

    cd ~/hello-app
    
    git add .
    git commit -m "Initial commit"
    git push origin main
    
  2. Cloud Console에서 기록 페이지로 이동합니다.

    기록 페이지로 이동

  3. 빌드 진행 상황을 보려면 가장 최근 Cloud Build 실행을 클릭합니다.

    빌드 정보

  4. staging-cluster에 대한 배포가 완료되면 서비스 페이지로 이동합니다.

    서비스 페이지로 이동

  5. 앱이 정상적으로 실행되는지 확인하려면 해당 앱을 가리키는 엔드포인트 링크를 클릭합니다.

  6. 이미지 페이지로 이동합니다.

    이미지 페이지로 이동

  7. hello-app을 클릭합니다.

  8. 스테이징 배포에서 검증한 이미지를 클릭합니다.

    검증된 이미지 이름

  9. 다이제스트 세부정보 페이지의 이미지 세부정보에서 다이제스트 값을 복사합니다. 이 정보는 다음 단계에서 필요합니다.

    이미지의 다이제스트 값

  10. 수동으로 QA 증명을 적용합니다. 여기서 ...를 이미지 세부정보에서 복사한 값으로 바꿉니다. DIGEST 변수는 sha256:hash-value` 형식이어야 합니다.

    Await QA attestation 빌드 단계에서도 다음과 같이 복사하여 붙여넣을 수 있는 명령어를 출력합니다.

    DIGEST="sha256:..." # Replace with your value
    
    gcloud beta container binauthz attestations sign-and-create \
      --project "${PROJECT_ID}" \
      --artifact-url "gcr.io/${PROJECT_ID}/hello-app@${DIGEST}" \
      --attestor "qa-attestor" \
      --attestor-project "${PROJECT_ID}" \
      --keyversion "1" \
      --keyversion-key "qa-signer" \
      --keyversion-location "${REGION}" \
      --keyversion-keyring "binauthz" \
      --keyversion-project "${PROJECT_ID}"
    
  11. 앱이 배포되었는지 확인하려면 서비스 페이지로 이동합니다.

    서비스 페이지로 이동

  12. 앱을 보려면 엔드포인트 링크를 클릭합니다.

증명되지 않은 이미지 배포

지금까지 샘플 앱에는 취약점이 없었습니다. 이제 앱을 업데이트하여 다른 메시지를 출력하고 기본 이미지를 변경합니다.

  1. Cloud Shell에서 출력을 Hello World에서 Binary Authorization로, 기본 이미지를 distroless에서 debian을 변경합니다.

    cd ~/hello-app
    sed -i "s/Hello World/Binary Authorization/g" main.go
    sed -i "s/FROM gcr\.io\/distroless\/static/FROM debian/g" Dockerfile
    
  2. 변경사항을 커밋하고 푸시합니다.

    git add .
    git commit -m "Change message and base image"
    git push origin main
    
  3. CI/CD 파이프라인 상태를 모니터링하려면 Cloud Console에서 기록 페이지로 이동합니다.

    기록 페이지로 이동

    이미지에서 CVE가 감지되어 빌드가 중단됩니다.

  4. 감지된 CVE를 검사하려면 이미지 페이지로 이동합니다.

    이미지 페이지로 이동

  5. hello-app을 클릭합니다.

  6. 감지된 CVE를 살펴보려면 가장 최근 이미지의 취약점 요약을 클릭합니다.

    최근 이미지의 취약점 요약 링크

  7. Cloud Shell에서 취약점 스캔 증명 없이 프로덕션 환경에 대한 새로운 이미지 배포를 시도합니다.

    export SHA_DIGEST="[SHA_DIGEST_VALUE]"
    
    cd ~/hello-app
    sed "s/GOOGLE_CLOUD_PROJECT/${DEVSHELL_PROJECT_ID}/g" \
        kubernetes/deployment.yaml.tpl | sed -e  \
        "s/DIGEST/${SHA_DIGEST}/g" > kubernetes/deployment.yaml
    
    gcloud container clusters get-credentials \
        --project=${DEVSHELL_PROJECT_ID} \
        --region="${REGION}" prod-cluster
    
    kubectl apply -f kubernetes
    
  8. Cloud Console에서 워크로드 페이지로 이동합니다.

    워크로드 페이지로 이동

    이미지 오류 상태

    vulnz-attestorqa-attestor의 서명이 없기 때문에 이미지를 배포할 수 없습니다.

긴급 상황 처리 절차

간혹 정상적인 워크플로에서 벗어나는 변경을 허용해야 할 때가 있습니다. 필요한 증명 없이 이미지 배포를 허용할 경우 긴급 상황 정책 플래그가 pod 정의에 주석으로 표시됩니다. 이 플래그를 사용 설정하더라도 GKE가 계속해서 필요한 증명 유무를 검사하지만 컨테이너 이미지 배포를 허용하고 위반을 로깅합니다.

증명 확인을 우회하는 방법에 대한 자세한 내용은 정책 재정의를 참조하세요.

  1. Cloud Shell에서 Kubernetes 매니페스트의 긴급 상황 주석 처리를 삭제합니다.

    sed -i "31s/^#//" kubernetes/deployment.yaml
    
  2. kubectl을 사용하여 변경사항을 적용합니다.

    kubectl apply -f kubernetes
    
  3. 변경사항이 prod-cluster에 배포되었는지 확인하려면 Cloud Console에서 워크로드 페이지로 이동합니다.

    워크로드 페이지로 이동

    이제 배포 오류 메시지가 사라집니다.

  4. 앱이 배포되었는지 확인하려면 서비스 페이지로 이동합니다.

    서비스 페이지로 이동

  5. 앱을 보려면 엔드포인트 링크를 클릭합니다.

삭제

이 튜토리얼에서 사용된 리소스 비용이 Google Cloud 계정에 청구되지 않도록 하려면 리소스가 포함된 프로젝트를 삭제하거나 프로젝트를 유지하고 개별 리소스를 삭제하세요.

프로젝트 삭제

  1. Cloud Console에서 리소스 관리 페이지로 이동합니다.

    리소스 관리로 이동

  2. 프로젝트 목록에서 삭제할 프로젝트를 선택하고 삭제를 클릭합니다.
  3. 대화상자에서 프로젝트 ID를 입력한 후 종료를 클릭하여 프로젝트를 삭제합니다.

다음 단계