Google Kubernetes Engine에서 소프트웨어 공급망 보안 강화

이 문서는 Google Kubernetes Engine(GKE) 클러스터에 코드를 배포하기 전에 소프트웨어 공급망이 알려진 안전한 경로를 따르도록 하는 방법을 안내합니다. 이 문서에서는 Binary Authorization의 작동 원리를 살펴본 후 Google Cloud에서 이를 가장 효과적으로 구현하고 사용하는 방법을 설명합니다. 이렇게 하면 배포 파이프라인이 각각의 필수 단계에서 승인 결정에 도움이 되는 정보를 최대한 많이 제공하도록 할 수 있습니다.

State of DevOps 보고서에는 소프트웨어 제공 성능을 향상시키는 기능이 나와 있습니다. 이 문서에서는 다음 기능을 설명합니다.

소프트웨어 공급망을 보호하기 위한 구성 요소

컨테이너형 애플리케이션을 빌드하고 배포할 때는 변경되지 않는 고정 아티팩트를 배포 단위로 사용해야 합니다. 고정 아티팩트를 사용하면 소프트웨어가 예상대로 작동할 것임을 확실히 아는 상태에서 소프트웨어를 여러 호스트와 환경에 배포하고 확장할 수 있습니다.

고정 아티팩트를 빌드한 후에는 나중에 사용할 수 있도록 버전과 카탈로그를 지정하여 아티팩트 저장소에 보관하세요.

체크포인트 표시와 마찬가지로, 출시 프로세스의 다양한 단계에서 사람이나 자동화된 프로세스가 활동 결과를 설명하는 메타데이터를 추가할 수 있습니다. 예를 들어 통합 테스트 모음을 통과했음을 알리는 메타데이터를 이미지에 추가할 수도 있습니다.

아티팩트에 메타데이터가 추가된 후에는 아티팩트가 어떤 검증을 통과해야 인프라에 배포될 수 있는지 정의하는 배포 정책을 만듭니다. 배포 정책을 승인하기 전에 작업 부하가 필수 체크포인트를 모두 통과하는지 검증하는 메커니즘을 빌드하세요. 이러한 유형의 검증은 코드가 실행되기 전에 수행되어 어떠한 배포도 작업 흐름의 필수 단계를 우회하지 못하도록 합니다.

다음 다이어그램은 소프트웨어 공급망 관리의 일반적인 프로세스를 보여줍니다.

소프트웨어 공급망 관리 프로세스

GKE에서 공급망 보호

다음 표에서는 공급망 구성 요소와 해당 Google Cloud 기능을 보여줍니다.

구성 요소 Google Cloud 구현
고정 아티팩트 Docker 이미지
아티팩트 저장소 Container Registry
아티팩트 메타데이터 참고
아티팩트 감사자 증명자
아티팩트 검증 증명
배포 정책 Binary Authorization 정책

배포되는 GKE 고정 아티팩트는 Docker 이미지입니다. 이 이미지는 빌드된 후에 아티팩트 저장소인 Container Registry로 푸시되며, 이곳에 있는 이미지는 GKE 클러스터 수에 관계없이 자유롭게 배포할 수 있습니다.

Container Registry에서는 단일 메타데이터를 나타내는 태그를 사용하여 이미지 정보를 추가합니다. 이미지의 Docker 태그는 일반적으로 v2.0.0 또는 beta와 같이 소프트웨어 버전이나 출시 트레인을 표시합니다. 이 정보도 유용하기는 하지만 이미지가 빌드된 장소, 빌드 시 소스 코드, 프로덕션 환경에서 배포가 승인되었는지 여부 등 아티팩트에 관한 세부정보는 태그를 사용하여 추가할 수 없습니다. 이러한 세부정보를 표시하려면 증명을 사용해야 합니다.

