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

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

예를 들어 Binary Authorization에서는 앱의 단위 테스트 합격 여부 또는 앱 빌드 시 특정 시스템 세트 사용 여부 등을 확인할 수 있습니다. 자세한 내용은 Software Delivery Shield 개요를 참조하세요.

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

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

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

목표

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

비용

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

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

이 문서에 설명된 태스크를 완료했으면 만든 리소스를 삭제하여 청구가 계속되는 것을 방지할 수 있습니다. 자세한 내용은 삭제를 참조하세요.

시작하기 전에

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

Google Cloud Console의 프로젝트 선택기 페이지에서 Google Cloud 프로젝트를 선택하거나 만듭니다.

프로젝트 선택기로 이동

Google Cloud 프로젝트에 결제가 사용 설정되어 있는지 확인합니다.

API Binary Authorization, Cloud Build, Cloud KMS, GKE, Artifact Registry, Artifact Analysis, Resource Manager, and Cloud Source Repositories 사용 설정

API 사용 설정

Google Cloud Console의 프로젝트 선택기 페이지에서 Google Cloud 프로젝트를 선택하거나 만듭니다.

프로젝트 선택기로 이동

Google Cloud 프로젝트에 결제가 사용 설정되어 있는지 확인합니다.

API Binary Authorization, Cloud Build, Cloud KMS, GKE, Artifact Registry, Artifact Analysis, Resource Manager, and Cloud Source Repositories 사용 설정

API 사용 설정

Google Cloud 콘솔에서 Cloud Shell을 활성화합니다.

Cloud Shell 활성화

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

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

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

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

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

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

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

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

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

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

앱 소스 코드로 컨테이너 이미지 빌드
컨테이너 이미지를 Artifact Registry로 푸시
Artifact Analysis: 컨테이너 이미지를 스캔하여 알려진 보안 취약점 또는 CVE의 유무 확인

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

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

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

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

환경 설정

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

Cloud Shell에서 이 가이드에 사용된 모든 리소스를 배포하고 관리하는 Google Cloud 프로젝트를 설정합니다.
```
export PROJECT_ID="${DEVSHELL_PROJECT_ID}"
gcloud config set project ${PROJECT_ID}
```
다음 리소스를 배포할 리전을 설정합니다.
```
export REGION="us-central1"
```
GKE 클러스터와 Cloud KMS 키는 이 리전에 있습니다. 이 가이드에서 리전은 us-central1입니다. 리전에 대한 자세한 내용은 위치 및 리전을 참조하세요.

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

export PROJECT_NUMBER="$(gcloud projects describe "${PROJECT_ID}" \
  --format='value(projectNumber)')"

Cloud Build 서비스 계정 이메일을 설정합니다.

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

GKE 클러스터 만들기

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

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

gcloud container clusters create "staging-cluster" \
  --project "${PROJECT_ID}" \
  --machine-type "n1-standard-1" \
  --region "${REGION}" \
  --num-nodes "1" \
  --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE

프로덕션 환경에 배포할 GKE 클러스터를 만듭니다.

gcloud container clusters create "prod-cluster" \
  --project "${PROJECT_ID}" \
  --machine-type "n1-standard-1" \
  --region "${REGION}" \
  --num-nodes "1" \
  --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE

Cloud Build 서비스 계정에 GKE에 대한 배포 권한을 부여합니다.

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

서명 키 만들기

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

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

gcloud kms keyrings create "binauthz" \
  --project "${PROJECT_ID}" \
  --location "${REGION}"

취약점 스캔 증명을 서명하고 확인하는 데 사용할 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"

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 서비스 계정에 메모를 보고, 메모를 연결하고, 이전 단계의 키를 사용하여 증명자를 만들 수 있는 권한을 부여합니다.

취약점 스캐너 증명 만들기

Cloud Shell에서 vulnz-note라는 Artifact Analysis 메모를 만듭니다.

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

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

취약점 스캔 증명자를 만듭니다.

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"

증명자의 서명 키에 대한 공개 키를 추가합니다.

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}"

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"

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 증명 만들기

Cloud Shell에서 qa-note라는 Artifact Analysis 메모를 만듭니다.

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

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

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"

증명자의 서명 키에 대한 공개 키를 추가합니다.

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}"

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"

QA 팀에 증명에 서명할 수 있는 권한을 부여합니다.

참고: 다음은 그룹 또는 팀 별칭을 사용하여 권한을 부여하는 예시입니다. 개별 사용자를 추가할 수도 있습니다. 테스트할 팀 별칭이 없는 경우에는 구성원을 이메일 주소(예: user:you@example.com)로 바꿉니다.
```
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 정책 설정

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

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

기본 evaluationMode를 ALWAYS_DENY로 변경합니다. 필요한 증명이 포함된 예외 이미지 또는 이미지만 클러스터에서 실행할 수 있습니다.
Google에서 제공하는 시스템 이미지만 포함되도록 기본 허용 목록을 변경하는 globalPolicyEvaluationMode를 사용 설정합니다.
다음 클러스터 허용 규칙을 정의합니다.
- staging-cluster에는 vulnz-attestor의 증명이 필요합니다.
- prod-cluster에는 vulnz-attestor 및 qa-attestor의 증명이 필요합니다.

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

Cloud Shell에서 Google 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

새 정책을 Google Cloud 프로젝트에 업로드합니다.

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

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

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

Cloud Shell에서 증명자 이미지를 저장할 새 Artifact Registry 저장소를 만듭니다.

gcloud artifacts repositories create cloudbuild-helpers \
  --repository-format=DOCKER --location=${REGION}

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

git clone https://github.com/GoogleCloudPlatform/gke-binary-auth-tools ~/binauthz-tools

attestor라는 취약점 스캔 증명자 컨테이너를 빌드하여 cloudbuild-helpers Artifact Registry로 푸시합니다.

gcloud builds submit \
  --project "${PROJECT_ID}" \
  --tag "us-central1-docker.pkg.dev/${PROJECT_ID}/cloudbuild-helpers/attestor" \
  ~/binauthz-tools

Cloud Build 파이프라인 설정

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

hello-app Cloud Source Repositories 및 Artifact Registry 저장소 만들기

Cloud Shell에서 샘플 앱을 저장할 Cloud Source Repositories 저장소를 만듭니다.
```
gcloud source repos create hello-app \
  --project "${PROJECT_ID}"
