다중 프로젝트 설정 구성

이 튜토리얼에서는 다중 프로젝트 구성에서 Binary Authorization을 사용하는 방법을 설명합니다. 간단한 단일 프로젝트 구성은 Google Cloud CLI(GKE) 사용 시작하기를 참조하세요.

업무 분리를 설정하려면 다중 프로젝트 구성으로 Binary Authorization을 설정할 수 있습니다. 각 프로젝트의 목적에 대해서는 이 튜토리얼의 뒷 부분에 설명되어 있습니다.

목표

이 튜토리얼에서는 다음 작업을 수행합니다.

  1. 업무 분리를 지원하기 위해 배포(GKE), 증명자, 증명 관리를 위한 다른 프로젝트를 설정합니다.

  2. 증명을 요구하도록 Binary Authorization 정책의 기본 규칙을 구성합니다.

  3. 서명할 키 쌍을 만들고 나중에 증명을 확인합니다.

  4. Binary Authorization 시행자가 증명 확인을 위해 사용하는 증명자를 만듭니다.

  5. 예시 이미지를 서명하고 증명을 만듭니다.

  6. 예시 이미지를 배포하여 정책을 테스트합니다.

Identity and Access Management(IAM)를 통해 각 프로젝트의 적절한 액세스 제어를 구성해야 합니다.

추가적인 보안을 위해 VPC 서비스 제어를 사용하여 이 튜토리얼에서 만든 리소스를 안전하게 보호할 수 있습니다. 자세한 내용은 VPC 서비스 제어로 보안 설정을 참조하세요.

비용

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

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

시작하기 전에

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

  2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

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

  4. Install the Google Cloud CLI.

  5. To initialize the gcloud CLI, run the following command: 

    gcloud init

  6. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

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

  8. Install the Google Cloud CLI.

  9. To initialize the gcloud CLI, run the following command: 

    gcloud init
  10. GKE와의 상호작용을 위해 kubectl을 설치합니다.

배포자 프로젝트 설정

배포자 프로젝트는 사용자가 이미지를 배포하는 Google Kubernetes Engine(GKE) 클러스터 및 Binary Authorization이 배포 시에 적용하는 Binary Authorization 정책을 관리합니다. 환경의 크기, 복잡성 및 기타 요구사항에 따라 둘 이상의 배포자 프로젝트를 가질 수 있습니다.

배포자 프로젝트를 설정하려면 다음을 수행하세요.

  1. 아직 Google Cloud 콘솔에서 프로젝트를 만들고 결제를 사용 설정하지 않았다면 프로젝트를 만들고 결제를 사용 설정합니다.

  2. Identity and Access Management 메모: 배포자 프로젝트에는 GKE 클러스터가 포함됩니다. 이 프로젝트의 Identity and Access Management 구성은 이를 반영해야 합니다.

  3. Google Cloud 프로젝트 및 번호를 저장할 환경 변수를 설정합니다.

    DEPLOYER_PROJECT_ID=DEPLOYER_PROJECT_ID

    DEPLOYER_PROJECT_ID를 Google Cloud 프로젝트 ID로 바꿉니다.

    DEPLOYER_PROJECT_NUMBER=$(gcloud projects describe "${DEPLOYER_PROJECT_ID}" \
    --format="value(projectNumber)")

  4. API 사용 설정:

    Container Registry 

    gcloud --project=${DEPLOYER_PROJECT_ID} \
  services enable\
  container.googleapis.com\
  containerregistry.googleapis.com\
  binaryauthorization.googleapis.com

    Artifact Registry 

    gcloud --project=${DEPLOYER_PROJECT_ID} \
  services enable\
  container.googleapis.com\
  artifactregistry.googleapis.com\
  binaryauthorization.googleapis.com

  5. 배포자 프로젝트 서비스 계정 이름을 가져옵니다.

    DEPLOYER_SERVICE_ACCOUNT="service-${DEPLOYER_PROJECT_NUMBER}@gcp-sa-binaryauthorization.iam.gserviceaccount.com"

    증명자와 연결된 Artifact Analysis 메모에 대한 권한을 구성할 때 이후 단계에서 서비스 계정 이름을 사용합니다.

증명자 프로젝트 설정

