이 튜토리얼에서는 증명이 필요한 Binary Authorization 정책을 구성하고 테스트하는 방법을 보여줍니다. 이 정책 유형은 Google Kubernetes Engine(GKE)에 컨테이너 이미지를 배포할 수 있는 사용자 및 GKE에 배포할 수 있는 컨테이너 이미지를 정의하여 컨테이너 기반 소프트웨어 공급망을 보호합니다.
Binary Authorization은 배포 시에 증명자를 사용하여 증명에서 디지털 서명을 확인합니다. 증명은 빌드 프로세스의 일부로 서명자가 생성하였습니다.
이 튜토리얼에서 GKE 클러스터, 증명, 증명자는 모두 단일 프로젝트에 위치합니다. 단일 프로젝트 구성은 주로 서비스를 테스트하거나 실험하는 데 유용합니다. 실제 예시를 더 보려면 다중 프로젝트 구성을 참조하세요.
아래의 단계에서는 Google Cloud 콘솔에서 수행하는 작업과 gcloud 명령어를 사용하여 수행하는 작업을 설명합니다. gcloud를 사용하여 이러한 단계를 수행하려면 Google Cloud CLI를 사용하여 시작하기를 참조하세요.
목표
이 튜토리얼에서는 다음을 수행하는 방법을 알아봅니다.
- Binary Authorization이 사용 설정된 (GKE) 클러스터 만들기
- Binary Authorization 시행자가 증명의 서명을 확인하는 데 사용하는 증명자 만들기
- 증명이 필요한 정책 구성
- 암호화 키 쌍을 만들어 증명을 서명한 후 나중에 확인
- 컨테이너 이미지 다이제스트에 서명하여 서명 만들기
- 서명을 사용하여 증명 만들기
- GKE에 컨테이너 이미지를 배포하여 정책 테스트
비용
이 문서에서는 비용이 청구될 수 있는 다음과 같은 Google Cloud 구성요소를 사용합니다.
- Artifact 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.
-
Enable the Container Registry, Artifact Analysis and Binary Authorization APIs.
- 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.
-
Enable the Container Registry, Artifact Analysis and Binary Authorization APIs.
- Install the Google Cloud CLI.
-
To initialize the gcloud CLI, run the following command:
gcloud init kubectl을 설치합니다.
기본 프로젝트 설정
다음 명령어를 사용하려면 다음과 같이 Google Cloud 프로젝트 ID를 환경 변수에 저장합니다.
PROJECT_ID=PROJECT_ID
여기서 PROJECT_ID는 프로젝트 이름입니다.
기본 프로젝트가 선택되지 않은 경우 지금 설정합니다.
gcloud config set project ${PROJECT_ID}
Binary Authorization이 사용 설정된 클러스터 만들기
클러스터 만들기
이제 Binary Authorization이 사용 설정된 GKE 클러스터를 만들 수 있습니다. 여기에서 GKE 영역 us-central1-a에 test-cluster라는 클러스터를 만듭니다.
클러스터를 만들려면 다음 단계를 따르세요.
Google Cloud Console에서 GKE 메뉴로 이동합니다.
클러스터 만들기를 클릭합니다.
이름 필드에
test-cluster를 입력합니다.위치 유형 옵션에서 영역을 선택합니다.
영역 드롭다운 목록에서
us-central1-a를 선택합니다.가용성, 네트워킹, 보안, 추가 기능을 클릭합니다.
보안 섹션에서 Binary Authorization 사용 설정을 선택합니다.
시행 전용을 선택합니다.
만들기를 클릭합니다.
kubectl 구성
kubectl 설치를 위해 로컬 kubeconfig 파일도 업데이트해야 합니다. 이 파일은 GKE에서 클러스터에 액세스하는 데 필요한 사용자 인증 정보와 엔드포인트 정보를 제공합니다.
로컬 kubeconfig 파일을 업데이트하려면 다음 단계를 따르세요.
gcloud container clusters get-credentials \
--zone us-central1-a \
test-cluster
기본 정책 보기
Binary Authorization의 정책은 컨테이너 이미지의 배포를 제어하는 규칙 집합입니다. 정책은 프로젝트당 하나만 사용할 수 있습니다. 기본적으로 정책은 모든 컨테이너 이미지를 배포하도록 구성됩니다.
기본 정책을 보려면 다음 단계를 수행합니다.
Google Cloud 콘솔의 Binary Authorization 페이지로 이동합니다.
정책 수정을 클릭합니다.
프로젝트 기본 규칙에 모든 이미지 허용 옵션이 표시됩니다.
정책 저장을 클릭합니다.
증명자 만들기
증명자는 배포 시 Binary Authorization 시행자가 GKE에서 서명된 컨테이너 이미지를 배포하도록 허용할지 여부를 결정하는 확인 권한입니다. 증명자는 공개 키를 포함하며 일반적으로 소프트웨어 공급망 보안을 담당하는 직원이 관리합니다.
증명자를 만들려면 다음을 수행해야 합니다.
- Binary Authorization에서 증명자를 만듭니다.
- Artifact Analysis에서 연결된 증명자 메모를 자동 생성하여 승인 프로세스에 사용된 신뢰할 수 있는 증명 메타데이터를 저장합니다.
이 튜토리얼에서는 test-attestor라는 증명자 하나를 사용합니다. 실제 시나리오에서는 제한 없이 증명자를 사용할 수 있으며, 각 증명자는 이미지의 승인 프로세스에 참여하는 당사자를 나타냅니다.
키 쌍 생성
Binary Authorization은 암호화 키를 사용하여 서명자의 ID를 안전하게 확인합니다. 이렇게 하면 승인된 컨테이너 이미지만 배포할 수 있습니다. 키 쌍은 비공개 키와 공개 키로 구성됩니다. 서명자는 비공개 키를 사용하여 컨테이너 이미지 다이제스트를 서명합니다. 그러면 증명에 저장되는 서명이 생성됩니다. 공개 키는 증명자에 저장됩니다. 배포 시 Binary Authorization 시행자는 증명자의 공개 키를 사용하여 컨테이너의 배포를 허용하기 전에 증명의 서명을 확인합니다.
이 튜토리얼에서는 암호화 키에 공개 키 인프라(X.509)(PKIX) 형식을 사용합니다. 이 튜토리얼에서는 PKIX 키 쌍을 생성하는 데 타원 곡선 디지털 서명 알고리즘(ECDSA) 사용이 권장됩니다. 서명에 RSA 또는 PGP 키를 사용할 수도 있습니다. 서명 알고리즘에 대한 자세한 내용은 키 용도 및 알고리즘을 참조하세요.
Cloud Key Management Service(Cloud KMS)에서 생성하여 저장된 키는 PKIX와 호환되는 형식입니다. PKIX 키 및 Cloud KMS 사용에 대한 자세한 내용은 CLI를 사용하여 증명자 만들기를 참조하세요.
PKIX 키 쌍을 생성하려면 다음을 수행합니다.
비공개 키를 만듭니다.
PRIVATE_KEY_FILE="/tmp/ec_private.pem" openssl ecparam -genkey -name prime256v1 -noout -out ${PRIVATE_KEY_FILE}비공개 키에서 공개 키를 추출합니다.
PUBLIC_KEY_FILE="/tmp/ec_public.pem" openssl ec -in ${PRIVATE_KEY_FILE} -pubout -out ${PUBLIC_KEY_FILE}
증명자 만들기
이제 Binary Authorization에서 증명자를 만들고 생성한 공개 키를 연결할 수 있습니다.
증명자를 만들려면 다음을 수행합니다.
Google Cloud 콘솔의 Binary Authorization 페이지로 돌아갑니다.
증명자 탭에서 만들기를 클릭합니다.
다음과 같이 필드를 작성합니다.
증명자 이름 필드에
test-attestor를 입력합니다.Artifact Analysis 메모 자동 생성이 선택되어 있는지 확인합니다.
PKIX 공개 키 추가를 클릭합니다.
텍스트 편집기에서
/tmp/ec_public.pem를 엽니다. 이 파일은 이전 단계에서 만든 공개 키 파일입니다. 파일의 콘텐츠를 공개 키 자료 텍스트 상자에 복사합니다.서명 알고리즘 풀다운 메뉴에서
Elliptic Curve P-256 - SHA256 Digest를 클릭합니다.완료를 클릭합니다.
만들기를 클릭하여 증명자를 만듭니다.
공개 키 ID를 저장합니다.
증명자의 공개 키 ID를 증명자에 추가한 후 보려면
gcloud container binauthz attestors describe ${ATTESTOR_NAME}를 사용하세요. 공개 키 ID를 저장할 환경 변수를 만들려면 다음 명령어를 실행합니다.ATTESTOR_NAME=test-attestor PUBLIC_KEY_ID=$(gcloud container binauthz attestors describe ${ATTESTOR_NAME}\ --format='value(userOwnedGrafeasNote.publicKeys[0].id)')
정책 구성
이제 정책을 구성할 수 있습니다.
Google Cloud 콘솔의 Binary Authorization 페이지로 돌아갑니다.
정책 탭에서 정책 수정을 클릭합니다.
다음의 모든 증명자가 승인한 이미지만 허용을 선택합니다.
증명자 추가를 클릭합니다.
프로젝트 및 증명자 이름으로 추가를 클릭합니다.
프로젝트 이름 필드에 PROJECT_ID을 입력합니다.
증명자 이름 필드에
test-attestor를 입력합니다.증명자 1개 추가를 클릭합니다.
정책 저장을 클릭합니다.
자세한 내용은 콘솔을 사용하여 정책 구성을 참조하세요.
정책 테스트
클러스터에 샘플 컨테이너 이미지 배포를 시도하여 위에서 구성한 정책을 테스트할 수 있습니다. 필요한 증명이 적용되지 않은 경우 정책에서 배포를 차단합니다.
이 튜토리얼에서는 Container Registry 및 Artifact Registry의 샘플 이미지를 사용할 수 있습니다. Container Registry의 이미지는 gcr.io/google-samples/hello-app:1.0 경로에 있습니다. Artifact Registry의 이미지는 us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0 경로에 있습니다.
두 경로 모두 'Hello, World!' 샘플 애플리케이션이 포함된 Google에서 생성된 공개 이미지를 포함합니다.
이미지를 배포하려면 다음 명령어를 실행합니다.
kubectl run hello-server --image gcr.io/google-samples/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_NAME: No attestations found
이 출력에서 각 항목의 의미는 다음과 같습니다.
- POD_NAME: 포드의 이름입니다.
- IMAGE_NAME: 이미지의 이름입니다.
- ATTESTOR_NAME: 증명자의 이름입니다.
다음 단계를 진행하려면 배포를 삭제해야 합니다.
kubectl delete deployment hello-server
증명 만들기
증명은 서명자가 만든 디지털 문서로, GKE에서 연결된 컨테이너 이미지를 배포할 수 있는지 여부를 인증합니다. 증명을 만드는 프로세스는 '이미지 서명'이라고도 합니다.
이 튜토리얼에서는 Container Registry 및 Artifact Registry의 예시 이미지에 대해 증명을 만듭니다.
증명을 만들려면 다음을 수행합니다.
이미지의 레지스트리 경로 및 다이제스트와 증명자 이름을 저장할 변수를 설정합니다.
Container Registry
IMAGE_PATH="gcr.io/google-samples/hello-app" IMAGE_DIGEST="sha256:c62ead5b8c15c231f9e786250b07909daf6c266d0fcddd93fea882eb722c3be4" ATTESTOR="test-attestor" IMAGE_TO_ATTEST=${IMAGE_PATH}@${IMAGE_DIGEST}Artifact Registry
IMAGE_PATH="us-docker.pkg.dev/google-samples/containers/gke/hello-app" IMAGE_DIGEST="sha256:37e5287945774f27b418ce567cd77f4bbc9ef44a1bcd1a2312369f31f9cce567" ATTESTOR="test-attestor" IMAGE_TO_ATTEST=${IMAGE_PATH}@${IMAGE_DIGEST}증명 페이로드를 생성합니다.
Container Registry
gcloud container binauthz create-signature-payload \ --artifact-url=${IMAGE_PATH}@${IMAGE_DIGEST} > /tmp/generated_payload.json페이로드 JSON 파일에 포함되는 내용은 다음과 같습니다.
{ "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
gcloud container binauthz create-signature-payload \ --artifact-url=${IMAGE_PATH}@${IMAGE_DIGEST} > /tmp/generated_payload.json페이로드 JSON 파일에 포함되는 내용은 다음과 같습니다.
{ "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 비공개 키로 페이로드를 서명하고 서명 파일을 출력합니다.
openssl dgst -sha256 -sign ${PRIVATE_KEY_FILE} /tmp/generated_payload.json > /tmp/ec_signature서명 파일은 위에서 만든 페이로드 JSON 파일의 디지털 서명 버전입니다.
증명을 만들고 검증합니다.
gcloud container binauthz attestations create \ --project="${PROJECT_ID}" \ --artifact-url="${IMAGE_TO_ATTEST}" \ --attestor="projects/${PROJECT_ID}/attestors/${ATTESTOR_NAME}" \ --signature-file=/tmp/ec_signature \ --public-key-id="${PUBLIC_KEY_ID}" \ --validate여기서
PUBLIC_KEY_ID는 위의 PKIX 키 쌍 생성에서 찾은 공개 키 ID입니다.validate플래그는 정책에 구성된 증명자로 증명을 확인할 수 있는지 검사합니다.증명이 생성되었는지 확인합니다.
gcloud container binauthz attestations list \ --attestor=$ATTESTOR_NAME --attestor-project=$PROJECT_ID
증명 만들기에 대한 자세한 내용은 증명 만들기를 참조하세요.
정책 다시 테스트
다시 샘플 컨테이너 이미지를 클러스터에 배포하여 정책을 테스트합니다.
Binary Authorization에서 다이제스트를 사용하여 증명을 조회하므로 이번에는 1.0 또는 latest와 같은 태그가 아닌 다이제스트를 사용하여 이미지를 배포해야 합니다. 여기에서는 필요한 증명이 적용되었으므로 Binary Authorization을 통해 이미지를 배포할 수 있습니다.
이미지를 배포하려면 다음 명령어를 실행합니다.
kubectl run hello-server --image ${IMAGE_PATH}@${IMAGE_DIGEST} --port 8080
이미지가 배포되었는지 확인하려면 다음 명령어를 실행합니다.
kubectl get pods
위 명령어가 반환하는 메시지는 다음과 같으며, 배포가 성공했음을 나타냅니다.
NAME READY STATUS RESTARTS AGE hello-server-579859fb5b-h2k8s 1/1 Running 0 1m
포드를 삭제하려면 다음 명령어를 실행합니다.
kubectl delete pod hello-server
삭제
이 튜토리얼에서 사용된 리소스 비용이 Google Cloud 계정에 청구되지 않도록 하려면 리소스가 포함된 프로젝트를 삭제하거나 프로젝트를 유지하고 개별 리소스를 삭제하세요.
GKE에서 만든 클러스터를 삭제합니다.
gcloud container clusters delete \
--zone=us-central1-a \
test-cluster