Kritis 서명자로 증명 만들기

이 튜토리얼에서는 Kritis 서명자를 빌드하고, 증명을 만들기 전에 이를 사용하여 Binary Authorization 컨테이너 이미지의 취약점을 검사하는 방법을 설명합니다.

개요

Kritis 서명자는 사용자가 구성한 정책에 따라 Binary Authorization 증명을 만들 수 있는 오픈소스 명령줄 도구입니다. 이미지에서 Artifact Analysis에서 식별한 취약점을 검사한 후 Kritis 서명자를 사용하여 증명을 만들 수도 있습니다.

또한 Cloud Build는 빌드 파이프라인에서 Kritis 서명자를 커스텀 빌더로 실행할 수 있습니다.

이 튜토리얼에서는 Kritis 서명자 커스텀 빌더를 한 번 빌드한 다음 샘플 빌드 파이프라인을 실행합니다. 각 샘플 파이프라인에는 다음 빌드 단계가 포함됩니다.

샘플 컨테이너 이미지를 빌드합니다.
이미지를 Container Registry로 내보내기
이미지 검사 및 서명: Kritis 서명자를 사용하여 정책에 따라 증명을 만듭니다.

Kritis 서명자는 각 파이프라인의 빌드 검사 및 서명 단계에서 다음을 수행합니다.

Artifact Analysis로 새로 빌드된 이미지를 스캔하고 취약점 목록을 검색합니다.
정책의 취약점 서명 규칙을 기준으로 취약점 목록을 검사한 후 다음을 수행합니다.
1. 식별된 모든 취약점이 취약점 서명 규칙을 충족하면 Kritis 서명자가 증명을 만듭니다.
2. 식별된 취약점이 취약점 서명 규칙을 위반하는 경우 Kritis 서명자가 증명을 만들지 않습니다.

Binary Authorization 시행자는 배포 시 검증 가능한 증명을 검사합니다. 이러한 증명이 없으면 시행자가 이미지 배포를 허용하지 않습니다.

또한 이 튜토리얼에서는 Cloud Build 파이프라인에서 Kritis 서명자를 검사 전용 모드로 실행하는 방법을 설명합니다. 이 모드에서는 Kritis 서명자가 증명을 만들지 않고 취약점 결과가 정책의 취약점 서명 규칙을 충족하는지만 확인합니다. 충족할 경우 Kritis 서명자 빌드 단계가 성공하고 파이프라인이 계속 실행되고 그렇지 않으면 단계가 실패하고 파이프라인이 종료됩니다.

목표

이 가이드에서는 다음과 같은 작업을 수행하게 됩니다.

Kritis 서명자를 Cloud Build 커스텀 빌더로 설정합니다.
취약점 서명 규칙이 포함된 정책을 확인합니다.
취약점 스캔 결과를 기반으로 증명 만들기에서 Kritis 서명자를 실행합니다.
Kritis 서명자를 검사 전용 모드로 실행합니다.

비용

이 튜토리얼에서는 다음 Google Cloud 제품을 사용합니다.

Container Registry
Artifact Analysis
Cloud Build
Cloud Key Management Service

가격 계산기를 사용하면 예상 사용량을 토대로 예상 비용을 산출할 수 있습니다.

시작하기 전에

이 섹션에서는 시스템 1회 설정을 수행합니다.

환경 설정

환경 변수에 Google Cloud 프로젝트를 저장합니다.

참고: 이 Google Cloud 프로젝트는 이 튜토리얼 전체에서 사용됩니다.
```
export PROJECT_ID=PROJECT_ID
```
PROJECT_ID를 Google Cloud 프로젝트 ID로 바꿉니다.
기본 프로젝트 ID를 Google Cloud 프로젝트로 설정합니다.
```
gcloud config set project $PROJECT_ID
```

다음 단계에서 프로젝트 번호를 환경 변수에 저장합니다.

export PROJECT_NUMBER=$(gcloud projects list --filter="${PROJECT_ID}" \
 --format="value(PROJECT_NUMBER)")