증명자 프로젝트는 이미지 배포 준비 여부를 확인할 수 있는 증명자를 저장합니다. 승인 절차에서 신뢰할 수 있는 당사자에 대한 정보의 중앙 집중식 저장소 역할을 하는 단일 증명자 프로젝트가 있는 경우가 많습니다. 이를 통해 증명자의 ID를 확인하고 이를 관리하는 당사자에게만 액세스를 제한하는 데 필요한 보안 키를 중앙에서 관리할 수 있습니다.

증명자 프로젝트를 설정하려면 다음을 수행하세요.

  1. 아직 Google Cloud 콘솔에서 프로젝트를 만들고 결제를 사용 설정하지 않았다면 프로젝트를 만들고 결제를 사용 설정합니다.

  2. Identity and Access Management 메모: 이 프로젝트에는 증명자가 포함되어 있으므로 보안 담당자에게만 쓰기 액세스 권한이 있어야 합니다.

  3. 환경 변수를 설정하여 프로젝트 ID와 번호를 저장합니다.

    ATTESTOR_PROJECT_ID=ATTESTOR_PROJECT_ID

    ATTESTOR_PROJECT_ID를 증명자 프로젝트 ID로 바꿉니다.

    ATTESTOR_PROJECT_NUMBER=$(gcloud projects describe "${ATTESTOR_PROJECT_ID}" \
    --format="value(projectNumber)")

  4. Artifact Analysis 및 Binary Authorization API를 사용 설정합니다.

    gcloud services --project=${ATTESTOR_PROJECT_ID} \
    enable containeranalysis.googleapis.com \
    binaryauthorization.googleapis.com

  5. 증명자 프로젝트 서비스 계정 이름을 가져옵니다.

    ATTESTOR_SERVICE_ACCOUNT="service-${ATTESTOR_PROJECT_NUMBER}@gcp-sa-binaryauthorization.iam.gserviceaccount.com"

    증명자와 연결된 Artifact Analysis 메모에 대한 권한을 구성할 때 이후 단계에서 서비스 계정 이름을 사용합니다.

증명 프로젝트 설정

증명 프로젝트는 증명자가 이미지를 확인할 때 수행하는 attestations을 저장하는 프로젝트입니다. 별도의 증명 프로젝트를 사용하면 소프트웨어 준비에 대한 구문을 더 간편하게 구성하고 검사할 수 있습니다.

  1. 아직 Google Cloud 콘솔에서 프로젝트를 만들고 결제를 사용 설정하지 않았다면 프로젝트를 만들고 결제를 사용 설정합니다.

  2. Identity and Access Management 메모: Binary Authorization과 관련된 모든 역할에는 이 프로젝트의 Artifact Analysis 메모 및 일치하는 항목에 대한 읽기 액세스 권한이 있어야 하지만 증명 관리자에게만 쓰기 액세스 권한이 있어야 합니다.

  3. 프로젝트 이름을 저장할 환경 변수를 설정합니다.

    ATTESTATION_PROJECT_ID=ATTESTATION_PROJECT_ID

    ATTESTATION_PROJECT_ID를 증명 프로젝트 ID로 바꿉니다.

  4. Artifact Analysis 및 Binary Authorization API를 사용 설정합니다.

    gcloud services --project=${ATTESTATION_PROJECT_ID} \
    enable containeranalysis.googleapis.com \
    binaryauthorization.googleapis.com

클러스터 만들기

이제 배포자 프로젝트에서 GKE 클러스터를 만들 수 있습니다. 배포된 컨테이너 이미지를 실행할 클러스터입니다. 클러스터를 만들 때 --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE 플래그를 gcloud container clusters create 명령어에 전달합니다.

클러스터를 만들려면 다음을 입력하세요.

gcloud --project=${DEPLOYER_PROJECT_ID} \
    container clusters create \
    --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE \
    --zone us-central1-a \
    test-cluster

여기에서 GKE 영역 us-central1-a에 test-cluster라는 클러스터를 만듭니다.

kubectl 설치를 위해 로컬 kubeconfig 파일도 업데이트해야 합니다. 이 파일은 GKE에서 클러스터에 액세스하는 데 필요한 사용자 인증 정보와 엔드포인트 정보를 제공합니다.

로컬 kubeconfig 파일을 업데이트하려면 다음을 실행하세요.

gcloud --project=${DEPLOYER_PROJECT_ID} \
    container clusters get-credentials \
    --zone us-central1-a \
    test-cluster

증명자 만들기