증명자는 Container Registry에서 이미지에 관한 메모를 추가하여 이미지가 특정 조건에 부합하는지 명시할 수 있습니다. 이러한 정보는 이미지 수명 주기 전반에서 액세스할 수 있습니다. 몇몇 종류의 메모는 이미지 정보를 더 효과적으로 필터링할 수 있도록 카테고리별로 분류됩니다. 메모의 한 가지 종류인 attestation은 프로젝트의 증명자가 추가합니다. 예를 들어 이미지가 심각한 보안 취약점 없이 빌드되었는지 또는 특정 빌드 시스템에서 빌드되었는지 검증하는 증명자가 있을 수 있습니다.

연결된 Pretty Good Privacy(PGP) 공개 키를 업로드하여 증명자를 만들고 식별하여 증명자를 프로젝트에 추가합니다. 이후 증명자는 증명 중인 특정 콘텐츠를 지정할 수 있는 이미지 다이제스트를 식별하는 메시지를 서명하여 증명을 만들 수 있습니다.

다음 다이어그램은 특정 다이제스트의 이미지에 증명을 추가하는 예시입니다.

이미지에 증명 추가

Binary Authorization을 사용하면 이미지에 어떤 증명이 있어야 클러스터에 배포할 수 있는지 정의하는 정책을 구성할 수 있습니다. 이 정책은 이미지가 배포 파이프라인에서 중요한 단계를 건너뛰지 않고 올바른 경로를 따라가도록 하는 구성 요소를 만듭니다. 배포 파이프라인의 주요 단계마다 이미지가 해당 단계를 통과했음을 명시하는 증명을 만들 수 있습니다. 증명은 자동화된 시스템이나 사람이 추가할 수 있습니다.

예를 들어 품질 보증(QA)팀이 이미지가 검증을 통과했는지 확인하도록 할 수도 있습니다. 테스트가 완료되면 품질 보증팀 구성원 중 한 명이 특정 키를 사용하여 증명자 qa-validated의 증명에 서명합니다. 이 증명은 프로덕션 클러스터가 이미지를 배포하는 데 필요합니다.

비슷한 사례로, 이미지에서 취약점을 스캔하여 이상이 나타나지 않는지 확인하고 싶을 수도 있습니다. 자동화된 시스템은 저장소에서 새 이미지를 보고, 특정 취약점 표준을 충족한다는 증명을 추가할 수 있습니다. 또 취약점 스캔을 검증한 후에 암호화 키를 사용하여 not-vulnerable 증명자에서 증명을 서명하고 추가할 수 있습니다. Cloud Key Management Service로 이 키를 암호화하고 Cloud Storage에 안전하게 저장하며 ID 및 액세스 관리를 통해 액세스를 제어하고 Cloud Logging을 통해 사용을 감사할 수 있습니다.

다음 다이어그램은 Container Registry의 이미지와 함께, 사람 또는 자동화된 증명자가 추가한 증명을 보여줍니다.

자동화 또는 사람에 의해 추가된 Container Registry 내 이미지

Binary Authorization으로 각각의 증명 검증에 사용할 암호화 키를 정의하는 정책을 만듭니다. 특정 이미지를 예외 이미지 목록에 추가하여 증명 검증을 건너뛰거나 특정 클러스터에 Binary Authorization을 사용 중지할 수도 있습니다.

Google Cloud는 소프트웨어 공급망을 만들고 관리하는 관리형 서비스를 제공하지만 개발자가 오픈소스 구현을 사용하여 유사한 프로세스를 다른 환경에 구현할 수도 있습니다.

다음 표에서는 Google Cloud 서비스와 유사한 기능을 제공하는 오픈소스 도구를 보여줍니다.

Google Cloud 오픈소스
Container Registry Docker 배포
Metadata API Grafeas
Binary Authorization Kritis
취약점 스캔 Clair, Anchore Engine

지속적 배포 파이프라인 권장사항

소프트웨어 공급망 검증은 코드 저장소에서 프로덕션 인프라로 소스 코드를 자동 배포하는 지속적 배포 파이프라인이 있을 때 가장 효과적입니다. 이 파이프라인의 단계는 조직마다 다르지만, 파이프라인이 소프트웨어를 안전하게 배포하는 데 도움이 되는 몇 가지 일반적인 권장사항을 구현할 수 있습니다.