API 사용 설정:

이 가이드에 필요한 서비스가 사용 설정되어 있는지 확인하려면 다음 명령어를 실행합니다.

gcloud services enable \
  cloudbuild.googleapis.com \
  containerregistry.googleapis.com \
  containerscanning.googleapis.com \
  cloudkms.googleapis.com

IAM 역할 설정

다음 명령어를 실행하여 Cloud Build 서비스 계정을 다음 역할로 구성합니다.

containeranalysis.notes.editor: 증명자를 관리하기는 Artifact Analysis 메모 편집자 역할을 추가합니다.
containeranalysis.notes.occurrences.viewer: 취약점과 증명 어커런스를 모두 관리하는 메모용 Artifact Analysis 어커런스 역할을 추가합니다.
roles/containeranalysis.occurrences.editor: Artifact Analysis에 증명 어커런스를 만드는 Artifact Analysis 어커런스 편집자 역할을 추가합니다.

cloudkms.signer: 서비스 계정이 Cloud KMS 서명 서비스에 액세스할 수 있도록 허용하는 Cloud KMS CryptoKey 서명자 역할을 추가합니다.

gcloud projects add-iam-policy-binding $PROJECT_ID --member serviceAccount:$PROJECT_NUMBER@cloudbuild.gserviceaccount.com --role roles/containeranalysis.notes.editor
gcloud projects add-iam-policy-binding $PROJECT_ID --member serviceAccount:$PROJECT_NUMBER@cloudbuild.gserviceaccount.com --role roles/containeranalysis.notes.occurrences.viewer
gcloud projects add-iam-policy-binding $PROJECT_ID --member serviceAccount:$PROJECT_NUMBER@cloudbuild.gserviceaccount.com --role roles/containeranalysis.occurrences.editor
gcloud projects add-iam-policy-binding $PROJECT_ID --member serviceAccount:$PROJECT_NUMBER@cloudbuild.gserviceaccount.com --role roles/cloudkms.signer

Kritis Signer 커스텀 빌더 설정

이 섹션에서는 Kritis 서명자 커스텀 빌더의 일회성 설정을 수행합니다. Kritis 서명자를 가져와서 빌드하고 푸시하면 모든 Cloud Build 파이프라인에서 사용할 수 있습니다.

이 섹션에서는 다음 방법을 보여줍니다.

Kritis 저장소를 클론합니다.
Kritis 서명자 Cloud Build 커스텀 빌더 빌드
Cloud Build 빌드 단계로 사용할 수 있도록 Kritis Signer를 Container Registry로 푸시합니다.

다음 명령어를 실행하여 이 가이드에서 사용된 코드와 구성 파일을 가져옵니다.

Kritis 저장소를 클론합니다.
```
git clone https://github.com/grafeas/kritis.git
```
이 저장소에는 다음이 포함됩니다.
- Kritis 서명자도 포함된 Kritis의 소스 코드
- Cloud Build에서 Kritis Signer 커스텀 빌더를 빌드하는 데 사용되는 Cloud Build 구성 파일
- 취약점 서명 규칙이 포함된 정책 예시
- Cloud Build 구성 파일 예시 각 구성 파일은 취약점 스캔 파이프라인에서 Kritis 서명자를 사용합니다.
kritis/ 디렉터리로 이동합니다.
```
cd kritis
```
Kritis Signer 커스텀 빌더를 빌드하고 등록합니다.

이 일회성 설정 단계는 Kritis 서명자 커스텀 빌더를 빌드하고 Cloud Build에 등록합니다. 등록된 커스텀 빌더는 모든 Cloud Build 파이프라인에서 사용할 수 있습니다.
```
gcloud builds submit . --config deploy/kritis-signer/cloudbuild.yaml
```

기존 정책 보기

이 섹션에서는 Kritis 서명자 정책의 예시를 보여줍니다.

이 정책은 Artifact Analysis에 이미지의 취약점 스캔을 요청하도록 Kritis 서명자를 구성합니다. 스캔이 완료되면 Kritis 서명자가 정책의 취약점 서명 규칙을 기준으로 반환된 취약점 결과를 검사합니다.