증명자는 컨테이너 이미지를 배포하기 전에 필수 프로세스가 완료되었음을 증명할 책임이 있는 당사자입니다. 이 당사자는 사람 사용자 또는 빌드 및 테스트 시스템과 같은 머신 프로세스이거나 지속적 통합(CI) 및 배포(CD) 파이프라인일 수 있습니다. 증명자 프로젝트에서 증명자를 만듭니다.

증명자를 만들려면 다음을 수행해야 합니다.

  • Artifact Analysis에서 메모를 만들어 승인 프로세스에 사용된 신뢰할 수 있는 메타데이터 저장
  • 증명자 프로젝트에서 증명자를 만들고 생성한 메모를 연결
  • 배포자 프로젝트 서비스 계정의 IAM 역할 바인딩을 증명자에 추가
  • Artifact Analysis 메모에 대한 권한 설정

이 튜토리얼에서는 test-attestor라는 증명자 하나와 test-attestor-note라는 컨테이너 분석 메모를 사용합니다. 실제 시나리오에서는 제한 없이 증명자를 사용할 수 있으며, 각 증명자는 이미지의 승인 프로세스에 참여하는 당사자를 나타냅니다.

Artifact Analysis 메모 만들기

  1. 증명자 및 Artifact Analysis 메모의 이름을 저장할 변수를 설정합니다.

    ATTESTOR_NAME=test-attestor
NOTE_ID=test-attestor-note

    다음과 같이 바꿉니다.

    • test-attestor: 선택한 증명자 이름입니다.
    • test-attestor-note: 선택한 증명자 메모 이름입니다.

  2. /tmp/note_payload.json에 컨테이너 분석 메모를 설명하는 JSON 파일을 만듭니다.

    cat > /tmp/note_payload.json << EOM
{
  "name": "projects/${ATTESTOR_PROJECT_ID}/notes/${NOTE_ID}",
  "attestation": {
    "hint": {
      "human_readable_name": "Attestor Note"
    }
  }
}
EOM

  3. Artifact Analysis REST API에 HTTP 요청을 보내 메모를 만듭니다.

    curl -X POST \
    -H "Content-Type: application/json" \
    -H "Authorization: Bearer $(gcloud auth print-access-token)"  \
    --data-binary @/tmp/note_payload.json  \
    "https://containeranalysis.googleapis.com/v1/projects/${ATTESTOR_PROJECT_ID}/notes/?noteId=${NOTE_ID}"

  4. 메모가 생성되었는지 확인합니다.

    curl \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
"https://containeranalysis.googleapis.com/v1/projects/${ATTESTOR_PROJECT_ID}/notes/${NOTE_ID}"

증명자 만들기

이제 증명자를 만들 수 있습니다.

  1. Binary Authorization에서 증명자를 만듭니다.

    gcloud --project=${ATTESTOR_PROJECT_ID} \
    container binauthz attestors create ${ATTESTOR_NAME} \
    --attestation-authority-note=${NOTE_ID} \
    --attestation-authority-note-project=${ATTESTOR_PROJECT_ID}

  2. 증명자가 생성되었는지 확인합니다.

    gcloud --project=${ATTESTOR_PROJECT_ID} \
    container binauthz attestors list

생성된 증명자는 연결된 PKIX 키 쌍이 없이는 사용할 수 없습니다. PKIX 키 쌍은 아래에서 만듭니다.

배포자 프로젝트에 IAM 역할 바인딩 추가

배포자 프로젝트의 IAM 역할 바인딩을 증명자에 추가해야 합니다. 이는 Binary Authorization에서 프로젝트에 연결된 증명에 액세스할 수 있는 권한이 있는지 확인하기 위해 정책을 평가할 때 사용됩니다.

IAM 역할 바인딩을 추가하려면 다음을 실행하세요.

gcloud --project ${ATTESTOR_PROJECT_ID} \
    container binauthz attestors add-iam-policy-binding \
    "projects/${ATTESTOR_PROJECT_ID}/attestors/${ATTESTOR_NAME}" \
    --member="serviceAccount:${DEPLOYER_SERVICE_ACCOUNT}" \
    --role=roles/binaryauthorization.attestorsVerifier

Artifact Analysis 메모에 대한 권한 설정

