이 튜토리얼에서는 다중 프로젝트 구성에서 Binary Authorization을 사용하는 방법을 설명합니다. 간단한 단일 프로젝트 구성은 Google Cloud CLI(GKE) 사용 시작하기를 참조하세요.
업무 분리를 설정하려면 다중 프로젝트 구성으로 Binary Authorization을 설정할 수 있습니다. 각 프로젝트의 목적에 대해서는 이 튜토리얼의 뒷 부분에 설명되어 있습니다.
목표
이 튜토리얼에서는 다음 작업을 수행합니다.업무 분리를 지원하기 위해 배포(GKE), 증명자, 증명 관리를 위한 다른 프로젝트를 설정합니다.
서명할 공개 키 인프라 (X.509) (PKIX) 키 쌍을 만들고 나중에 증명을 확인합니다.
Binary Authorization 시행자가 증명 확인을 위해 사용하는 증명자를 만듭니다.
예시 이미지를 서명하고 증명을 만듭니다.
예시 이미지를 배포하여 정책을 테스트합니다.
Identity and Access Management(IAM)를 통해 각 프로젝트의 적절한 액세스 제어를 구성해야 합니다.
추가적인 보안을 위해 VPC 서비스 제어를 사용하여 이 튜토리얼에서 만든 리소스를 안전하게 보호할 수 있습니다. 자세한 내용은 VPC 서비스 제어로 보안 설정을 참조하세요.
비용
이 문서에서는 비용이 청구될 수 있는 다음과 같은 Google Cloud 구성요소를 사용합니다.
- Artifact Registry or Container Registry
- Binary Authorization
- GKE
- Container Registry
- Optional: Cloud Key Management Service
프로젝트 사용량을 기준으로 예상 비용을 산출하려면 가격 계산기를 사용하세요.
시작하기 전에
- Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Make sure that billing is enabled for your Google Cloud project.
- Install the Google Cloud CLI.
-
To initialize the gcloud CLI, run the following command:
gcloud init
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Make sure that billing is enabled for your Google Cloud project.
- Install the Google Cloud CLI.
-
To initialize the gcloud CLI, run the following command:
gcloud init
- GKE와의 상호작용을 위해
kubectl
을 설치합니다.
배포자 프로젝트 설정
배포자 프로젝트는 사용자가 이미지를 배포하는 Google Kubernetes Engine(GKE) 클러스터 및 Binary Authorization이 배포 시에 적용하는 Binary Authorization 정책을 관리합니다. 환경의 크기, 복잡성 및 기타 요구사항에 따라 둘 이상의 배포자 프로젝트를 가질 수 있습니다.
배포자 프로젝트를 설정하려면 다음을 수행하세요.
아직 Google Cloud 콘솔에서 프로젝트를 만들고 결제를 사용 설정하지 않았다면 프로젝트를 만들고 결제를 사용 설정합니다.
Identity and Access Management 메모: 배포자 프로젝트에는 GKE 클러스터가 포함됩니다. 이 프로젝트의 Identity and Access Management 구성은 이를 반영해야 합니다.
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)")
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
배포자 프로젝트 서비스 계정 이름을 가져옵니다.
DEPLOYER_SERVICE_ACCOUNT="service-${DEPLOYER_PROJECT_NUMBER}@gcp-sa-binaryauthorization.iam.gserviceaccount.com"
증명자와 연결된 Artifact Analysis 메모에 대한 권한을 구성할 때 이후 단계에서 서비스 계정 이름을 사용합니다.
증명자 프로젝트 설정
증명자 프로젝트는 이미지 배포 준비 여부를 확인할 수 있는 증명자를 저장합니다. 승인 절차에서 신뢰할 수 있는 당사자에 대한 정보의 중앙 집중식 저장소 역할을 하는 단일 증명자 프로젝트가 있는 경우가 많습니다. 이를 통해 증명자의 ID를 확인하고 이를 관리하는 당사자에게만 액세스를 제한하는 데 필요한 보안 키를 중앙에서 관리할 수 있습니다.
증명자 프로젝트를 설정하려면 다음을 수행하세요.
아직 Google Cloud 콘솔에서 프로젝트를 만들고 결제를 사용 설정하지 않았다면 프로젝트를 만들고 결제를 사용 설정합니다.
Identity and Access Management 메모: 이 프로젝트에는 증명자가 포함되어 있으므로 보안 담당자에게만 쓰기 액세스 권한이 있어야 합니다.
환경 변수를 설정하여 프로젝트 ID와 번호를 저장합니다.
ATTESTOR_PROJECT_ID=ATTESTOR_PROJECT_ID
ATTESTOR_PROJECT_ID를 증명자 프로젝트 ID로 바꿉니다.
ATTESTOR_PROJECT_NUMBER=$(gcloud projects describe "${ATTESTOR_PROJECT_ID}" \ --format="value(projectNumber)")
Artifact Analysis 및 Binary Authorization API를 사용 설정합니다.
gcloud services --project=${ATTESTOR_PROJECT_ID} \ enable containeranalysis.googleapis.com \ binaryauthorization.googleapis.com
증명자 프로젝트 서비스 계정 이름을 가져옵니다.
ATTESTOR_SERVICE_ACCOUNT="service-${ATTESTOR_PROJECT_NUMBER}@gcp-sa-binaryauthorization.iam.gserviceaccount.com"
증명자와 연결된 Artifact Analysis 메모에 대한 권한을 구성할 때 이후 단계에서 서비스 계정 이름을 사용합니다.
증명 프로젝트 설정
증명 프로젝트는 증명자가 이미지를 확인할 때 수행하는 증명을 저장하는 프로젝트입니다. 별도의 증명 프로젝트를 사용하면 소프트웨어 준비에 대한 구문을 더 간편하게 구성하고 검사할 수 있습니다.
아직 Google Cloud 콘솔에서 프로젝트를 만들고 결제를 사용 설정하지 않았다면 프로젝트를 만들고 결제를 사용 설정합니다.
Identity and Access Management 메모: Binary Authorization과 관련된 모든 역할에는 이 프로젝트의 Artifact Analysis 메모 및 일치하는 항목에 대한 읽기 액세스 권한이 있어야 하지만 증명 관리자에게만 쓰기 액세스 권한이 있어야 합니다.
프로젝트 이름을 저장할 환경 변수를 설정합니다.
ATTESTATION_PROJECT_ID=ATTESTATION_PROJECT_ID
ATTESTATION_PROJECT_ID를 증명 프로젝트 ID로 바꿉니다.
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 메모 만들기
증명자 및 Artifact Analysis 메모의 이름을 저장할 변수를 설정합니다.
ATTESTOR_NAME=test-attestor NOTE_ID=test-attestor-note
다음과 같이 바꿉니다.
- test-attestor: 선택한 증명자 이름입니다.
- test-attestor-note: 선택한 증명자 메모 이름입니다.
/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
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}"
메모가 생성되었는지 확인합니다.
curl \ -H "Authorization: Bearer $(gcloud auth print-access-token)" \ "https://containeranalysis.googleapis.com/v1/projects/${ATTESTOR_PROJECT_ID}/notes/${NOTE_ID}"
증명자 만들기
이제 증명자를 만들 수 있습니다.
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}
증명자가 생성되었는지 확인합니다.
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 정책을 업데이트하여 프로젝트 서비스 계정에 뷰어 액세스 권한을 할당합니다.
메모에 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
서비스 계정 및 요청된 액세스 역할을 생성된 메모의 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은 배포 시에 이 공개 키를 사용하여 비공개 키로 서명된 증명을 확인합니다.
비공개 키를 생성합니다.
로컬 비대칭 PKIX 키 쌍을 새로 생성하여 파일에 저장하려면 다음 안내를 따르세요.
PKIX(Cloud KMS)
이 단계에서는 Cloud Key Management Service에서 생성되고 저장된 키를 사용하여 증명을 수행하는 방법을 보여줍니다.
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: 키 버전입니다.
[선택사항] KMS 키를 설정합니다.
증명자에 저장할 수 있는 공개 키의 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
KMS 키링을 만듭니다.
gcloud kms keyrings create ${KMS_KEYRING_NAME} \ --location ${KMS_KEY_LOCATION} \ --project ${KMS_KEY_PROJECT_ID}
키를 만듭니다.
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 키 만들기에 대한 자세한 내용은 비대칭 키 만들기를 참조하세요.
공개 키를 증명자에 추가합니다.
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(로컬 키)
비공개 키를 생성하려면 다음 명령어를 실행합니다.
PRIVATE_KEY_FILE="/tmp/ec_private.pem" openssl ecparam -genkey -name prime256v1 -noout -out ${PRIVATE_KEY_FILE}
PRIVATE_KEY_FILE은 증명자에 저장된 비공개 키를 포함한 파일의 이름입니다.
비공개 키에서 공개 키를 추출하여 파일에 저장합니다.
PUBLIC_KEY_FILE="/tmp/ec_public.pem" openssl ec -in ${PRIVATE_KEY_FILE} -pubout -out ${PUBLIC_KEY_FILE}
PUBLIC_KEY_FILE은 증명자에 저장된 공개 키를 포함한 파일의 이름입니다.
내보낸 공개 키를 증명자에 추가하려면 다음 코드를 실행합니다.
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 파일을 로컬 시스템으로 내보내고 위에서 정의한 증명자의 증명을 요구하도록 기본 규칙을 수정합니다.
정책을 구성하려면 다음을 수행하세요.
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
정책 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를 포함하는 디지털 서명 레코드입니다.
이 튜토리얼에서 증명에는 단순히 이미지 배포를 승인했음이 표시됩니다. 증명 프로젝트에서 증명을 만듭니다.
증명을 만들려면 다음 안내를 따르세요.
이미지의 레지스트리 경로와 다이제스트를 저장할 변수를 설정합니다.
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}
증명 만들기
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(로컬 키)
로컬 키를 사용하여 증명을 만들려면 다음 단계를 따르세요.
증명 페이로드를 생성합니다.
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" } }
페이로드에 서명합니다.
로컬 PKIX 파일을 사용하는 경우 로컬 PKIX 비공개 키로 페이로드에 서명하고 서명 파일을 출력합니다.
openssl dgst -sha256 -sign ${PRIVATE_KEY_FILE} /tmp/generated_payload.json > /tmp/ec_signature
출력 파일은 위에서 만든 페이로드 JSON 파일의 서명된 버전입니다.
증명자로부터 공개 키 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})
증명을 만들고 검증합니다.
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
플래그는 정책에 구성된 증명자로 증명을 확인할 수 있는지 검사합니다.
증명이 생성되었는지 확인합니다.
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 계정에 청구되지 않도록 하려면 리소스가 포함된 프로젝트를 삭제하거나 프로젝트를 유지하고 개별 리소스를 삭제하세요.
GKE에서 만든 클러스터를 삭제합니다.
gcloud container clusters delete \ --zone=us-central1-a \ test-cluster
이 튜토리얼에서 만든 Google Cloud 프로젝트를 삭제할 수도 있습니다.