다음을 기반으로 증명을 만들도록 이 정책의 취약점 서명 규칙을 수정할 수 있습니다.

식별된 취약점의 심각도 수준
특정 취약점

증명을 무조건 생성하거나(ALLOW_ALL) 생성하지 않도록(BLOCK_ALL) 정책을 설정할 수도 있습니다.

Kritis 서명자 정책을 보려면 다음 명령어를 실행합니다.

cat samples/signer/policy-strict.yaml

이 정책은 다음과 유사합니다.

apiVersion: kritis.grafeas.io/v1beta1
kind: VulnzSigningPolicy
metadata:
  name: my-vsp
spec:
  imageVulnerabilityRequirements:
    maximumFixableSeverity: MEDIUM
    maximumUnfixableSeverity: MEDIUM
    allowlistCVEs:
    - projects/goog-vulnz/notes/CVE-2021-20305

각 항목의 의미는 다음과 같습니다.

maximumUnfixableSeverity 및 maximumFixableSeverity는 Kritis 서명자가 증명을 만드는 Common Vulnerabilities and Exposures(CVE) 심각도 기준점을 정의합니다. maximumUnfixableSeverity는 현재 수정사항이 제공되지 않는 심각도의 기준점을 정의합니다. maximumFixableSeverity는 현재 수정사항이 제공되는 심각도의 기준점을 정의합니다. maximumUnfixableSeverity 및 maximumFixableSeverity는 각각 다음 심각도 수준 중 하나로 설정할 수 있습니다.
- CRITICAL
- HIGH
- MEDIUM
- LOW
심각도 수준에 대한 자세한 내용은 심각도 수준을 참조하세요.

또는 maximumUnfixableSeverity와 maximumFixableSeverity를 다음과 같이 설정할 수 있습니다.
- BLOCK_ALL: 취약점이 식별되면 증명이 생성되지 않습니다.
- ALLOW_ALL: 증명이 항상 생성됩니다.
allowlistCVEs는 허용 목록에 추가할 특정 CVE 목록입니다. Kritis 서명자는 증명 생성 여부 평가 시 이 목록의 CVE를 무시합니다. 허용 목록의 각 항목은 CVE의 Artifact Analysis 메모 이름과 정확히 일치해야 합니다. Artifact Analysis 취약점 소스에 대해 자세히 알아보세요. 메모에 대한 자세한 내용은 메타데이터 스토리지를 참조하세요.

Cloud KMS 서명 키 만들기

Cloud Key Management Service 키는 증명을 만드는 데 사용됩니다.

KEY_RING이라는 이름으로 Cloud KMS 키링을 새로 만듭니다.
```
gcloud kms keyrings create KEY_RING \
   --location global
```

키링 안에 KEY_NAME라는 새 Cloud KMS 키를 만듭니다.

gcloud kms keys create KEY_NAME \
    --keyring KEY_RING \
    --location global \
    --purpose "asymmetric-signing" \
    --default-algorithm "rsa-sign-pkcs1-2048-sha256"

다음 단계를 위해 다이제스트 알고리즘과 Cloud KMS를 환경 변수에 저장합니다.

export KMS_DIGEST_ALG=SHA256
export KMS_KEY_NAME=projects/$PROJECT_ID/locations/global/keyRings/KEY_RING/cryptoKeys/KEY_NAME/cryptoKeyVersions/1

메모 이름 정의

모든 증명은 Artifact Analysis 메모를 참조합니다. Kritis 서명자는 지정된 이름의 메모를 자동으로 만듭니다. 기존 메모 이름을 재사용할 수도 있습니다.

export NOTE_ID=my-signer-note
export NOTE_NAME=projects/${PROJECT_ID}/notes/${NOTE_ID}

Cloud Build 파이프라인에서 Kritis 서명자로 증명 만들기

