CI 파이프라인에서 정책 관리자 사용

이 페이지에서는 Git 저장소와 동기화된 정책 유효성 검사를 확인하는 CI(지속적 통합) 파이프라인을 생성하여 Policy Controller를 Cloud Build와 통합하는 방법에 대해 설명합니다.

개발자가 회사 정책에 따라 앱 유효성을 검사하는 목적이라면 대신 지속적 통합 파이프라인에서 회사 정책에 따라 앱 유효성 검사를 참조하세요.

소개

Policy Controller를 사용하여 CI 파이프라인을 작성하면 다음을 수행할 수 있습니다.

  • 정의된 정책 구성을 적용하고 개발자에게 가능한 한 빨리 의견을 제공합니다. 정책을 사용하면 플랫폼 관리자가 액세스를 잠글 수 있습니다. 그러면 개발팀은 정책을 삭제하거나 우회하는 대신 정책을 준수해야 합니다.

  • 항상 있어야 하는 Kubernetes 객체에 기본 필드를 설정합니다. 예를 들어 소유자 또는 비용 센터에 대한 라벨을 자동으로 추가할 수 있습니다.

이 문서는 GitHub 구성 저장소를 사용하는 Cloud Build CI 파이프라인에 중점을 둡니다. 동일한 패턴을 사용하여 Anthos Config Management가 지원하는 다른 CI 도구 또는 버전 제어 시스템을 설정할 수 있습니다.

이 파이프라인은 KPT 기능으로 구축되었습니다. KPT 기능을 사용하면 클라이언트 측 컨테이너 이미지를 개발하여 Kubernetes 구성을 확인, 변환 또는 생성할 수 있습니다.

이 주제에서는 KPT 함수 카탈로그에서 사전 빌드된 KPT 함수를 사용합니다. 카탈로그의 기능 중 하위 집합은 Google 지원 Container Registry에 미러링되었으며 모든 프로젝트에서 사용할 수 있습니다.

시작하기 전에

  • Anthos Config Management를 사용하여 Policy Controller를 설치하려면 Anthos 권한이 있어야 합니다.

  • Anthos Config Management가 이미 설치된 클러스터가 필요합니다.

  • Policy Controller를 설정합니다.

  • Google Cloud 프로젝트에 대한 serviceusage.services.enable 권한이 있고 Cloud Build API에 대한 servicemanagement.services.bind 권한이 있습니다. Cloud Build 서비스 계정을 사용 설정하려면 이러한 권한이 필요합니다. 자세한 내용은 API 사용 설정을 참조하세요.

  • 프로젝트에서 Cloud Build를 활성화합니다. 이는 Google Cloud Console을 통해 수행할 수 있습니다.

구조화되지 않은 저장소 사용

이 가이드에는 구조화되지 않은 저장소를 사용하는 옵션이 포함되어 있습니다. 구조화되지 않은 저장소에는 기본 Anthos Config Management 디렉터리 구조가 필요하지 않습니다.

Cloud Build 구성

파이프라인을 구성하는 각 프로젝트의 Cloud Build 서비스 계정에 'Kubernetes Engine 개발자' 역할을 부여해야 합니다.

  1. Cloud Build 설정 페이지 열기

    서비스 계정 권한 페이지가 표시됩니다.

  2. Kubernetes Engine이 포함된 행을 찾아 상태사용으로 설정합니다.

자세한 내용은 서비스 계정 권한 설정을 참조합니다.

환경 설정

Cloud Build에서 작동하도록 Policy Controller를 구성하려면 Git 저장소 예시를 참조합니다.

git로 저장소를 클론합니다.

git clone git@github.com:GoogleCloudPlatform/csp-config-management.git

계층적 저장소를 사용하는 경우 Cloud Build를 설정한 후에 저장소에서 구성 파일을 편집해야 합니다.

디렉터리 구조