또한 만든 Artifact Analysis 메모에 권한을 설정해야 합니다. 그래야 배포자 프로젝트와 증명자 프로젝트 모두에 액세스할 수 있습니다. 이렇게 하려면 메모의 IAM 정책을 업데이트하여 프로젝트 서비스 계정에 뷰어 액세스 권한을 할당합니다.

  1. 메모에 IAM 정책을 설정하는 데 필요한 정보가 포함된 JSON 파일을 생성합니다.

    cat > /tmp/iam_request.json << EOM
{
  'resource': 'projects/${ATTESTOR_PROJECT_ID}/notes/${NOTE_ID}',
  'policy': {
    'bindings': [
      {
        'role': 'roles/containeranalysis.notes.occurrences.viewer',
        'members': [
          'serviceAccount:${ATTESTOR_SERVICE_ACCOUNT}',
          'serviceAccount:${DEPLOYER_SERVICE_ACCOUNT}'
        ]
      }
    ]
  }
}
EOM

  2. 서비스 계정 및 요청된 액세스 역할을 생성된 메모의 IAM 정책에 추가합니다.

    curl -X POST  \
    -H "Content-Type: application/json" \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    --data-binary @/tmp/iam_request.json \
    "https://containeranalysis.googleapis.com/v1/projects/${ATTESTOR_PROJECT_ID}/notes/${NOTE_ID}:setIamPolicy"

PKIX 키 설정

Binary Authorization은 암호화 키를 사용하여 증명자의 ID를 안전하게 확인합니다. 이렇게 하면 확인된 당사자 만 컨테이너 이미지 승인에 참여할 수 있습니다. 키 쌍은 증명자가 증명을 디지털 서명하는 데 사용하는 비공개 키와 Binary Authorization 서비스에 저장된 대로 증명자에 추가하는 공개 키로 구성됩니다.

이 튜토리얼에서는 권장 타원 곡선 디지털 서명 알고리즘(ECDSA)을 사용하여 키 쌍을 만듭니다. 서명에 RSA 또는 PGP 키를 사용할 수도 있습니다. 서명 알고리즘에 대한 자세한 내용은 키 용도 및 알고리즘을 참조하세요.

Cloud Key Management Service(Cloud KMS)에서 생성되고 저장된 비대칭 키는 PKIX와 호환됩니다. PKIX 키 및 Cloud KMS 사용에 대한 자세한 내용은 CLI를 사용하여 증명자 만들기를 참조하세요.

키 쌍 생성

PKIX 키 쌍은 서명자가 증명을 디지털 서명하는 데 사용하는 비공개 키와 증명자에 추가하는 공개 키로 구성됩니다. Binary Authorization은 배포 시에 이 공개 키를 사용하여 비공개 키로 서명된 증명을 확인합니다.

  1. 비공개 키를 생성합니다.

    로컬 비대칭 PKIX 키 쌍을 새로 생성하여 파일에 저장하려면 다음 안내를 따르세요.

    PKIX(Cloud KMS)

    이 단계에서는 Cloud Key Management Service에서 생성되고 저장된 키를 사용하여 증명을 수행하는 방법을 보여줍니다.

    1. Cloud KMS에서 관리하는 키 쌍에 대한 정보를 저장하도록 환경 변수를 설정합니다.

      이미 키 쌍이 있으면 이러한 환경 변수를 설정하고 다음 단계를 건너뛸 수 있습니다.

      KMS_KEY_PROJECT_ID=KMS_KEY_PROJECT_ID
KMS_KEY_LOCATION=KMS_KEY_LOCATION
KMS_KEYRING_NAME=KMS_KEYRING_NAME
KMS_KEY_NAME=KMS_KEY_NAME
KMS_KEY_VERSION=KMS_KEY_VERSION

      다음을 바꿉니다.

      • KMS_KEY_PROJECT_ID: 키가 저장된 프로젝트의 ID입니다.
      • KMS_KEY_LOCATION: 키의 위치입니다.
      • KMS_KEYRING_NAME: 키링의 이름
      • KMS_KEY_NAME: 키의 이름
      • KMS_KEY_VERSION: 키 버전입니다.

    2. [선택사항] KMS 키를 설정합니다.

      1. 증명자에 저장할 수 있는 공개 키의 KMS 키를 만듭니다. 이 단계에서는 아래에서 사용할 환경 변수도 설정합니다.

        키를 만들고 환경 변수를 설정하려면 다음을 실행하세요.

        KMS_KEY_PROJECT_ID=${PROJECT_ID}