```

로컬에서 저장소를 클론합니다.

gcloud source repos clone hello-app ~/hello-app \
  --project "${PROJECT_ID}"

샘플 코드를 저장소에 복사합니다.

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

애플리케이션 이미지를 저장할 새 Artifact Registry 저장소를 만듭니다.

gcloud artifacts repositories create applications \
  --repository-format=DOCKER --location=${REGION}

hello-app Cloud Build 트리거 만들기

Google Cloud 콘솔에서 트리거 페이지로 이동합니다.

트리거로 이동
저장소 관리를 클릭합니다.
hello-app 저장소에서 ...를 클릭하고 트리거 추가를 선택합니다.
트리거 설정 창에서 다음 세부정보를 입력합니다.
- 이름 필드에 build-vulnz-deploy를 입력합니다.
- 이벤트에서 분기로 푸시를 선택합니다.
- 저장소 필드의 메뉴에서 hello-app을 선택합니다.
- 분기 필드에 master를 입력합니다.
- 구성에서 Cloud Build 구성 파일(yaml 또는 json)을 선택합니다.
- 위치에서 저장소를 선택하고 기본값 /cloudbuild.yaml을 입력합니다.
다음 치환 변수 쌍을 추가합니다.
- _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
만들기를 클릭합니다.

Cloud Build 파이프라인 테스트

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

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

git add .
git commit -m "Initial commit"
git push origin master
```
Google Cloud 콘솔에서 기록 페이지로 이동합니다.

기록 페이지로 이동
빌드 진행 상황을 보려면 가장 최근 Cloud Build 실행을 클릭합니다.
staging-cluster에 대한 배포가 완료되면 서비스 페이지로 이동합니다.

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

이미지 페이지로 이동
applications를 클릭합니다.
hello-app을 클릭합니다.
스테이징 배포에서 검증한 이미지를 클릭합니다.
이미지 세부정보에서 다이제스트 값을 복사합니다. 이 정보는 다음 단계에서 필요합니다.

수동으로 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 "${REGION}-docker.pkg.dev/${PROJECT_ID}/applications/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}"

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

서비스 페이지로 이동
앱을 보려면 엔드포인트 링크를 클릭합니다.

증명되지 않은 이미지 배포

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

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-debian11/FROM debian/g" Dockerfile

변경사항을 커밋하고 푸시합니다.

git add .
git commit -m "Change message and base image"
git push origin master

CI/CD 파이프라인 상태를 모니터링하려면 Google Cloud 콘솔에서 기록 페이지로 이동합니다.

기록 페이지로 이동

이미지에서 CVE가 감지되어 빌드가 중단됩니다.
감지된 CVE를 검사하려면 이미지 페이지로 이동합니다.

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

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

export SHA_DIGEST="[SHA_DIGEST_VALUE]"

cd ~/hello-app
sed "s/REGION/${REGION}/g" kubernetes/deployment.yaml.tpl | \
    sed "s/GOOGLE_CLOUD_PROJECT/${PROJECT_ID}/g" | \
    sed -e "s/DIGEST/${SHA_DIGEST}/g" > kubernetes/deployment.yaml

gcloud container clusters get-credentials \
    --project=${PROJECT_ID} \
    --region="${REGION}" prod-cluster

kubectl apply -f kubernetes

Google Cloud 콘솔에서 워크로드 페이지로 이동합니다.

워크로드 페이지로 이동

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

긴급 상황 처리 절차

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

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

Cloud Shell에서 Kubernetes 매니페스트의 긴급 상황 주석 처리를 삭제합니다.
```
sed -i "31s/^#//" kubernetes/deployment.yaml
```
kubectl을 사용하여 변경사항을 적용합니다.
```
kubectl apply -f kubernetes
```
변경사항이 prod-cluster에 배포되었는지 확인하려면 Google Cloud 콘솔에서 워크로드 페이지로 이동합니다.

워크로드 페이지로 이동

이제 배포 오류 메시지가 사라집니다.
앱이 배포되었는지 확인하려면 서비스 페이지로 이동합니다.

서비스 페이지로 이동
앱을 보려면 엔드포인트 링크를 클릭합니다.

삭제

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

프로젝트 삭제

Google Cloud 콘솔에서 리소스 관리 페이지로 이동합니다.
리소스 관리로 이동
프로젝트 목록에서 삭제할 프로젝트를 선택하고 삭제를 클릭합니다.
대화상자에서 프로젝트 ID를 입력한 후 종료를 클릭하여 프로젝트를 삭제합니다.

다음 단계

컨테이너 빌드를 위한 권장사항
컨테이너화된 웹 애플리케이션 배포
Cloud Build를 사용한 GitOps 스타일 지속적 배포
관리형 기본 이미지
Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항 살펴보기. Cloud 아키텍처 센터 살펴보기