런타임 환경을 보호하려면 배포 기준을 사용하여 정책을 정의하고 배포 전후에 정책 준수를 검증합니다. 사전 정의된 증명자가 서명한 코드만 허용하는 정책을 정의하면 배포를 제한하고 신뢰할 수 있는 출처의 코드만 배포하는 데 도움이 됩니다.
배포 기준의 예는 다음과 같습니다.
심각도가 중간 이상인 알려진 취약점 없음
소스 코드가 신뢰할 수 있는 소스 저장소에서 가져온 것임
신뢰할 수 있는 빌드 서비스가 빌드를 실행함
배포하는 빌드 아티팩트가 신뢰할 수 있는 아티팩트 저장소에서 가져온 것임
메타데이터 생성
이러한 요구사항을 검증하려면 빌드 아티팩트에 관한 메타데이터를 제공해야 합니다.
빌드 출처
빌드 출처는 빌드된 이미지의 다이제스트, 입력 소스 위치, 빌드 도구 모음, 빌드 기간과 같은 빌드에 대한 검증 가능한 데이터 모음입니다. 보안 상태를 평가하기 위한 프레임워크인 SLSA는 출처 모델과 출처 요구사항을 제공합니다. 출처는 프레임워크의 요구사항 카테고리 중 하나이며, 각 요구사항은 완화 조치를 점진적으로 구현할 수 있도록 SLSA 수준과 연결됩니다.
SLSA 수준 1 보증의 경우 출처를 사용할 수 있어야 합니다.
SLSA 레벨 2 보증의 경우 출처가 생성되어야 하며 소비자가 출처의 진위성과 무결성을 확인할 수 있어야 합니다.
SLSA 수준 3 및 4는 출처 서명 및 출처 데이터 세부정보의 심도에 관한 요구사항이 더 엄격합니다.
일부 빌드 서비스는 빌드 출처 기록 메타데이터를 생성합니다.
Google Cloud에서 Cloud Build는 SLSA 수준 3 빌드를 지원하는 컨테이너 이미지의 빌드 출처를 생성하고 서명합니다.
SLSA 프레임워크는 GitHub 출처 도구를 제공합니다.
이 도구는 SLSA 수준 3의 빌드 및 provenance 카테고리의 요구사항을 충족하는 위조할 수 없는 SLSA 출처를 GitHub에서 생성합니다.
취약점 스캔 소프트웨어는 소스 코드를 확인하고 아티팩트에 알려진 취약점이 있는지를 확인합니다. Artifact Analysis는 Artifact Registry로 푸시된 컨테이너 이미지에 취약점이 있는지를 자동으로 스캔할 수 있습니다. 아티팩트를 저장하기 전에 아티팩트에 있는지 확인하려면 로컬 개발 환경에서 또는 Cloud Build 빌드 단계와 같은 CI/CD 파이프라인에서 On-Demand Scanning API를 사용할 수 있습니다.
정책 시행 설정
배포 가능한 아티팩트에 관한 메타데이터가 있으면 정책을 시행할 도구가 필요합니다.
Google Cloud에서 배포의 Binary Authorization에서 정책을 구성할 수 있습니다. Binary Authorization은 지원되는 컨테이너 기반 플랫폼에 대한 배포 시도에 정책을 적용합니다. 또한 GKE, Cloud Run, GKE Enterprise에서 실행되는 워크로드에 대해 지속적인 정책 검증을 수행합니다.
사전 배포 검사는 제외된 이미지 목록에 없는 모든 이미지를 차단하므로, 신뢰할 수 있는 등록처의 신뢰할 수 있는 이미지만 배포됩니다.
정책에 특정 필수 프로세스로 이미지가 성공적으로 빌드되었음을 나타내는 디지털 문서인 증명이 요구될 수도 있습니다. 예를 들어 증명으로 이미지에 대한 다음과 같은 사실을 확인할 수 있습니다.
지속적 검증은 정책 검증을 배포 후 환경으로 확장합니다. Binary Authorization을 사용 설정하면 Cloud Logging에서 정책 적합성을 정기적으로 로깅하여 포드 수명 주기 전체에서 검증을 제공합니다. 이는 다양한 상황에서 유용합니다.
예를 들어 컨테이너를 배포한 후 정책을 변경하면 지속적 검증은 업데이트된 정책을 위반하는 포드를 로깅합니다. 또한 테스트 실행 또는 breakglass로 배포된 포드의 정책 위반을 로깅합니다.
게이트 배포 서비스 사용
배포 게이트를 사용하면 독립형 CI/CD 서비스 또는 프로세스 자동화 시스템과 통합된 CI/CD 서비스를 사용하여 배포 프로세스의 특정 지점에서 배포를 승인하거나 거부할 수 있습니다. 게이트된 배포를 사용하면 승인되지 않은 사용자가 애플리케이션 환경을 변경하지 못하도록 할 수 있습니다. 또한 배포 프로세스에 대한 추가 감독과 승인에 대한 가시성을 제공합니다.
Google Cloud에서 Cloud Deploy는 Google Kubernetes Engine에 워크로드를 배포하기 위한 완전 관리형 서비스를 제공합니다. 게이트 배포 기능을 사용하면 사용자는 대상으로 승격하기 위해 승인이 필요한지 여부를 지정할 수 있습니다.
워크로드 모니터링
워크로드는 GKE 및 Cloud Run과 같은 컨테이너 기반 플랫폼에서 실행되는 애플리케이션입니다. 배포하는 워크로드는 공격 노출 영역을 제한하는 강화된 구성이 있어야 합니다.
클러스터에서 워크로드를 검사하여 구성 문제를 확인하는 것은 대규모인 경우 수동으로 수행하기 어려울 수 있습니다. Google Cloud 는 Cloud Run 및 GKE에서 대시보드를 제공하여 워크로드의 보안 통계를 확인합니다.
GKE 보안 상황 대시보드는 Google 권장사항에 따라 클러스터의 보안 상황을 강화하기 위한 안내를 제공합니다. 여기에는 모든 워크로드에서 알려진 구성 문제를 확인하는 자동 워크로드 구성 스캔이 포함됩니다. GKE는 배포된 각 워크로드를 포드 보안 표준의 정책과 같은 관련 권장사항과 대조합니다.
GKE에서 발견된 문제의 심각도를 평가하고 활용 가능한 권장사항과 로그를 반환합니다. Cloud Logging을 사용하면 감사 및 관측 가능성을 개선할 수 있도록 감사 가능한 문제를 추적할 수 있습니다. GKE 보안 상황 대시보드에서 보안 통계를 보는 방법에 관한 안내는 GKE에 배포 및 보안 통계 보기를 참고하세요.
Cloud Run에는 보안 패널이 포함되어 있습니다. 이 패널은 SLSA 빌드 수준 규정 준수 정보, 빌드 출처, 실행 중인 서비스에서 발견된 취약점과 같은 소프트웨어 공급망 보안 통계를 표시합니다. Cloud Run 보안 통계 패널에서 보안 통계를 보는 방법은 Cloud Run에 배포 및 보안 통계 보기를 참고하세요.
Google Cloud 는 소프트웨어 개발 수명 주기 전반에서 보안 상황을 개선하기 위한 다른 서비스와 기능도 제공합니다. 자세한 내용은 소프트웨어 공급망 개요를 참고하세요.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[],[],null,["# Safeguard deployments\n\nThis document describes best practices for protecting your deployments.\n\nCreate and enforce deployment policies\n--------------------------------------\n\nTo protect your runtime environments, define policies with criteria for\ndeployment and validate policy compliance before and after deployment. Defining\na policy that only allows code signed by predefined attestors helps in gating deployments and deploying only code from trusted origins.\n\nExamples of deployment criteria include:\n\n- No known vulnerabilities with a severity above Medium\n- Source code is from a trusted source repository\n- A trusted build service ran the build\n- Build artifacts you are deploying are from a trusted artifact repository\n\n### Generate metadata\n\nTo validate these requirements, your need to provide metadata about your build\nartifacts.\n\nBuild origins\n\n: *Build provenance* is a collection of verifiable data about a build such as\n the digests of built images, the input source locations, the build toolchain,\n and the build duration. [SLSA](https://slsa.dev), a framework for assessing security\n posture, provides a [model for provenance](https://slsa.dev/provenance/) and\n [requirements for provenance](https://slsa.dev/spec/v0.1/requirements#provenance-requirements). Provenance is one requirement\n category in the framework, and each requirement is associated with SLSA\n levels so that you can incrementally implement mitigations.\n\n - For SLSA level 1 assurance, provenance must be available.\n - For SLSA level 2 assurance, provenance must be generated and consumers must be able to verify its authenticity and integrity.\n - SLSA Levels 3 and 4 have stricter requirements for provenance signing and depth of provenance data detail.\n\n: Some build services generate build provenance metadata.\n\n - In Google Cloud, Cloud Build [generates and signs build provenance](/build/docs/securing-builds/view-build-provenance) for container images supporting SLSA level 3 builds.\n - The SLSA framework provides [GitHub provenance tools](https://github.com/slsa-framework/slsa-github-generator). The tools generate non-forgeable SLSA provenance on GitHub that meet requirements in the [build](https://slsa.dev/spec/v0.1/requirements#build-requirements) and [provenance](https://slsa.dev/spec/v0.1/requirements#provenance-requirements) categories for SLSA level 3.\n - The open source [sigstore](https://www.sigstore.dev) project includes the [cosign](https://github.com/sigstore/cosign) tool for signing containers.\n\nVulnerabilies\n\n: Vulnerability scanning software checks your source code and build artifacts\n for known vulerabilties. Artifact Analysis can\n [automatically scan](/container-analysis/docs/automated-scanning-howto) container images pushed to Artifact Registry\n for vulnerabiilities. To check artifacts for vulnerabilities before you store\n them, you can use the [On-Demand Scanning API](/container-analysis/docs/on-demand-scanning-howto) in a local development environment or\n in a CI/CD pipeline, such as a [Cloud Build build step](/container-analysis/docs/ods-cloudbuild).\n\n### Set up policy enforcement\n\nOnce you have metadata about your deployable artifacts, you need tools to\nenforce your policies.\n\nIn Google Cloud, you can configure a policy in\n[Binary Authorization](/binary-authorization/docs/overview) for your deployments. Binary Authorization\nenforces policy for attempted deployments to supported container-based\nplatforms. It can also perform continuous validation of policy for workloads\nrunning on GKE, Cloud Run, and GKE Enterprise.\n\nPre-deployment checks can block all images that are not in the exempt image\nlist, so that only trusted images are deployed from trusted registries.\nYour policy can also require [attestations](/binary-authorization/docs/key-concepts#attestations), digital documents\nthat signify that the image was built successfully with a specific, required\nprocess. For example an attestion can indicate that an image is:\n\n- [Built by Cloud Build](/binary-authorization/docs/deploy-cloud-build).\n- [Does not contain vulnerabilities above a specified severity](/binary-authorization/docs/creating-attestations-kritis). If there are specitic vulnerabilities that do not apply to your applications, you can add them to an allowlist.\n\n[Continuous validation](/binary-authorization/docs/overview-cv) extends policy validation to the post-deploy\nenvironment. When enabled, Binary Authorization provides validation throughout\nthe Pod lifecycle by regularly logging policy conformance in\n[Cloud Logging](/logging/docs/audit). This is useful in a variety of situations.\nFor example, if you change your policy after deploying a container, continuous\nvalidation logs Pods that violate te updated policy. It also logs policy\nviolations for Pods deployed with [dry run](/binary-authorization/docs/enabling-dry-run) or\n[breakglass](/binary-authorization/docs/using-breakglass).\n\nUse gated deployment services\n-----------------------------\n\nDeployment gating lets you approve or deny deployments at specific points in the\ndeployment process using a standalone CI/CD service or a CI/CD service\nintegrated with a process automation system. Gated deployments prevent\nunauthorized users from making changes to application environments. They provide\nadditional oversight to the deployment process and greater visibility of\napprovals.\n\nIn Google Cloud, [Cloud Deploy](/deploy/docs/overview) offers a fully-managed\nservice for deploying workloads to Google Kubernetes Engine. The\n[gated deployment](/deploy/docs/overview#approvals) feature lets users specify if an approval is\nneeded for promotion to a target.\n\nMonitor your workloads\n----------------------\n\n*Workloads* are applications running on container-based platforms such as\nGKE and Cloud Run. The workloads that you deploy\nshould ideally have a [hardened configuration](/kubernetes-engine/docs/how-to/hardening-your-cluster) that\nlimits their attack surface.\n\nChecking workloads across clusters for configuration issues can be difficult to\ndo manually at scale. Google Cloud provides dashboards in Cloud Run and\nGKE to view security insights for workloads.\n\nThe\n[GKE security posture dashboard](/kubernetes-engine/docs/concepts/about-security-posture-dashboard)\nprovides you with guidance to strengthen the security posture of your clusters\nbased on Google's recommendations. It includes automatic\n[workload configuration scanning](/kubernetes-engine/docs/how-to/protect-workload-configuration), which checks for\nknown configuration concerns across all workloads. GKE checks\neach deployed workload against relevant industry best practices, such as\npolicies in the [Pod Security Standards](https://kubernetes.io/docs/concepts/security/pod-security-standards/).\nGKE rates the severity of discovered issues and returns\nactionable recommendations and logs. You can use [Cloud Logging](/logging/docs/audit) to get\nan auditable trail of concerns for better reporting and observability. For\ninstructions on viewing security insights in the GKE security\nposture dashboard, see\n[Deploy on GKE and view security insights](/software-supply-chain-security/docs/sds/deploy-gke-view-security-insights).\n\nCloud Run contains a security panel that displays software supply\nchain security insights such as the SLSA build level compliance info, build\nprovenance, and vulnerabilities found in running services. For instructions on\nviewing security insights in the Cloud Run security insights panel,\nsee\n[Deploy on Cloud Run and view security insights](/software-supply-chain-security/docs/sds/deploy-run-view-security-insights).\n\nGoogle Cloud also provides other services and features to improve your\nsecurity posture across the software development lifecycle. For more\ninformation, see the\n[software supply chain overview](/software-supply-chain-security/docs/overview).\n\nWhat's next\n-----------\n\n- Learn the [best practices to safeguard source code](/software-supply-chain-security/docs/safeguard-source).\n- Learn the [best practices to safeguard dependencies](/software-supply-chain-security/docs/dependencies).\n- Learn the [best practices to safeguard builds](/software-supply-chain-security/docs/safeguard-builds)."]]