KMS_KEYRING_NAME=my-binauthz-keyring
KMS_KEY_NAME=my-binauthz-kms-key-name
KMS_KEY_LOCATION=global
KMS_KEY_PURPOSE=asymmetric-signing
KMS_KEY_ALGORITHM=ec-sign-p256-sha256
KMS_PROTECTION_LEVEL=software
KMS_KEY_VERSION=1

      2. KMS 키링을 만듭니다.

        gcloud kms keyrings create ${KMS_KEYRING_NAME} \
  --location ${KMS_KEY_LOCATION} \
  --project ${KMS_KEY_PROJECT_ID}

      3. 키를 만듭니다.

        gcloud kms keys create ${KMS_KEY_NAME} \
  --location ${KMS_KEY_LOCATION} \
  --keyring ${KMS_KEYRING_NAME}  \
  --purpose ${KMS_KEY_PURPOSE} \
  --default-algorithm ${KMS_KEY_ALGORITHM} \
  --protection-level ${KMS_PROTECTION_LEVEL} \
  --project ${KMS_KEY_PROJECT_ID}

        KMS 키 만들기에 대한 자세한 내용은 비대칭 키 만들기를 참조하세요.

    3. 공개 키를 증명자에 추가합니다.

      gcloud --project="${ATTESTOR_PROJECT_ID}" \
    container binauthz attestors public-keys add \
    --attestor="${ATTESTOR_NAME}" \
    --keyversion-project="${KMS_KEY_PROJECT_ID}" \
    --keyversion-location="${KMS_KEY_LOCATION}" \
    --keyversion-keyring="${KMS_KEYRING_NAME}" \
    --keyversion-key="${KMS_KEY_NAME}" \
    --keyversion="${KMS_KEY_VERSION}"

    PKIX(로컬 키)

    1. 비공개 키를 생성하려면 다음 명령어를 실행합니다.

      PRIVATE_KEY_FILE="/tmp/ec_private.pem"
openssl ecparam -genkey -name prime256v1 -noout -out ${PRIVATE_KEY_FILE}

      PRIVATE_KEY_FILE은 증명자에 저장된 비공개 키를 포함한 파일의 이름입니다.

    2. 비공개 키에서 공개 키를 추출하여 파일에 저장합니다.

      PUBLIC_KEY_FILE="/tmp/ec_public.pem"
openssl ec -in ${PRIVATE_KEY_FILE} -pubout -out ${PUBLIC_KEY_FILE}

      PUBLIC_KEY_FILE은 증명자에 저장된 공개 키를 포함하는 파일의 이름입니다.

    3. 내보낸 공개 키를 증명자에 추가하려면 다음 코드를 실행합니다.

      gcloud --project="${ATTESTOR_PROJECT_ID}" \
  container binauthz attestors public-keys add \
  --attestor="${ATTESTOR_NAME}" \
  --pkix-public-key-file=${PUBLIC_KEY_FILE} \
  --pkix-public-key-algorithm=ecdsa-p256-sha256

      Binary Authorization은 증명자의 공개 키를 사용하여 증명을 확인합니다.

정책 구성

이제 배포자 프로젝트에서 정책을 구성할 수 있습니다. 이 단계에서는 정책 YAML 파일을 로컬 시스템으로 내보내고 위에서 정의한 증명자의 증명을 요구하도록 기본 규칙을 수정합니다.

정책을 구성하려면 다음을 수행하세요.

  1. Google이 관리하는 시스템 이미지를 허용하고, evaluationMode를 REQUIRE_ATTESTATION으로 설정하고, 생성된 증명자를 참조하는 requireAttestationsBy라는 노드를 추가하는 새로운 정책 파일을 만듭니다.

    cat > /tmp/policy.yaml << EOM
    globalPolicyEvaluationMode: ENABLE
    defaultAdmissionRule:
      evaluationMode: REQUIRE_ATTESTATION
      enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
      requireAttestationsBy:
        - projects/${ATTESTOR_PROJECT_ID}/attestors/${ATTESTOR_NAME}
    name: projects/${DEPLOYER_PROJECT_ID}/policy
EOM

  2. 정책 YAML 파일을 Binary Authorization으로 가져옵니다.

    gcloud --project=${DEPLOYER_PROJECT_ID} \
    container binauthz policy import /tmp/policy.yaml

