지속적 검증 개요

검사 기반 플랫폼 정책을 사용한 지속적 검증(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를 사용하려면 일반적으로 다음을 수행합니다.

  1. 사용하려는 검사를 결정합니다.
  2. 정책 YAML 파일을 사용해서 하나 이상의 플랫폼 정책을 구성합니다. 이 파일은 사용할 검사를 지정합니다.
  3. 플랫폼 정책을 만듭니다. 선택한 프로젝트에 정책을 저장할 수 있습니다.
  4. 개별 클러스터 또는 Fleet에서 CV를 사용 설정할지 여부를 선택합니다.
  5. Logging의 CV 로그에서 이벤트를 검사합니다.
  6. 로그를 검토하고 빌드 및 기타 프로세스를 업데이트하여 검사를 충족하는 이미지를 생성합니다.

수표

이 섹션에서는 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

checkscheckSetsdisplayName 필드는 선택사항입니다. 이 필드는 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"
          -