검사 기반 플랫폼 정책을 사용한 지속적 검증(CV)은 Google Kubernetes Engine(GKE)에서 실행되는 포드를 모니터링하여 연결된 컨테이너 이미지가 사용자가 지정한 Binary Authorization 검사 기반 플랫폼 정책을 계속 준수하도록 하는 데 사용할 수 있는 Binary Authorization의 기능입니다.
CV에 따라 포드의 플랫폼 정책 위반이 확인되면 Cloud Logging에 위반 사항이 로깅됩니다.
플랫폼 정책이 포함된 CV는 기존의 지속적 검증(지원 중단됨)을 대체합니다.
CV를 사용하는 이유
컨테이너 이미지를 배포할 때 Binary Authorization을 시행하면 이미지 검증이 한 번만 수행되지만 CV는 실행 중인 포드와 연결된 이미지가 정책을 일관되게 준수하는지 지속적으로 모니터링합니다.
따라서 Binary Authorization 시행과 검사 기반 정책이 포함된 CV를 모두 사용 설정하면 전체 조정 수명 주기 전반에 걸쳐서 정책 준수가 검증되도록 보장할 수 있습니다.
CV는 다음 시나리오에서 유용합니다.
정책 변경사항: Binary Authorization 프로젝트 싱글톤 시행 정책을 업데이트하면 Binary Authorization이 업데이트 후에 배포된 이미지만 검증합니다. 이미 실행 중인 포드는 영향을 받지 않습니다. 업데이트된 정책에 따라 Binary Authorization에서 동일한 이미지 배포가 차단되더라도 이러한 포드는 계속 실행됩니다.
따라서 Binary Authorization 프로젝트 싱글톤 정책을 업데이트할 때는 프로젝트 싱글톤 정책과 일치하도록 CV 플랫폼 정책을 만들거나 업데이트하는 것이 좋습니다. 이렇게 하면 CV를 통해 업데이트된 정책을 위반하는 실행 중인 포드에 대한 정보를 확인할 수 있습니다.
이미지 메타데이터 모니터링: CV는 다음과 같이 이미지 메타데이터의 변경사항에 대해 구체적인 검사를 제공합니다.
- 증명: 포드 이미지의 증명이 더 이상 유용하지 않으면 CV에 로깅됩니다.
- 최신 상태: 포드 이미지가 더 이상 최신이 아닌 것이 확인되면 CV에 로깅됩니다.
- 출처: 신뢰할 수 있는 소스 저장소에 있는 빌드 구성을 사용해서 신뢰할 수 있는 빌더로 포드 이미지가 빌드되었는지 CV를 통해 확인할 수 있습니다.
- Sigstore 서명: 포드 이미지에 유효한 Sigstore 서명이 없으면 CV에 로깅됩니다.
- 신뢰할 수 있는 디렉터리: 포드 이미지가 플랫폼 정책에 나열되지 않은 저장소 디렉터리에 있으면 CV에 로깅됩니다.
- 취약점: 포드 이미지에서 취약점이 식별되면 CV에 로깅됩니다.
테스트 실행 모니터링: 테스트 실행을 사용 설정하면 Binary Authorization에서 모든 이미지 배포가 허용됩니다. 프로젝트 싱글톤 정책과 일치하는 플랫폼 정책으로 CV를 사용 설정하면 CV에서 플랫폼 정책을 위반하는 이미지가 정기적으로 로깅됩니다.
Breakglass 모니터링: breakglass를 사용하여 포드를 배포하면 Binary Authorization가 프로젝트 싱글톤 정책 시행을 우회하고 단일 이벤트를 Cloud 감사 로그에 로깅합니다. 하지만 CV는 일치하는 플랫폼 정책을 사용해서 breakglass를 사용하여 배포되는 포드를 포함하여 정책 위반 포드를 정기적으로 로깅합니다.
CV 작동 방식
CV를 사용하려면 GKE 클러스터에서 CV를 사용 설정해야 합니다.
클러스터에 이미지를 배포한 후 CV가 연결된 포드를 모니터링하여 검사 기반 플랫폼 정책을 준수하는지 확인합니다.
CV는 예외 이미지에 지정된 것 이외의 이미지 태그를 지원하지 않습니다.
CV로 실행 중인 포드를 정기적으로 검토
실행 중인 포드를 모니터링하기 위해 CV는 최소 24시간 간격으로 각 포드와 연결된 이미지를 검토합니다. CV는 init 컨테이너와 임시 컨테이너도 모니터링합니다.
각 검토를 수행할 때 CV는 각 포드와 연결된 이미지 목록을 검색합니다. 그런 후 CV는 이미지 정보가 플랫폼 정책을 충족하는지 확인합니다.
CV의 플랫폼 정책 위반 로깅
CV에서 플랫폼 정책을 위반하는 이미지가 발견되면 위반 사항 및 기타 발견 항목이 Cloud Logging에 로깅됩니다. 각 포드에서 위반한 각 플랫폼 정책의 경우 별도의 로그 항목이 작성됩니다.
CV에서 플랫폼 정책을 사용하여 포드 이미지를 평가할 때 이미지가 일부 검사를 충족하고 다른 검사를 위반할 수 있습니다. CV는 포드 이미지가 검사를 위반할 때마다 로그 항목을 생성합니다. 로그 항목에는 플랫폼 정책을 위반하는 포드 이미지만 포함됩니다. 모든 이미지가 모든 검사를 충족하면 로그 항목이 생성되지 않습니다.
CV는 정책 위반 이미지가 있는 포드가 종료될 때까지 정책 위반을 계속 로깅합니다. 검증 간격 중에 정책 위반 포드가 종료되면 CV에서 생성된 최종 로그 항목이 다음 CV 평가 중에 종료 후 나타날 수 있습니다.
정책 위반 포드는 단기 포드의 경우에도 최소 한 번 로깅되어야 합니다.
CV는 실행 중인 포드를 종료하지 않습니다.
CV의 피드 리소스 사용
GKE 클러스터에서 실행 중인 포드에 대한 정보를 검색하기 위해 CV는 binauthz-cv-cai-feed라는 피드 리소스를 만듭니다.
CV 플랫폼 정책
CV를 사용하려면 먼저 플랫폼 정책을 구성합니다.
플랫폼 정책은 프로젝트 싱글톤 정책이라고 부르는 기존 Binary Authorization 정책과 다릅니다. 배포 프로젝트는 기존 프로젝트 싱글톤 정책을 하나만 포함할 수 있지만 플랫폼 정책은 여러 개 구성할 수 있습니다. 각 플랫폼 정책은 하나 이상의 프로젝트에 상주할 수 있습니다.
플랫폼 정책은 CV에서만 작동하며 Binary Authorization 시행을 지원하지 않습니다. 따라서 Binary Authorization 시행과 CV 모니터링을 모두 사용하려면 시행용 프로젝트 싱글톤 정책과 모니터링용 플랫폼 정책을 만드는 것이 좋습니다.
예를 들어 배포가 허용되기 전에 이미지에 증명 포함을 강제하도록 Binary Authorization을 구성할 경우에는 실행 중인 포드도 동일한 요구사항을 준수하도록 해야 합니다. 이렇게 하려면 증명자를 사용해서 프로젝트 싱글톤 시행 정책을 구성합니다. 그런 후 간단한 서명 증명 검사가 포함된 플랫폼 정책을 만듭니다. 이 정책에는 증명자와 동일한 노트 및 공개 키를 인증자가 포함됩니다.
플랫폼 정책은 플랫폼에 따라 달라집니다. GKE는 지원되는 유일한 플랫폼입니다.
플랫폼 정책에서 검사를 구성할 수 있습니다. 검사는 하나 이상의 검사 집합으로 그룹화됩니다. 각 검사 집합은 하나 이상의 검사를 지정할 수 있습니다.
플랫폼 정책은 CV에서 평가되지 않도록 이미지를 제외할 수 있습니다.
필수 권한
플랫폼 정책을 나열하거나 기술하려면 binaryauthorization.policyViewer 역할이 필요합니다. 플랫폼 정책을 생성, 수정, 삭제하려면 binaryauthorization.policyEditor 역할이 필요합니다.
자세한 내용은 플랫폼 정책 관리를 참조하세요.
정책 업데이트
플랫폼 정책을 업데이트하면 YAML 파일로 제공하는 정책 설명자로 기존 정책을 덮어씁니다. 기존 플랫폼 정책에 새 검사를 추가하려면 기존 정책을 기술하여, YAML 파일로 저장하고, 새 검사를 추가한 후 업데이트된 파일을 사용해서 정책을 업데이트하는 것이 좋습니다.
여러 플랫폼 정책
클러스터와 동일한 프로젝트(로컬 플랫폼 정책) 또는 다른 프로젝트에 플랫폼 정책을 만들 수 있습니다.
여러 플랫폼 정책을 구성할 수 있으므로 각 정책을 고유한 리소스 이름으로 지정할 수 있습니다. gcloud CLI 명령어를 실행할 때는 해당 ID를 사용해서 로컬 플랫폼 정책을 참조합니다. 다른 프로젝트의 플랫폼 정책을 참조할 때는 다음 형식으로 리소스 이름을 사용합니다.
projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID
로컬 플랫폼 정책 또는 다른 프로젝트에 있는 정책인지에 따라 각 GKE 클러스터와 연결할 플랫폼 정책을 선택할 수 있습니다.
플랫폼 정책당 여러 검사
정책의 checks 블록에 추가하여 각 플랫폼 정책에 여러 검사를 구성할 수 있습니다. 구성할 수 있는 특정 검사에 대해 자세히 알아보려면 검사를 참조하세요.
CV 플랫폼 정책에 검사를 하나 이상 지정하면 하나의 검사로 평가되는 이미지가 다른 검사로 계속 평가될 수 있습니다.
Binary Authorization은 이미지가 예외 이미지 허용 목록 패턴과 일치하지 않는 한 각 이미지의 플랫폼 정책에 구성된 모든 검사를 평가합니다. 자세한 내용은 예외 이미지를 참조하세요.
단일 프로젝트 설정
단일 프로젝트에 CV를 설정할 수 있습니다.
단일 프로젝트 설정에서 Binary Authorization은 Binary Authorization 서비스 에이전트의 필수 역할에 따라 자동으로 설정됩니다.
GKE 클러스터, 클러스터에 바인딩된 플랫폼 정책, 검사에 필요한 메타데이터가 모두 동일한 프로젝트에 있으면 추가적인 Identity and Access Management(IAM) 역할이 필요하지 않습니다.
보안 강화를 위한 다중 프로젝트 설정 구성에 대해 자세히 알아보려면 문제의 분리를 참조하세요.
다중 프로젝트 설정
플랫폼 정책을 사용해서 다중 프로젝트 CV 설정을 구성할 때는 플랫폼 정책, 이미지, GKE 클러스터, 기타 유형의 CV 종속 리소스가 각기 서로 다른 프로젝트에 배치될 수 있습니다.
다중 프로젝트 설정에서는 CV가 액세스해야 하는 각 프로젝트 및 리소스의 목적을 이해하고 필요한 IAM 역할 및 권한을 그에 맞게 설정하는 것이 중요합니다.
CV 사용 방법
CV를 사용하려면 일반적으로 다음을 수행합니다.
- 사용하려는 검사를 결정합니다.
- 정책 YAML 파일을 사용해서 하나 이상의 플랫폼 정책을 구성합니다. 이 파일은 사용할 검사를 지정합니다.
- 플랫폼 정책을 만듭니다. 선택한 프로젝트에 정책을 저장할 수 있습니다.
- 개별 클러스터 또는 Fleet에서 CV를 사용 설정할지 여부를 선택합니다.
- Logging의 CV 로그에서 이벤트를 검사합니다.
- 로그를 검토하고 빌드 및 기타 프로세스를 업데이트하여 검사를 충족하는 이미지를 생성합니다.
수표
이 섹션에서는 CV가 제공하는 구체적인 검사에 대해 설명합니다.
검사 기반 정책에는 다음과 같은 표준 형식이 사용됩니다.
gkePolicy:
checkSets:
- checks:
- CHECK_TYPE1:
CHECK_TYPE1_PARAMETERS
displayName: CHECK_TYPE1_DISPLAY_NAME
- CHECK_TYPE2:
CHECK_TYPE2_PARAMETERS
displayName: CHECK_TYPE2_DISPLAY_NAME
displayName: CHECK_SET_DISPLAY_NAME
checks 및 checkSets의 displayName 필드는 선택사항입니다. 이 필드는 CV가 정책 위반사항을 로깅할 때만 사용됩니다. 이 가이드의 뒷부분에 있는 일부 예시에서는 생략되어 있습니다.
항상 거부 검사
항상 거부 검사는 이 검사에 해당하는 모든 이미지에 대한 평가가 실패하도록 보장합니다. CV가 이 검사를 사용해서 실행 중인 포드를 검토할 때마다 각 포드에 대해 로그 항목이 생성됩니다.
항상 거부 검사를 허용 목록 또는 다중 검사 집합과 조합하여 Binary Authorization이 특정한 경우에 항상 포드에 대해 로그를 생성하도록 보장할 수 있습니다.
항상 거부 검사를 사용하려면 다음과 같이 checks 블록에 alwaysDeny: true를 추가합니다.
gkePolicy:
checkSets:
- displayName: "My check set"
checks:
- alwaysDeny: true
alwaysDeny 값은 false로 설정할 수 없습니다. 대신 검사를 삭제하세요.
항상 거부 검사의 사용 방법 예시는 다중 검사 집합 사용을 참조하세요.
이미지 최신 상태 검사
이미지 최신 상태 검사는 이미지가 실행 중인 기간을 계산하고 기간이 maxUploadAgeDays 임곗값을 초과하면 로깅을 수행합니다.
다음 예시 플랫폼 정책 YAML에서 CV는 배포된 시점으로부터 30일이 지나서 저장소에 업로드된 이미지가 포함된 포드를 로깅합니다.
gkePolicy:
checkSets:
checks:
- imageFreshnessCheck:
maxUploadAgeDays: 30
displayName: "My image freshness check"
displayName: "My check set"
단순 서명 증명 검사
CV 단순 서명 증명 검사를 사용하면 각 포드 이미지에 유효한 서명된 증명이 포함되는지 검사할 수 있습니다.
이 검사는 Binary Authorization 시행 정책의 증명 평가와 동일합니다. 증명자에 사용한 것과 동일한 노트 및 키를 사용해서 이 검사를 구성할 수 있습니다. 기존의 지속적 검증(지원 중단됨) 대신 이 검사를 사용하는 것이 좋습니다.
다음은 단순 서명 증명 검사가 포함된 플랫폼 정책의 예시입니다.
gkePolicy:
checkSets:
checks:
simpleSigningAttestationCheck:
containerAnalysisAttestationProjects:
- "projects/my-attestation-project1"
- "projects/my-attestation-project2"
attestationAuthenticators:
pkixPublicKeySet:
pkixPublicKeys:
publicKeyPem: |
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQxXxgAEvgQuW1FHYZPB2PTQfOJKUkS9sjMO/1os10xOWrhl1kQo4EnzMOovROWVLo+m9mcwp7nRQ2qQDThZdSFi0nFJ1A==
-----END PUBLIC KEY-----
signatureAlgorithm: ECDSA_P256_SHA256
Binary Authorization 증명자 대신 CV 증명에는 인증자가 포함됩니다. 정책의 attestationAuthenticators 블록에 직접 인증자를 지정합니다.
플랫폼 정책에서 simpleSigningAttestationCheck에는 여러 attestationAuthenticators를 가질 수 있으며, 각 pkixPublicKeySet에도 여러 키가 포함될 수 있습니다. 각 포드 이미지에 모든 인증자의 pkixPublicKeySet에 있는 모든 키로 서명된 유효한 증명이 포함되면 검사 요구사항이 충족됩니다.
CV 플랫폼 정책은 다음과 같은 방식에서 프로젝트 싱글톤 시행 정책과 다릅니다.
- PGP 키가 지원되지 않습니다.
- 증명자가 필요하지 않습니다. 대신 수동으로 키를 생성하고 증명 생성을 위해 사용하는 키 ID를 검색하도록 플랫폼 정책을 기술합니다.
- 수동으로 페이로드를 생성 및 서명하고, 증명 JSON 파일을 만들고, Artifact Analysis API를 사용해서 증명을 만듭니다.
- Artifact Analysis 노트를 만들지만 이를 정책에 지정하지는 않습니다. 대신 CV는 모든 프로젝트에서
containerAnalysisAttestationProjects필드에 나열된 증명을 찾습니다. - 증명이 Artifact Analysis 어커런스에 계속 저장되지만 하나 이상의 프로젝트에 저장될 수 있습니다.
- 리소스 이름
projects/ATTESTATION_PROJECT_ID를 사용하여 증명이 포함된 하나 이상의 프로젝트를 명시적으로 지정해야 합니다.
CV는 예외 이미지에 지정된 이미지 태그를 제외하고 이미지 태그를 지원하지 않습니다.
이미지가 다이제스트 대신 이미지 태그로 배포된 경우 허용 목록에 태그가 포함될 수 있기 때문에 CV가 예외 이미지에 따라 먼저 평가합니다. 이미지가 예외로 설정되지 않았으면 CV가 이미지 다이제스트를 찾으려고 시도합니다. 해당 항목이 없으므로 이미지가 검사를 위반합니다.
SLSA 검사
SLSA 검사는 포드 이미지의 SLSA로 지정된 출처를 검사합니다.
다음은 CV 플랫폼 정책 YAML 구성에 대한 예시입니다.
gkePolicy:
checkSets:
checks:
imageAllowlist:
allowPattern: "gcr.io/my-images/not-built-by-GCB/**"
- slsaCheck:
rules:
trustedBuilder: GOOGLE_CLOUD_BUILD
attestationSource:
- containerAnalysisAttestationProjects: "projects/attestation-project1"
- containerAnalysisAttestationProjects: "projects/attestation-project2"
# Require that images were built using a checked-in top-level config file.
configBasedBuildRequired: true
# Which repos the config file can be from.
trustedSourceRepoPatterns:
- "source.cloud.google.com/my-project/my-source-repo"
- "github.com/my-github-user/*"
displayName: "My SLSA check"
displayName: "My check set"
CV가 이 플랫폼 정책을 사용해서 이미지를 검토할 때는 다음을 검사합니다.
신뢰할 수 있는 빌더를 사용해서 이미지가 빌드되었는지 검사합니다. Cloud Build는 SLSA 검사가 지원하는 유일한 신뢰할 수 있는 빌더입니다.
Cloud Build가
attestation-project1또는attestation-project2로 증명을 생성했는지 검사합니다.이미지가 다음과 같은 신뢰할 수 있는 저장소의 최상위 구성 파일을 사용해서 빌드되었는지 검사합니다.
source.cloud.google.com/my-project/my-source-repo/저장소github.com/my-github-user/의 모든 저장소
gcr.io/my-images/not-built-by-GCB/또는 하위 디렉터리(Cloud Build에서 빌드되지 않음)의 이미지는 정책을 위반하므로 검사에서 예외로 설정됩니다.
Sigstore 서명 검사
Sigstore 서명 검사는 Sigstore 서명을 사용하여 이미지가 서명되었는지 확인합니다.
이 검사는 Artifact Registry에서 호스팅되는 이미지만 지원합니다. Artifact Registry에서 가져온 서명을 정책의 키로 성공적으로 검증할 수 있는지 확인합니다.
다음 플랫폼 정책 예시에서는 Sigstore 서명 검사를 구성하는 방법을 설명합니다.
gkePolicy:
checkSets:
- checks:
- displayName: sigstore-signature-check
sigstoreSignatureCheck:
sigstoreAuthorities:
- displayName: sigstore-authority
publicKeySet:
publicKeys:
publicKeyPem: |
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQxXxgAEvgQuW1FHYZPB2PTQfOJKUkS9sjMO/1os10xOWrhl1kQo4EnzMOovROWVLo+m9mcwp7nRQ2qQDThZdSFi0nFJ1A==
-----END PUBLIC KEY-----
플랫폼 정책에서 sigstoreSignatureCheck에는 각 publicKeySet의 여러 키와 여러 sigstoreAuthorities가 포함될 수 있습니다. 각 포드 이미지에 모든 인증자의 publicKeySet에 있는 모든 키로 서명된 유효한 증명이 포함되면 검사 요구사항이 충족됩니다.
신뢰할 수 있는 디렉터리 검사
신뢰할 수 있는 디렉터리 검사는 포드 이미지가 플랫폼 정책에서 지정하는 제공된 신뢰할 수 있는 디렉터리 중 하나에 있는지 검사합니다.
이 검사를 사용할 때는 정책에서 신뢰할 수 있는 디렉터리로 지정한 저장소를 보호하여 무단 액세스를 방지하는 것이 좋습니다.
다음 플랫폼 정책 예시에서는 신뢰할 수 있는 디렉터리 검사를 구성하는 방법을 설명합니다.
gkePolicy:
checkSets:
checks:
trustedDirectoryCheck:
trustedDirPatterns:
- "gcr.io/my-project/gcr-directory"
- "us-central1-docker.pkg.dev/my-project/ar-directory"
displayName: "My trusted directory check"
displayName: "My check set"
예시 플랫폼 정책에서 trustedDirPatterns는 신뢰할 수 있는 디렉터리를 나열합니다. 모든 포드 이미지가 나열된 디렉터리에 있으면 정책을 준수합니다. 나열된 디렉터리에 없는 포드 이미지는 정책을 위반하며, CV가 위반 사항을 로깅합니다.
취약점 검사
취약점 검사는 Artifact Analysis 취약점 스캔을 사용해서 포드 이미지에 취약점이 포함되는지 검사합니다. 여기에는 포드가 배포된 시점부터 취약점 스캔으로 식별된 새로운 취약점이 포함됩니다. 취약점 검사에서는 취약점 보안 수준 임곗값과 특정 취약점(CVE)을 구성할 수 있습니다. 취약점 검사를 위반하는 취약점이 포함된 이미지는 Logging에 로깅됩니다.
이 검사를 사용하려면 먼저 Artifact Analysis에서 취약점 스캔을 사용 설정해야 합니다.
다음 플랫폼 정책 구성 예시에는 취약점 검사가 포함됩니다.
gkePolicy:
checkSets:
- displayName: "Default check set"
checks:
- vulnerabilityCheck:
maximumFixableSeverity: MEDIUM
maximumUnfixableSeverity: HIGH
allowedCves:
- "CVE-2022-11111"
- "CVE-2022-22222"
blockedCves:
- "CVE-2022-33333"
- "CVE-2022-44444"
containerAnalysisVulnerabilityProjects: "projects/my-project"
이 예시에서 maximumUnfixableSeverity 및 maximumFixableSeverity는 Artifact Analysis가 식별할 수 있는 취약점과 연결된 공통 취약점 점수 산출 시스템(CVSS)의 심각도 수준을 정의합니다.
또한 blockedCves에는 특정 Common Vulnerability Exposures(CVE)가 나열됩니다. 식별된 취약점이 지정된 심각도 수준 중 하나를 초과하거나 blockedCves에 나열된 CVE 중 하나와 일치하고, allowedCves에 나열된 CVE 중 하나와 일치하지 않으면 CV가 Logging에 항목을 로깅합니다.
업데이트된 정책 검증
CV 플랫폼 정책을 업데이트한 후에는 Binary Authorization 및 CV가 계속 예상한 대로 작동하는지 검증하는 것이 좋습니다.
구성 검증
구성을 확인하려면 Binary Authorization 프로젝트 싱글톤 정책과 CV 플랫폼 정책을 모두 조사합니다.
검증 작업
Binary Authorization 및 CV가 예상한 대로 작동하는지 검증하려면 테스트 포드를 배포한 후 Logging에서 Binary Authorization 항목을 검사할 수 있습니다.
허용 목록으로 이미지 예외 설정
플랫폼 정책을 만들 때 해당 URL을 허용 목록에 추가하여 검사되지 않도록 이미지를 예외로 설정할 수 있습니다. 정책 수준의 허용 목록은 전체 정책으로부터 이미지를 예외로 설정합니다. 검사 집합 수준의 허용 목록이 검사 집합에서 예외로 설정되고 검사 집합이 평가될 때만 적용됩니다. 검사 내의 허용 목록은 해당 검사에서만 이지를 예외로 설정합니다.
허용 목록 패턴은 하나 이상의 이미지 URL과 일치하는 패턴입니다. 허용 목록 패턴은 다음 중 하나일 수 있습니다.
- 와일드 카드
*또는**로 끝나는 이미지 이름 프리픽스 - 태그 또는 다이제스트가 없는 이미지 이름
- 태그(또는 와일드 카드 문자
*가 있는 태그 프리픽스)를 포함하는 이미지 이름 - 다이제스트가 포함된 이미지 이름
- 태그와 다이제스트가 모두 포함된 이미지 이름
다음은 허용 목록 패턴의 예시입니다.
us-central1.pkg.dev/my-project/my-image:latest@sha256:77b0b75136b9bd0fd36fb50f4c92ae0dbdbbe164ab67885e736fa4374e0cbb8c는 정확한 이미지 이름, 태그, 다이제스트와 일치합니다.us-central1.pkg.dev/my-project/my-image:latest는 다이제스트를 포함한(또는 다이제스트를 포함하지 않는) 이름 및 태그와 일치합니다.us-central1.pkg.dev/my-image:foo*는 다이제스트를 포함한(또는 다이제스트를 포함하지 않는) 이름 및 태그 프리픽스(예:myimage:foo및myimage:foobar)와 일치합니다.us-central1.pkg.dev/my-project/my-image@sha256:77b0b75136b9bd0fd36fb50f4c92ae0dbdbbe164ab67885e736fa4374e0cbb8c는 태그를 포함한(또는 태그를 포함하지 않는) 이름 및 다이제스트와 일치합니다.us-central1.pkg.dev/my-project/my-image는 태그 또는 다이제스트를 포함한 이름과 일치합니다.
와일드 카드 문자 * 및 **를 사용하면 특정 프리픽스가 포함된 일치하는 이름을 찾을 수 있습니다. *는 /가 포함되지 않은 서픽스와 일치합니다. **는 /를 포함할 수 있는 서픽스와 일치하지만 **는 / 다음에만 사용할 수 있습니다. * 및 **는 태그 또는 다이제스트와 함께 사용할 수 없습니다.
예를 들면 다음과 같습니다.
us-central1.pkg.dev/my-project/my-image*는 태그 또는 다이제스트를 포함하는us-central1.pkg.dev/myproject/my-image,us-central1.pkg.dev/myproject/my-image1,us-central1.pkg.dev/myproject/my-image2와 일치합니다.us-central1.pkg.dev/my-project/**는 태그 또는 다이제스트를 포함하는us-central1.pkg.dev/myproject/my-image및us-central1.pkg.dev/my-project/some-directory/other-image와 일치합니다.
이름 프리픽스와 태그 프리픽스는 비어 있지 않아야 합니다. 따라서 * 또는 **만 단독으로 사용하는 것은 유효한 패턴이 아니며 us-central1.pkg.dev/my-image:*도 마찬가지입니다.
gkePolicy 수준 예외
다음 예시는 플랫폼 정책 수준에서 이미지를 예외로 설정하는 방법을 보여줍니다. exempt-images1 및 exempt-images2 디렉터리와 해당 하위 디렉터리의 모든 이미지는 CV 모니터링에서 제외됩니다.
gkePolicy:
imageAllowlist:
- allowPattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images1/**"
- allowPattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images2/**"
checkSets:
checks:
...
정책에서 imageAllowlist 아래에 나열된 이미지는 gkePolicy 아래에 나열된 모든 검사 집합(checkSets)에서 예외로 설정됩니다.
checkSet 수준 예외
다음 예시는 검사 집합 수준에서 이미지를 예외로 설정하는 방법을 보여줍니다.
gkePolicy:
checkSets:
imageAllowlist:
- allowPattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images1/**"
- allowPattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images2/**"
checks:
...
정책에서 imageAllowlist에 나열된 이미지는 checkSets에 나열된 모든 검사에서 예외로 설정됩니다.
checks 수준 예외
다음 예시는 검사 수준에서 이미지를 예외로 설정하는 방법을 보여줍니다.
gkePolicy:
checkSets:
checks:
imageAllowlist:
- allowPattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images1/**"
- allowPattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images2/**"
...
여러 검사 집합 사용
CV 검사 기반의 정책은 검사 집합을 하나 이상 포함할 수 있습니다. CV는 정책을 평가할 때마다 하나의 검사 집합을 평가합니다. 검사 집합은 여러 상황에서 평가되는 하위 정책으로 이해할 수 있습니다. 예를 들어 프로덕션 환경에서 수행하는 서로 다른 검사를 개발 환경에서 적용하려면 각 환경에 대한 검사를 개발 환경에서만 평가되는 집합과 프로덕션 환경에서 평가되는 집합과 같이 별도의 검사 집합에 배치할 수 있습니다.
각 검사 집합의 범위는 Kubernetes 네임스페이스 또는 Kubernetes 서비스 계정으로 지정됩니다. 이러한 범위에 따라 검사 집합이 적용되는 포드가 결정됩니다.
검사 집합에 범위가 구성되면 해당 범위에서 실행 중인 포드에만 적용됩니다.
검사 집합에 범위가 없으면 이를 기본 검사 집합이라고 부르며, Kubernetes 네임스페이스 또는 서비스 계정 범위에 관계없이 모든 포드에 검사가 적용됩니다.
CV 가이드에서 대부분의 정책 예시에는 기본 검사 집합만 사용됩니다.
다음 예시 정책 구성은 3개의 검사 집합을 구성합니다.
gkePolicy:
checkSets:
- displayName: "Prod check set"
scope:
kubernetesNamespace: "prod-namespace"
checks:
- trustedDirectoryCheck:
trustedDirPatterns: "gcr.io/my-project/prod-images"
- imageFreshnessCheck:
maxUploadAgeDays: 30
- displayName: "Dev check set"
scope:
kubernetesNamespace: "dev-namespace"
checks:
- trustedDirectoryCheck:
trustedDirPatterns: "gcr.io/my-project/dev-images"
- displayName: "Default check set"
checks:
- alwaysDeny: true
예시 구성에서 첫 번째 검사 집합은 범위가 prod-namespace로 지정되므로 해당 범위에서 실행되는 포드에만 검사가 적용됩니다. 두 번째 검사 집합은 범위가 dev-namespace로 지정되므로, 이 범위에서 실행되는 포드에만 검사가 적용됩니다.
세 번째 검사 집합은 기본 검사 집합입니다. 이 검사는 prod-namespace 및 dev-namespace 범위 외부에서 실행되는 클러스터의 모든 포드에 적용됩니다.
CV는 Prod check set라는 검사 집합을 평가할 때 prod-namespace Kubernetes 네임스페이스에서 실행되는 포드 이미지에 대해 다음을 검사합니다.
- 이미지가 신뢰할 수 있는
prod-images디렉터리에 저장되었는지 검사합니다. - 이미지가 이전 30일 내에 업로드되었는지 확인합니다.
CV는 Dev check set라는 검사 집합을 평가할 때 dev-namespace Kubernetes 네임스페이스에서 실행 중인 포드를 평가하여 해당 포드의 이미지가 dev-images 디렉터리에서 왔는지 확인합니다.
기본 검사 집합은 캐치올(catch-all) 방식으로 작동합니다. 항상 거부 검사는 CV가 다른 네임스페이스에서 실행되는 모든 포드를 로깅하도록 보장합니다.
Kubernetes 서비스 계정을 검사 집합의 범위로 사용하려면 예시에서 kubernetesNamespace 키를 kubernetesServiceAccount로 바꿉니다. 값은 my-namespace:my-service-account 형식입니다.
검사 집합 범위에는 다음 규칙이 포함됩니다.
플랫폼 정책에는 범위당 검사 집합이 하나만 있을 수 있습니다.
정책에 네임스페이스 범위의 검사 집합과 서비스 계정 범위의 검사 집합이 모두 포함된 경우 서비스 계정 범위의 검사 집합이 먼저 나열되고 이어서 네임스페이스 범위의 검사 집합이 나열됩니다.
기본 검사 집합은 하나만 있을 수 있고 마지막에 나열되어야 합니다.
플랫폼 정책에 검사 집합이 포함된 경우 기본 검사 집합이 하나 이상 포함되어야 합니다. 검사 집합이 없는 플랫폼 정책도 허용되지만 위반 사항을 검사하지 않으므로, CV에서 어떠한 로그 항목도 생성되지 않습니다.
기존 CV
이 섹션에서는 기존 CV 정책에 대해 설명합니다. CV를 처음 사용하는 경우 대신 검사 기반 정책이 포함된 CV를 사용하는 것이 좋습니다.
기존 CV 사용자를 지원하려면 GKE를 실행하는 프로젝트에서 CV를 사용 설정할 수 있습니다. 그러면 CV가 Binary Authorization 시행 정책을 사용해서 Binary Authorization 시행이 사용 설정되지 않은 클러스터를 포함하여 프로젝트의 모든 클러스터에서 실행되는 모든 포드를 검사합니다.
기존 CV 사용(지원 중단됨) 방법과 Cloud Logging에서 기존 CV 이벤트 보기 방법을 알아보세요.
다음 단계
- 이미지 최신 상태 검사 사용
- 단순 서명 증명 검사 사용
- Sigstore 서명 확인 사용
- SLSA 검사 사용
- 신뢰할 수 있는 디렉터리 검사 사용
- 취약점 검사 사용
- CV 로그 보기
- Binary Authorization에 대해 알아보기