일반 CI/CD 파이프라인 지침

많은 조직에서는 개별 팀이 지속적 배포 프로세스 및 도구를 직접 선택하는 것을 허용합니다. 이러한 유연성 덕분에 자율성이 향상되고 팀은 익숙한 도구를 사용할 수 있지만, 모든 출시 버전이 권장사항을 따르도록 하는 데 복잡한 문제가 생길 수 있습니다. 한 곳에서 방법론을 템플릿화하고 공유, 감사할 수 있도록 도와주는 Spinnaker와 같은 도구에서 팀의 출시 파이프라인을 중앙 집중화하는 것이 좋을 수도 있습니다.

이미지 빌드

여타 공급망과 마찬가지로 소프트웨어의 보안도 실행 가능한 아티팩트를 만드는 데 사용되는 재료가 얼마나 안전한지에 달려 있습니다. GKE를 사용할 때는 안전한 기본 이미지로부터 이미지를 만들어야 합니다.

기본 이미지의 보안을 극대화하는 첫 단계는 애플리케이션을 실행하는 데 필요한 소프트웨어와 라이브러리만 포함하는 최소한의 배포를 사용하는 것입니다. Ubuntu, Debian, CentOS처럼 인기 있는 배포의 경우, Google Cloud는 보안 패치로 정기적으로 업데이트되는 관리형 기본 이미지를 제공합니다. Distroless 이미지다양한 프로그래밍 언어로 작성된 애플리케이션 실행에 필요한 라이브러리와 도구만 포함하는 기본 이미지 세트입니다. 기본 이미지를 선택한 후에는 추가하는 내용을 최소화하세요. Docker의 다단계 빌드를 활용하여 빌드 타임 종속 항목을 런타임 종속 항목과 분리하면 공격에 취약한 부분을 줄일 수 있습니다.

이미지가 빌드된 후에는 조직의 정책에 맞는지 확인하세요. 이미지의 콘텐츠와 메타데이터를 검증하는 컨테이너 구조 테스트를 만들 수 있습니다. container-diff를 사용하여 기존 컨테이너와 새로 빌드된 컨테이너를 비교할 수도 있습니다.

애플리케이션 이미지에 포함되는 내용을 좁힌 후에는 클러스터에서 허용되는 타사 이미지 범위를 감사하고 줄이세요. Binary Authorization을 사용하여 증명 요구사항을 건너뛸 수 있는 예외 이미지 목록에 이미지를 추가할 수 있습니다. 필요하지만 아티팩트 생성 파이프라인에서 빌드할 수 없는 각 이미지에 항목을 최대한 구체적으로 명시해야 합니다.

컨테이너 빌드에 대한 자세한 내용은 컨테이너 빌드를 위한 권장사항 문서에서 찾아볼 수 있습니다.

이미지 취약점 분석 사용 설정

Docker 이미지의 잠재적 보안 문제에 대한 자세한 정보를 얻으려면 프로젝트에서 Container Registry 취약점 스캔을 사용 설정하세요. 이미지가 푸시되는 즉시 실행되는 자동화된 스캔은 이미지의 취약점이 얼마나 심각한지 파악하는 데 도움이 될 수 있습니다. 배포하기 전에 취약점을 확인해야 하지만, 새로운 취약점이 발견될 수도 있기 때문에 배포한 후에도 이미지를 확인해야 합니다. 취약점 스캔은 지난 30일 동안 레지스트리에서 가져온 이미지를 지속적으로 스캔합니다. 이미지에서 취약점이 발견될 때마다 Pub/Sub를 사용하여 알림을 수신할 수 있습니다.

배포 중에 정책 검증