이 섹션에서는 Kritis 서명자 커스텀 클라우드 빌더를 사용하여 취약점 스캔 결과에 따라 Binary Authorization 증명을 만드는 방법을 보여줍니다.

다음 단계에서는 Kritis 서명자 저장소의 예시 빌드 구성 파일을 사용하여 Kritis 서명자가 작동하는 방법을 보여줍니다. 각 구성 파일 예시는 다음과 같은 빌드 단계를 포함합니다.

Docker 컨테이너 이미지를 빌드하는 docker build 단계
새로 빌드된 컨테이너 이미지를 Container Registry에 푸시하는 docker push 단계
다음을 수행하여 컨테이너 이미지를 검사하고 서명하는 vulnsign 단계
1. Artifact Analysis가 새로 빌드된 컨테이너 이미지에서 취약점 발견 항목을 반환할 때까지 대기
2. 정책의 취약점 서명 규칙을 기준으로 발견 항목 검사
3. 결과가 취약점 규칙을 충족하는 경우 증명 생성

각 예시 빌드를 Cloud Build에 제출합니다. 각 빌드는 취약점 결과를 생성합니다.

실패 사례: 취약점 결과가 취약점 서명 규칙을 위반합니다. 이 빌드가 실패하고 증명이 생성되지 않습니다.
성공 사례: 취약점 결과가 취약점 서명 규칙을 충족합니다. 이 빌드가 성공하고 증명이 생성됩니다.

실패 사례 샘플 빌드 제출

이 섹션에서는 컨테이너 이미지를 빌드하고 취약점을 스캔합니다. 컨테이너 이미지가 HIGH 심각도 수준의 여러 취약점이 포함된 Debian 10의 특정 스냅샷을 기반으로 하기 때문에 이 빌드가 실패합니다. 이러한 취약점은 취약점 서명 규칙을 위반합니다. 따라서 빌더가 증명을 생성하지 않습니다.

(선택사항) 실패 사례의 취약점 서명 정책 파일을 확인합니다.
```
cat samples/signer/policy-strict.yaml
```
참고: 이 빌드 구성 파일에는 사용자 정의 대체도 포함되어 있습니다. 대체 항목은 빌드 파이프라인 내에서 사용되는 변수이며, --substitutions 매개변수와 함께 gcloud builds submit 명령어를 통해 전달됩니다.

빌드를 제출합니다.

gcloud builds submit \
  --substitutions=_KMS_KEY_NAME=$KMS_KEY_NAME,_KMS_DIGEST_ALG=$KMS_DIGEST_ALG,_NOTE_NAME=$NOTE_NAME \
  --config=samples/signer/cloudbuild-bad.yaml samples/signer

다음과 같이 출력이 표시됩니다.

"ERROR: (gcloud.builds.submit) build BUILD_ID completed with status "FAILURE"

마지막 빌드의 빌드 ID를 저장합니다.

export BUILD_ID=$(gcloud builds list --limit=1 --format="value('ID')")

결과 확인:

 gcloud storage cat gs://${PROJECT_NUMBER}.cloudbuild-logs.googleusercontent.com/log-${BUILD_ID}.txt | grep "does not pass VulnzSigningPolicy"

성공 사례 샘플 빌드 제출

이 섹션에서는 취약점 서명 규칙을 위반하지 않는 취약점을 포함하는 컨테이너 이미지를 빌드합니다. 이 경우 Kritis Signer 커스텀 빌더가 증명을 만듭니다.

Cloud Build에 성공 사례 샘플 빌드를 제출하려면 다음을 수행합니다.

(선택사항) 취약점 서명 정책 파일에서 성공 사례를 확인합니다.
```
cat samples/signer/policy-loose.yaml
```
참고: 이 빌드 구성 파일에는 사용자 정의 대체도 포함되어 있습니다. 대체 항목은 빌드 파이프라인 내에서 사용되는 변수이며, --substitutions 매개변수와 함께 gcloud builds submit 명령어를 통해 전달됩니다.

빌드를 제출합니다.