저장소 csp-config-management에는 계층적 저장소(ci-pipeline/) 및 구조화되지 않은 저장소(ci-pipeline-unstructured/)에 대한 구성이 포함된 두 개의 디렉터리가 있습니다. 클러스터 유형에 적합한 디렉터리를 선택합니다.

저장소의 ci-pipeline/ci-pipeline-unstructured/ 디렉터리는 다음 계층을 사용합니다.

  • config-root/는 저장소의 루트이며 이 예시에 대한 모든 구성을 포함합니다.

  • config-root/.../*-constraint.yaml*-template.yamlconfig-root/의 모든 구성이 통과해야 하는 Policy Controller 제약조건 및 템플릿을 정의합니다.

    예를 들면 다음과 같습니다.

    • ci-pipeline/config-root/cluster/required-labels-constraint.yaml 파일을 사용하려면 각 네임스페이스에 cost-center 라벨이 있어야 합니다.

    • ci-pipeline-unstructured/config-root/constraints/banned-key-constraint.yaml 파일은 private-key 필드를 포함하는 ConfigMap 객체가 없도록 강제합니다.

    자세한 정보는 제약조건 작성을 참조합니다.

  • cloudbuild.yaml은 빌드 단계를 정의하는 Cloud Build 구성 파일입니다. 이러한 빌드 단계는 저장소에 대한 커밋에 의해 트리거됩니다.

    파이프라인은 계층적 저장소를 사용하여 nomos hydrate로 저장소의 콘텐츠를 빌드하고 이를 연결한 후 Policy Controller로 유효성을 검증합니다.

    구조화되지 않은 저장소에서 Policy Controller는 nomos를 사용하거나 클러스터에 연결하지 않고 구성을 작성합니다.

    구성 파일의 내용에 대한 자세한 정보는 기본 구성 작성을 참조합니다.

Cloud Build 구성

이 섹션에서는 Cloud Build를 소스 저장소에 연결하여 Cloud Build가 해당 저장소에서 코드를 빌드할 수 있도록 합니다.

빌드 트리거 만들기

Cloud Build는 커밋이 분기로 푸시될 때 빌드 트리거를 실행합니다. Google Cloud Console에서 빌드 트리거를 구성하려면 다음 단계를 수행합니다.

  1. Google Cloud Console에서 트리거 페이지를 엽니다.

    트리거 페이지 열기

  2. 페이지 상단의 프로젝트 선택기 드롭다운 메뉴에서 프로젝트를 선택합니다.

  3. 열기를 클릭합니다.

  4. 트리거 만들기를 클릭합니다.

  5. 트리거의 이름을 작성합니다.

  6. 이벤트에서 분기로 푸시를 선택합니다.

  7. 저장소를 선택합니다. 저장소를 연결하지 않은 경우 다음 단계를 완료합니다.

    1. 저장소 연결을 클릭합니다.

    2. 소스 코드를 저장한 저장소를 선택합니다.

      소스 저장소로 GitHub(미러링) 또는 Bitbucket(미러링)을 선택하면 Cloud Build는 Cloud Source Repositories에서 저장소를 미러링하고 미러링된 저장소를 사용합니다.

    3. 계속을 클릭합니다.

    4. 사용자 이름과 비밀번호를 사용하여 소스 저장소에 인증합니다.

    5. 사용 가능한 저장소 목록에서 원하는 저장소를 선택한 다음 저장소 연결을 클릭합니다.

  8. 사용 가능한 저장소 목록에서 저장소 csp-config-management를 선택합니다.

  9. 분기, master를 선택합니다.

  10. 빌드 구성에서 Cloud Build 구성 파일ci-pipeline/cloudbuild.yaml 또는 ci-pipeline-unstructured/cloudbuild.yaml로 설정합니다.

  11. 만들기를 클릭하여 빌드 트리거를 저장합니다.

gcloud로 빌드 트리거를 작성할 수도 있습니다. 자세한 정보는 빌드 트리거 작성 및 관리를 참조합니다.

저장소 구성

Cloud Build가 저장소에 연결되도록 구성된 후에 Anthos Config Management 구성을 완료합니다.

  1. csp-config-management/CODEOWNERS 파일을 수정하고 @OWNERGitHub 사용자 이름 또는 플랫폼 관리팀의 이메일 별칭으로 바꿉니다. CODEOWNERS 구문에 대한 자세한 내용은 codeowners 정보를 참조합니다.

아래에서 계층적(기본값) 또는 구조화되지 않은 저장소를 사용 중인 경우 선택합니다.

  1. 구성 파일 설정

    계층

    csp-config-management/ci-pipeline/cloudbuild.yaml 파일을 수정합니다.

    CLUSTER_NAMEZONE을 Anthos Config Management와 Policy Controller가 설치된 GKE 클러스터의 클러스터 이름 및 영역으로 바꿉니다.

    구조화되지 않음

    이 예시에서는 구조화되지 않은 저장소를 사용하여 구성을 변경할 필요가 없습니다. Anthos Config Management 및 Policy Controller는 클러스터에 연결하지 않고 저장소의 유효성을 검사합니다.

  2. 저장소에 변경사항을 추가하고 커밋합니다.

    계층

    cd ci-pipeline
    git add .
    git commit -m "[COMMIT_MESSAGE]"

    구조화되지 않음

    cd ci-pipeline-unstructured
    git add .
    git commit -m "[COMMIT_MESSAGE]"

    커밋 후 Cloud Build는 저장소에서 정책 유효성 검사를 실행합니다.

  3. Cloud Build 기록을 열고 가장 최근의 빌드를 클릭합니다.

    빌드 세부정보 페이지가 나타납니다.

  4. csp-config-management 저장소의 샘플에 오류가 있습니다.

    아이콘이 포함된 목록의 맨 위에서 가장 최근 빌드를 선택합니다.

  5. Cloud Build가 실행하는 마지막 단계가 종료되면서 오류가 발생합니다. 오류는 다음과 같습니다.

    계층

    Error: Found 1 violations:
    [1] All namespaces must have a cost-center label that points to your division
    name: "shipping-prod"
    path: namespace_shipping-prod.yaml

    구조화되지 않음

    Step #2: Error: Found 1 violations:
    [1] The following banned keys are being used in the config map: {"private_key"}
    name: "super-secret"
    path: configmap.yaml

  6. 다음으로 저장소에서 파일을 편집하여 오류를 수정합니다.

    계층

    /ci-pipeline/config-root/namespaces/online/shipping-app-backend/shipping-prod/namespace.yaml 파일을 편집하고 metadata.labels.cost-center에 대한 값을 설정합니다. namespace.yaml은 다음과 같아야 합니다.

    apiVersion: v1
    kind: Namespace
    metadata:
      name: shipping-prod
      labels:
        env: prod
        cost-center: "shipping.foo-corp.com"
      annotations:
        audit: "true"
    

    구조화되지 않음

    /ci-pipeline-unstructured/config-root/configmap.yaml 파일을 수정합니다. data.private_key 필드를 data.public_key로 변경합니다. 편집한 YAML은 다음과 같습니다.

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: super-secret
      namespace: default
    data:
      public_key: no secrets here
    

    다음으로 변경사항을 커밋하고 푸시합니다.

    git add .
    git commit -m "[COMMIT_MESSAGE]"
    git push origin [BRANCH]
  7. Cloud Build 기록을 열고 가장 최근의 빌드를 클릭합니다.

    빌드 세부정보 페이지가 나타납니다.

  8. 새 빌드는 성공이어야 합니다.

문제 해결

문제: Cloud Build 빌드가 실패하고 기록에 다음 오류가 포함됩니다.

  [1] KNV1021: No CustomResourceDefinition is defined for the type "ConstraintTemplate.templates.gatekeeper.sh" in the cluster.
  Resource types that are not native Kubernetes objects must have a CustomResourceDefinition.

솔루션: Policy Controller 설치를 확인합니다.

다음 단계