정책 구성에 대한 자세한 내용은 CLI를 사용하여 정책 구성을 참조하세요.

정책 테스트

이 튜토리얼에서는 Container Registry 및 Artifact Registry의 공개 'Hello World!' 이미지와 같은 증명을 만듭니다. 처음에는 필요한 증명이 존재하지 않기 때문에 시행자가 이미지 배포를 차단합니다.

이미지 배포를 시도하려면 다음을 실행하세요.

Container Registry 

kubectl run hello-server --image gcr.io/google-samples/hello-app:1.0 --port 8080

Artifact Registry 

kubectl run hello-server --image us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0 --port 8080

이제 Binary Authorization에서 배포를 차단했는지 확인합니다.

kubectl get pods

이 명령어는 이미지가 배포되지 않았음을 나타내는 다음 메시지를 출력합니다.

No resources found.

배포에 대한 세부정보를 확인할 수 있습니다.

kubectl get event --template \
'{{range.items}}{{"\033[0;36m"}}{{.reason}}:{{"\033[0m"}}\{{.message}}{{"\n"}}{{end}}'

다음과 비슷한 응답이 표시됩니다.

FailedCreate: Error creating: pods POD_NAME is forbidden: admission webhook "imagepolicywebhook.image-policy.k8s.io" denied the request: Image IMAGE_NAME denied by Binary Authorization default admission rule. Image IMAGE_NAME denied by attestor ATTESTOR_NAME: No attestations found

이 출력에서 각 항목의 의미는 다음과 같습니다.

  • POD_NAME: 포드의 이름입니다.
  • IMAGE_NAME: 이미지의 이름입니다.
  • ATTESTOR_NAME: 증명자의 이름입니다.

다음 단계를 진행하려면 배포를 삭제해야 합니다.

kubectl delete deployment hello-server

증명 만들기

증명은 파이프라인의 필수 프로세스가 완료되었고 문제의 컨테이너 이미지가 배포를 위해 승인되었다는 증명자의 구문입니다. 증명 자체는 컨테이너 이미지 레지스트리를 저장할 때 이미지 버전의 전체 경로와 증명자의 ID를 포함하는 디지털 서명 레코드입니다.

이 튜토리얼에서 증명에는 단순히 이미지 배포를 승인했음이 표시됩니다. 증명 프로젝트에서 증명을 만듭니다.

증명을 만들려면 다음 안내를 따르세요.

  1. 이미지의 레지스트리 경로와 다이제스트를 저장할 변수를 설정합니다.

    Container Registry 

    IMAGE_PATH="gcr.io/google-samples/hello-app"
IMAGE_DIGEST="sha256:c62ead5b8c15c231f9e786250b07909daf6c266d0fcddd93fea882eb722c3be4"

    Artifact Registry 

    IMAGE_PATH="us-docker.pkg.dev/google-samples/containers/gke/hello-app"
