Binary Authorization 개념

참고: 이 문서 또는 섹션에는 Google에서 무례하거나 불쾌감을 준다고 간주하는 용어가 하나 이상 포함되어 있습니다. 이러한 용어는 문서에서 설명되는 소프트웨어의 키워드이므로 사용됩니다.

용어: whitelist

이 페이지에는 Binary Authorization과 연관된 개념 정보가 포함되어 있습니다.

정책

프로젝트 싱글톤 정책이라고도 부르는 Binary Authorization 정책은 컨테이너 이미지 배포를 제어하는 규칙 집합입니다.

지속적 검증(CV)은 플랫폼 정책이라는 다른 유형의 정책을 사용합니다.

정책은 다음으로 구성되어 있습니다.

• 배포 규칙
• 예외 이미지 목록

다음 중 하나를 사용하여 정책을 구성할 수 있습니다.

• Google Cloud 콘솔
• gcloud 명령어

gcloud 명령어를 사용할 경우 정책을 프로젝트로 다시 가져오기 전에 YAML 형식으로 정책의 정의를 내보내고 수정합니다. YAML 형식에는 Binary Authorization 스토리지에 저장된 정책의 내부 구조가 반영됩니다. 이 형식에 대한 자세한 내용은 정책 YAML 참조를 참조하세요.

각 Google Cloud 프로젝트는 정확히 하나의 정책을 포함할 수 있습니다. 배포 플랫폼을 실행하는 프로젝트에서 정책을 구성해야 합니다. 단일 프로젝트 구성에서 정책 및 모든 종속 리소스(증명자 및 attestations)는 동일한 프로젝트에 있습니다. 업무 분리를 설정하려면 다중 프로젝트 구성을 사용하면 됩니다. 이 구성에서 배포 플랫폼은 한 프로젝트에서 실행될 수 있고, 증명자는 다른 프로젝트에 상주할 수 있으며, 증명은 또 다른 프로젝트에 상주할 수 있습니다.

지원되는 플랫폼에서 Binary Authorization을 설정하고 사용하려면 플랫폼별 설정을 참조하세요.

GKE의 멀티 프로젝트 설정 예시를 참조하세요.

규칙

정책을 구성할 때 규칙을 정의합니다. 규칙은 이미지가 배포되기 전에 충족해야 하는 제약조건을 정의합니다. 정책에는 기본 규칙이 하나 있으며 플랫폼에 따라 특정 규칙을 가질 수 있습니다. 자세한 내용은 플랫폼별 지원되는 규칙 유형을 참조하세요.

각 규칙은 평가 모드 및 시행 모드로 구성할 수 있습니다. 예를 들면 이미지가 배포되기 전에 먼저 이미지에는 서명된 증명이 있어야 한다는 규칙입니다.

기본 규칙

각 정책에는 기본 규칙이 있습니다. 이 규칙은 특정 규칙과 일치하지 않는 모든 배포 요청에 적용됩니다. 정책 YAML 파일에서 기본 규칙은 defaultAdmissionRule 노드에 지정되어 있습니다.

기본 규칙 구성에 대한 자세한 내용은 정책 구성을 참조하세요.

특정 규칙

정책에 특정 규칙을 하나 이상 추가할 수 있습니다. 이 유형의 규칙은 특정 클러스터, 서비스 계정 또는 ID에 배포할 이미지에 적용됩니다. 특정 규칙에 대한 지원은 플랫폼별로 다릅니다. 자세한 내용은 플랫폼별 지원되는 규칙 유형을 참조하세요.

정책 YAML 파일에서 각 클러스터별 규칙은 clusterAdmissionRule 노드에 지정되어 있습니다.

플랫폼별 지원되는 규칙 유형

다음 표에서는 각 배포 플랫폼에서 지원되는 규칙 유형을 보여줍니다.