gcloud builds submit \
  --substitutions=_KMS_KEY_NAME=$KMS_KEY_NAME,_KMS_DIGEST_ALG=$KMS_DIGEST_ALG,_NOTE_NAME=$NOTE_NAME \
  --config=samples/signer/cloudbuild-good.yaml samples/signer

마지막 빌드의 빌드 ID를 저장합니다.

export BUILD_ID=$(gcloud builds list --limit=1 --format="value('ID')")

결과 확인:

gcloud builds describe $BUILD_ID | grep status

검사 전용 모드에서 Kritis 서명자 사용

이 섹션에서는 check-only 모드에서 Kritis 서명자를 사용하는 방법을 보여줍니다. 이 모드에서는 Kritis 서명자가 증명을 만들지 않습니다. 취약점 서명 규칙에 따라 빌드 단계에 성공 또는 실패하기 전에만 이미지에 취약점이 있는지 확인합니다.

실패 사례 샘플 빌드 제출

(선택사항) 실패 사례의 취약점 서명 정책 파일을 확인합니다.
```
cat samples/policy-check/policy-strict.yaml
```
Kritis 서명자 빌드 단계에서는 mode 플래그가 check-only로 설정됩니다.

빌드를 제출합니다.

gcloud builds submit \
  --config=samples/policy-check/cloudbuild-bad.yaml samples/policy-check

빌드에 실패합니다.

마지막 빌드의 빌드 ID를 저장합니다.

export BUILD_ID=$(gcloud builds list --limit=1 --format="value('ID')")

결과 확인:

 gcloud storage cat gs://${PROJECT_NUMBER}.cloudbuild-logs.googleusercontent.com/log-${BUILD_ID}.txt | grep "does not pass VulnzSigningPolicy"

성공 사례 샘플 빌드 제출

(선택사항) 취약점 서명 정책 파일에서 성공 사례를 확인합니다.
```
cat samples/policy-check/policy-loose.yaml
```

빌드를 제출합니다.

gcloud builds submit \
 --config=samples/policy-check/cloudbuild-good.yaml samples/policy-check

마지막 빌드의 빌드 ID를 저장합니다.

export BUILD_ID=$(gcloud builds list --limit=1 --format="value('ID')")

결과 확인:

gcloud builds describe $BUILD_ID | grep status

증명자 만들기

이 가이드에 설명된 방법을 사용하여 생성된 증명이 필요한 정책을 만들려면 먼저 증명자를 만들어야 합니다.

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

이 가이드의 앞부분에서 만든 Cloud KMS 키에서 공개 키 자료를 검색합니다.
```
gcloud kms keys versions get-public-key 1 \
--key KEY_NAME \
--keyring KEY_RING \
--location global \
--output-file OUTPUT_PATH
```
- KEY_NAME: 키 이름
- KEY_RING: 키링 이름
- OUTPUT_PATH: 파일 경로(예: my-key.pem)
파일의 공개 키 자료와 이 가이드의 앞부분에서 만든 메모를 사용하여 증명자를 만듭니다. Google Cloud 콘솔 또는 gcloud CLI를 통해 증명자를 만들 수 있습니다.
증명이 필요한 정책을 만들고 이 섹션에서 만든 증명자를 제공합니다. Google Cloud 콘솔 또는 gcloud CLI를 통해 정책을 만들 수 있습니다.

증명 만들기

증명자를 사용하여 증명을 만들려면 Cloud KMS를 사용하여 증명 만들기를 참조하세요.

삭제

이 문서에서 사용된 리소스를 삭제하려면 프로젝트를 삭제하면 됩니다.

gcloud projects delete ${PROJECT_ID}

다음 단계

GitHub의 Kritis 서명자 문서
Binary Authorization 개요
Google Cloud Console 또는 명령줄 도구를 통해 증명자 만들기
Google Cloud Console 또는 command-line-tool를 통해 증명을 요구하도록 정책 구성
Voucher로 증명 만들기
Artifact Analysis 및 취약점 스캔
Cloud Build 커뮤니티 및 커스텀 클라우드 빌더