IMAGE_DIGEST="sha256:37e5287945774f27b418ce567cd77f4bbc9ef44a1bcd1a2312369f31f9cce567"
IMAGE_TO_ATTEST=${IMAGE_PATH}@${IMAGE_DIGEST}

  2. 증명 만들기

    PKIX Cloud KMS

    Cloud KMS 키를 사용하여 증명을 만들려면 다음 명령어를 실행합니다.

    gcloud beta container binauthz attestations sign-and-create \
    --project="${PROJECT_ID}" \
    --artifact-url="${IMAGE_TO_ATTEST}" \
    --attestor="${ATTESTOR_NAME}" \
    --attestor-project="${PROJECT_ID}" \
    --keyversion-project="${KMS_KEY_PROJECT_ID}" \
    --keyversion-location="${KMS_KEY_LOCATION}" \
    --keyversion-keyring="${KMS_KEYRING_NAME}" \
    --keyversion-key="${KMS_KEY_NAME}" \
    --keyversion="${KMS_KEY_VERSION}"

    PKIX(로컬 키)

    로컬 키를 사용하여 증명을 만들려면 다음을 수행합니다.

    1. 증명 페이로드를 생성합니다.

      gcloud --project=${ATTESTATION_PROJECT_ID} \
  container binauthz create-signature-payload \
  --artifact-url=${IMAGE_TO_ATTEST} > /tmp/generated_payload.json

      페이로드 JSON 파일에 포함되는 내용은 다음과 같습니다.

      Container Registry 

      {
"critical": {
  "identity": {
    "docker-reference": "gcr.io/google-samples/hello-app"
  },
  "image": {
    "docker-manifest-digest": "sha256:c62ead5b8c15c231f9e786250b07909daf6c266d0fcddd93fea
882eb722c3be4"
  },
  "type": "Google cloud binauthz container signature"
}
}

      Artifact Registry 

      {
"critical": {
  "identity": {
    "docker-reference": "us-docker.pkg.dev/google-samples/containers/gke/hello-app"
  },
  "image": {
    "docker-manifest-digest": "sha256:37e5287945774f27b418ce567cd77f4bbc9ef44a1bcd1a2312369f31f9cce567"
  },
  "type": "Google cloud binauthz container signature"
}
}

    2. 페이로드에 서명합니다.

      로컬 PKIX 파일을 사용하는 경우 로컬 PKIX 비공개 키로 페이로드에 서명하고 서명 파일을 출력합니다.

      openssl dgst -sha256 -sign ${PRIVATE_KEY_FILE} /tmp/generated_payload.json > /tmp/ec_signature

      출력 파일은 위에서 만든 페이로드 JSON 파일의 서명된 버전입니다.

    3. 증명자로부터 공개 키 ID를 가져옵니다.

      gcloud container binauthz attestors describe ATTESTOR_NAME 명령어를 사용하면 언제든지 공개 키 ID를 볼 수 있습니다.

      공개 키 ID를 환경 변수에 저장하려면 다음 명령어를 입력하세요.

      PUBLIC_KEY_ID=$(gcloud container binauthz attestors describe ${ATTESTOR_NAME} \
--format='value(userOwnedGrafeasNote.publicKeys[0].id)' --project ${ATTESTOR_PROJECT_ID})

    4. 증명을 만들고 검증합니다.

      gcloud container binauthz attestations create \
  --project="${ATTESTATION_PROJECT_ID}" \
  --artifact-url="${IMAGE_TO_ATTEST}" \
  --attestor="projects/${ATTESTOR_PROJECT_ID}/attestors/${ATTESTOR_NAME}" \
  --signature-file=/tmp/ec_signature \
  --public-key-id="${PUBLIC_KEY_ID}" \
  --validate

      validate 플래그는 정책에 구성된 증명자로 증명을 확인할 수 있는지 검사합니다.

  3. 증명이 생성되었는지 확인합니다.

    gcloud --project=${ATTESTATION_PROJECT_ID} \
    container binauthz attestations list \
    --attestor=$ATTESTOR_NAME --attestor-project=$ATTESTOR_PROJECT_ID

증명 만들기에 대한 자세한 내용은 증명 만들기를 참조하세요.

정책 다시 테스트

샘플 컨테이너 이미지를 클러스터에 배포하여 정책을 테스트합니다. Binary Authorization에서 다이제스트를 사용하여 증명을 조회하므로 이번에는 1.0 또는 latest와 같은 태그가 아닌 다이제스트를 사용하여 이미지를 배포해야 합니다. 여기에서는 이미지에 연결된 증명이 포함되기 때문에 Binary Authorization에서 이미지 배포가 허용됩니다.

이미지를 배포하려면 다음을 실행하세요.

kubectl run hello-server --image ${IMAGE_TO_ATTEST} --port 8080

이미지가 배포되었는지 확인하려면 다음을 실행하세요.

kubectl get pods

위 명령어가 반환하는 메시지는 다음과 같으며, 배포가 성공했음을 나타냅니다.

NAME                            READY     STATUS    RESTARTS   AGE
hello-server-579859fb5b-h2k8s   1/1       Running   0          1m

이제 컨테이너 이미지를 성공적으로 배포하고 설정이 작동하는지 확인했으므로 GKE에서 만든 클러스터를 삭제할 수 있습니다.

gcloud --project=${DEPLOYER_PROJECT_ID} \
    container clusters delete \
    --zone=us-central1-a \
    test-cluster

삭제

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

  1. GKE에서 만든 클러스터를 삭제합니다.

    gcloud container clusters delete \
    --zone=us-central1-a \
    test-cluster

  2. 이 튜토리얼에서 만든 Google Cloud 프로젝트를 삭제할 수도 있습니다.

다음 단계