소프트웨어 공급망을 보호하려면 배포 중에 이미지 검증을 사용 설정하세요. 지속적 배포 파이프라인의 마지막 단계는 프로세스가 모든 스테이지를 포함하고 모든 체크포인트를 통과했는지 확인하기에 좋은 시점입니다. 이 접근 방식을 사용하면 누군가 클러스터 사용자 인증 정보에 액세스하더라도 악성 이미지를 배포할 수 없습니다.

Binary Authorization을 사용하면 프로젝트에서 모든 클러스터의 기본 규칙을 구성한 후에 해당 규칙을 클러스터별 구성으로 재정의할 수 있습니다. 예를 들어 모든 클러스터에서 취약점 스캔 및 QA 검증 증명을 요구하도록 하면서 개발자가 QA 검증을 거치지 않고도 development 클러스터에서 새로운 기술과 이미지를 실험해 보도록 할 수 있습니다. Binary Authorization 정책에 대한 자세한 내용은 정책 YAML 참조 문서를 확인하세요.

파이프라인 예시

다음은 두 가지 주요 단계인 빌드와 배포로 나누어진 파이프라인 예시입니다.

샘플 파이프라인의 빌드 및 배포 단계

다음 표에서 파이프라인 단계와 증명을 추가해야 하는 곳을 자세히 확인할 수 있습니다.

단계 번호 요약 설명 증명
아이콘
1 소스 코드 얻기 빌드 시스템이 사용할 버전에서 소스 코드를 확인합니다. 없음
2 단위 테스트 실행 아티팩트를 만들기 전에 코드가 모든 단위 테스트를 통과하는지 확인합니다.

단위 테스트를 실행합니다.

3 Docker 이미지 만들기 로컬 소스 코드에서 Dockerfile을 사용하여 Container Registry에 푸시할 수 있는 이미지를 빌드합니다. 없음
4 Docker 이미지가 정책에 맞는지 확인 컨테이너 구조 테스트를 사용하여 이미지가 올바른 콘텐츠를 포함하고 있고 이미지 안의 명령어가 올바른 출력을 반환하는지 확인할 수 있습니다.

Docker 이미지가 정책에 맞는지 확인

5 Container Registry에 이미지 푸시 코드가 단위 테스트를 거치고 이미지 콘텐츠가 검증되었으면 이미지를 Container Registry에 푸시할 수 있습니다. 취약점 스캔이 자동으로 시작됩니다. 없음
6 이미지에 심각한 취약점이 없는지 확인 취약점 스캔이 완료되는 데는 몇 분이 걸리며 발견되는 Common Vulnerabilities and Exposures(CVE)에 관한 메모가 이미지의 메타데이터에 추가됩니다. 이 데이터가 나타날 때까지 기다린 후에 심각한 취약점이 발견되지 않으면 증명을 추가합니다.

이미지에 심각한 취약점이 없는지 확인

7 스테이징에 이미지 배포 프로덕션 환경과 가장 흡사한 시나리오에서 변경사항을 검증하고 관찰할 수 있는 프로덕션 전 환경에서 배포를 시작합니다.

스테이징에 이미지를 배포합니다.

8 프로덕션 환경에 코드를 배포하도록 승인 변경사항이 요구사항을 충족하는 것으로 모든 신호가 나타날 경우 프로덕션 환경에 배포되도록 승인합니다. 없음
9 프로덕션 클러스터에 코드 배포 이제 전체 클러스터에서 업데이트되도록 이미지를 설정할 수 있습니다. 각 클러스터는 애플리케이션을 실행하기 전에 모든 증명이 완료되었는지 확인합니다. 없음

증명 예

출시 파이프라인에 포함할 수 있는 몇 가지 증명은 다음과 같습니다.

  • 취약점 분석 결과에 심각한 취약점이 포함되지 않았다는 증명
  • 수동 QA 검증을 통과했다는 증명
  • 이미지에 포함된 모든 소프트웨어가 적절한 라이선스를 얻었다는 증명
  • 신뢰할 수 있는 빌드 시스템에서 아티팩트가 생성되었다는 증명

다음 단계