플랫폼	기본 규칙	특정 규칙
GKE	지원됨	클러스터 Kubernetes 네임스페이스 Kubernetes 서비스 계정
Cloud Run	지원됨	지원되지 않음
GKE 연결 클러스터	지원됨	클러스터 Kubernetes 네임스페이스 Kubernetes 서비스 계정
GKE on AWS	지원됨	클러스터 Kubernetes 네임스페이스 Kubernetes 서비스 계정
Google Distributed Cloud	지원됨	클러스터 Kubernetes 네임스페이스 Kubernetes 서비스 계정
Google Distributed Cloud	지원됨	클러스터 Kubernetes 네임스페이스 Kubernetes 서비스 계정
Cloud Service Mesh	지원됨	Cloud Service Mesh 서비스 ID

평가 모드

각 규칙에는 Binary Authorization에서 규칙에 적용하는 제약조건 유형을 지정하는 평가 모드가 있습니다. 규칙의 평가 모드는 정책 YAML 파일의 evaluationMode 속성을 사용하여 지정됩니다.

세 가지 평가 모드가 있습니다.

• 모든 이미지 허용: 모든 이미지의 배포를 허용합니다.
• 모든 이미지 거부: 모든 이미지의 배포를 허용하지 않습니다.
• 증명 필요: 배포 전에 서명자가 이미지 다이제스트를 디지털 서명하고 증명을 만들어야 합니다. 배포 시 Binary Authorization 시행자는 연결된 이미지를 배포하기 전에 증명자를 사용하여 증명의 서명을 확인합니다.

시행 모드

각 규칙에는 시행 모드도 있습니다. 이 모드는 이미지가 규칙을 준수하지 않을 경우 GKE에서 취해야 하는 조치를 지정합니다. 규칙에는 다음과 같은 시행 모드가 있을 수 있습니다.

• 차단 및 감사 로그: 규칙을 준수하지 않는 이미지의 배포를 차단하고 이미지가 배포되지 않은 이유를 설명하는 메시지를 감사 로그에 기록합니다.

• 테스트 실행: 감사 로그만: 테스트 실행 모드는 비준수 이미지 배포를 허용하지만 배포 세부정보를 Cloud 감사 로그에 기록하는 정책의 시행 모드입니다. 테스트 실행 모드를 사용하면 프로덕션 환경에서 시행이 실제로 적용되기 전에 정책을 테스트할 수 있습니다.

대부분의 프로덕션 규칙은 차단 및 감사 로그 시행 모드를 사용합니다. 테스트 실행: 감사 로그 전용은 사용자 환경에서 정책이 적용되기 전에 해당 정책을 테스트하는 데 주로 사용됩니다.

규칙의 시행 모드는 정책 YAML 파일의 enforcementMode 속성을 사용하여 지정됩니다.

Cloud 감사 로그에 기록된 메시지에 대한 자세한 내용은 감사 로그 보기(GKE, GKE 클러스터, Cloud Service Mesh) 또는 감사 로그 보기(Cloud Run)를 참조하세요.

지속적 검증

미리보기

이 기능에는 서비스별 약관의 일반 서비스 약관 섹션에 있는 'GA 이전 제공 서비스 약관'이 적용됩니다. GA 이전 기능은 '있는 그대로' 제공되며 지원이 제한될 수 있습니다. 자세한 내용은 출시 단계 설명을 참조하세요.

지속적 검증(CV)은 지속적인 정책 준수를 위해 포드 실행과 연관된 이미지를 주기적으로 확인하는 Binary Authorization 기능입니다.

CV에 대해 자세히 알아보세요.

예외 이미지

참고: admissionWhitelistPatterns를 사용하여 Google 관리 시스템 이미지를 허용하는 방법은 더 이상 권장되지 않습니다. Google 관리 시스템 이미지를 허용하려면 globalPolicyEvaluationMode를 ENABLE로 설정해야 합니다. 자세한 내용은 globalPolicyEvaluationMode를 참조하세요.

예외 이미지는 정책 규칙에서 제외되는 이미지입니다. Binary Authorization에서는 항상 예외 이미지를 배포할 수 있습니다. 각 프로젝트에는 레지스트리 경로에서 지정된 예외 이미지의 허용 목록이 있습니다. gcr.io/google_containers/* 및 k8s.gcr.io/** 경로와 추가 경로의 이미지에는 GKE가 기본 정책을 활성화한 상태에서 클러스터를 성공적으로 시작하는 데 필요한 리소스가 포함되어 있으므로 기본적으로 제외됩니다.

예외 이미지를 허용 목록에 추가하려면 정책 파일에 다음을 추가합니다.

admissionWhitelistPatterns:
  - namePattern: EXEMPT_IMAGE_PATH

EXEMPT_IMAGE_PATH를 제외할 am 이미지의 경로로 바꿉니다. 추가 이미지를 제외하려면 - namePattern 항목을 추가합니다. admissionWhitelistPatterns에 대해 자세히 알아보세요.

허용 목록 패턴

레지스트리 위치가 지정된 경로와 일치하는 모든 이미지를 허용하려면 다음을 실행하세요.

gcr.io/example-project/*

레지스트리 위치가 지정된 경로의 하위 디렉터리(예: gcr.io/example-project/my-directory/helloworld)인 모든 이미지를 허용하려면 다음을 실행하세요.

gcr.io/example-project/**

특정 이미지를 허용하려면 다음 안내를 따르세요.

gcr.io/example-project/helloworld

태그를 기준으로 특정 버전의 이미지를 허용하려면 다음을 실행하세요.

gcr.io/example-project/helloworld:latest
gcr.io/example-project/helloworld:my-tag

이미지의 모든 버전/태그를 허용하려면 다음 안내를 따르세요.

gcr.io/example-project/helloworld:*

다이제스트를 기준으로 특정 이미지 버전을 허용하려면 다음을 실행하세요.

gcr.io/example-project/helloworld@sha256:77b0b75136b9bd0fd36fb50f4c92ae0dbdbbe164ab67885e736fa4374e0cbb8c

컨테이너 이미지 다이제스트 사용에 대해 자세히 알아보세요.

Google Cloud Console에서, 명령줄 도구를 사용하거나 REST API를 사용하여 예외 이미지를 관리하는 방법을 알아보세요.

Google이 관리하는 시스템 이미지

Google이 관리하는 모든 시스템 이미지 신뢰를 설정하면 Binary Authorization이 추가 정책 평가에서 Google이 관리하는 시스템 이미지 목록을 제외합니다. 이 설정을 사용하면 GKE에 필요한 이미지가 정책 시행으로 차단되지 않습니다. 시스템 정책은 사용자 정책 평가 이전 그리고 평가가 수행될 때 평가됩니다.

이 설정은 정책 YAML 파일에서 globalPolicyEvaluationMode 속성을 사용하여 사용 설정 또는 사용 중지할 수 있습니다. 다음 명령어를 사용하여 시스템 정책의 콘텐츠를 확인할 수 있습니다.

gcloud alpha container binauthz policy export-system-policy

증명

증명은 이미지를 인증하는 디지털 문서입니다. 배포 중에 Binary Authorization은 이미지 배포를 허용하기 전 증명을 확인합니다.

경우에 따라 증명을 만드는 프로세스를 이미지 서명이라고 합니다. 증명은 이미지가 빌드된 후에 생성됩니다. 이러한 각 이미지에는 전역적으로 고유한 다이제스트가 있습니다. 서명자는 키 쌍의 비공개 키를 사용하여 이미지 다이제스트를 서명하고 이 서명을 사용하여 증명을 만듭니다. 배포 시 Binary Authorization 시행자는 증명의 공개 키를 사용하여 증명의 서명을 확인합니다. 일반적으로 각 증명자는 단 하나의 서명자에만 속해야 합니다.

증명은 특정한 필수 프로세스를 성공적으로 실행하여 연결된 이미지가 빌드되었음을 나타냅니다. 예를 들어 서명자가 품질 보증(QA) 팀을 대표하는 경우 증명은 이미지가 스테이징 환경에서 필요한 모든 엔드 투 엔드 테스트를 통과했음을 나타낼 수 있습니다.

Binary Authorization에서 증명을 사용 설정하려면 정책의 evaluationMode가 REQUIRE_ATTESTATION로 설정되어 있어야 합니다.

증명자 및 증명을 만들고 사용하는 방법을 알아보세요.

서명자

서명자는 사람이거나 비공개 키로 고유한 이미지 설명자를 서명하여 증명을 만드는 자동화된 프로세스입니다. 증명은 연결된 이미지가 배포되기 전에 증명에 저장된 해당하는 공개 키로 배포 시에 검증됩니다.

증명자 및 증명을 만들고 사용하는 방법을 알아보세요.

증명자

증명자는 Binary Authorization이 이미지 배포 시에 증명 확인을 위해 사용하는 Google Cloud 리소스입니다. 증명자에는 서명자가 이미지 다이제스트를 서명하고 증명을 만드는 데 사용한 비공개 키에 해당하는 공개 키가 포함됩니다. Binary Authorization 시행자는 배포 시 증명자를 사용하여 배포 전에 함께 생성된 확인 가능한 증명으로 배포할 수 있는 이미지를 제한할 수 있습니다.

증명자는 공개 키 및 비공개 키 쌍을 관리하는 보안 운영 담당자가 관리하는 경우가 많지만 서명자는 일반적으로 배포 가능한 이미지를 생성하고 비공개 키로 서명하며 배포를 시도하기 전에 증명을 만드는 소프트웨어 엔지니어, DevOps QA 또는 규정 준수 담당자입니다.

증명자에는 다음이 포함됩니다.

• 해당하는 Artifact Analysis 메모
• 서명자가 증명을 만드는 데 사용한 비공개 키에 해당하는 1개 이상의 암호화 공개 키

증명 필요 규칙이 포함된 정책을 설정할 때 이미지의 배포 준비가 되었는지 확인하는 데 필요한 사용자 또는 프로세스의 증명자를 추가해야 합니다. Google Cloud 콘솔, gcloud 인터페이스 또는 Binary Authorization REST API를 사용하여 증명자를 추가할 수 있습니다.

증명자 및 증명을 만들고 사용하는 방법을 알아보세요.

암호화 키

정책에 증명 필요 규칙이 포함된 경우 Binary Authorization은 배포 시에 디지털 서명을 사용하여 이미지를 확인합니다.

키 쌍이 생성됩니다. 비공개 키는 서명자가 이미지 설명자를 서명하는 데 사용됩니다. 이렇게 하면 증명이 생성됩니다.

그런 다음 증명자가 생성되어 정책에 저장됩니다. 서명에 사용되는 비공개 키에 해당하는 공개 키가 업로드되고 증명자에 연결됩니다.

Binary Authorization은 이미지를 배포하려고 시도할 때 정책의 증명자를 사용하여 이미지의 증명을 확인합니다. 증명을 확인할 수 있으면 이미지가 배포됩니다.

Binary Authorization은 다음 두 가지 유형의 키를 지원합니다.

• PKIX
• PGP

PKIX 키는 로컬, 외부 또는 Cloud Key Management Service에 저장될 수 있습니다.

암호화 키 및 증명자를 만듭니다.

Artifact Analysis 참고사항

Binary Authorization은 Artifact Analysis을 사용하여 승인 프로세스에 사용된 신뢰할 수 있는 메타데이터를 저장합니다. 생성된 증명자마다 Artifact Analysis 메모를 하나씩 만들어야 합니다. 각 증명은 이 메모의 어커런스로 저장됩니다.

Binary Authorization은 증명자가 이미지를 확인하도록 요구하는 규칙을 평가할 때 Artifact Analysis 스토리지를 검사하여 필요한 증명이 있는지 확인합니다.