GKE에서 선택적으로 방화벽 정책 적용

이 페이지에서는 태그를 사용하여 Google Kubernetes Engine(GKE)에서 Cloud Next Generation Firewall 네트워크 방화벽 정책을 선택적으로 시행하는 방법을 보여줍니다. 태그는 기본 Cloud de Confiance by S3NS 리소스 계층 구조에 비해 리소스 계층 구조를 구성하는 세밀한 제어 기능을 제공합니다. 태그를 사용하면 정책을 조건부로 적용할 수도 있습니다.

이 페이지는 GKE의 방화벽 정책을 세부적으로 제어하려는 보안 전문가를 대상으로 합니다. Cloud de Confiance by S3NS 콘텐츠에서 참조하는 일반적인 역할 및 예시 태스크에 대해 자세히 알아보려면 일반 GKE 사용자 역할 및 태스크를 참조하세요.

이 페이지를 읽기 전 다음 내용을 숙지해야 합니다.

태그 정보

태그는 조직 또는 프로젝트 수준에서Cloud de Confiance by S3NS 리소스에 주석을 달고 관리할 수 있는 키-값 쌍입니다. 태그를 사용하여 리소스를 정리하고 방화벽 또는 IAM 정책과 같은 정책을 조건부로 적용할 수 있습니다. IAM 액세스 제어를 사용하여 태그를 연결, 생성, 업데이트 또는 삭제할 수 있는 사용자를 정의할 수 있습니다.

태그에 대한 자세한 내용은 Resource Manager 문서의 태그 개요를 참조하세요.

태그를 사용한 네트워크 방화벽 정책 적용

태그를 사용하여 GKE 노드에 전역 또는 리전 네트워크 방화벽 정책을 조건부로 적용할 수 있습니다. 네트워크 방화벽 정책에 사용하려는 태그의 GCE_FIREWALL 용도를 지정해야 합니다. GKE 클러스터 또는 노드 풀에 방화벽 목적 태그를 적용하면 GKE가 이 태그를 해당하는 Compute Engine 가상 머신(VM)에 자동으로 연결합니다.

네트워크 방화벽 정책의 태그를 사용하면 네트워크 태그를 사용할 필요가 없습니다. 이는 누구나 가상 프라이빗 클라우드 방화벽 규칙 시행을 위해 기본 Compute Engine VM에 연결할 수 있는 메타데이터로서 IAM 액세스 제어를 지원하지 않습니다. VPC 방화벽 규칙에서 네트워크 태그를 사용하는 경우 네트워크 방화벽 정책으로 마이그레이션하고 보안 방화벽 태그를 사용하는 것이 좋습니다. 자세한 비교는 이 문서의 네트워크 태그와 태그 비교를 참고하세요.

네트워크 방화벽 정책 워크플로의 태그

GKE에서 네트워크 방화벽 정책과 함께 태그를 사용하려면 다음을 수행하세요.

  1. 태그를 만듭니다.

    1. 조직 또는 프로젝트 수준에서 태그 키(예: env)를 정의합니다.
    2. 키에 가능한 태그 값을 정의합니다(예: dev, staging, prod).

    3. 네트워크 방화벽 정책 사용을 위해 태그를 지정합니다.

  2. 사용자에게 방화벽 태그와 상호작용할 수 있는 액세스 권한을 부여합니다.

  3. 특정 GKE 클러스터, 노드 풀에 태그 키-값 쌍을 적용하거나 맞춤 ComputeClass에서 사용하여 특정 워크로드의 노드에 적용합니다. GKE가 방화벽 정책 시행을 위해 기본 Compute Engine VM에 태그를 자동으로 연결합니다.

시작하기 전에

시작하기 전에 다음 태스크를 수행했는지 확인합니다.

  • Google Kubernetes Engine API를 사용 설정합니다.
    • Google Kubernetes Engine API 사용 설정
  • 이 태스크에 Google Cloud CLI를 사용하려면 gcloud CLI를 설치한 후 초기화합니다. 이전에 gcloud CLI를 설치했으면 gcloud components update 명령어를 실행하여 최신 버전을 가져옵니다. 이전 gcloud CLI 버전에서는 이 문서의 명령어를 실행하지 못할 수 있습니다.

요구사항 및 제한사항

  • 네트워크 방화벽 정책의 태그는 GKE 버전 1.28 이상에서 지원됩니다. 1.28 이전의 GKE 버전을 사용하는 경우 대신 VPC 방화벽 규칙이 있는 네트워크 태그를 사용합니다.
  • Standard 클러스터에서는 각 노드 풀이 최대 5개의 연결된 방화벽 태그를 지원합니다.
  • Autopilot 클러스터는 최대 5개의 방화벽 태그를 지원합니다.
  • 커스텀 컴퓨팅 클래스는 최대 5개의 태그를 지원합니다.
  • GKE는 gke-managed 프리픽스를 사용하는 태그 키를 거부합니다.
  • 태그 키-값 쌍을 클러스터 또는 노드 풀에 연결하기 전에 먼저 만들어야 합니다.

IAM 역할 및 권한

GKE에서 방화벽 정책에 태그를 사용하는 데 필요한 권한을 얻으려면 관리자에게 다음 IAM 역할을 부여해 달라고 요청하세요.

  • 사용자 및 GKE 서비스 에이전트에 태그에 필요한 권한을 다음과 같이 부여합니다.
  • 태그를 만들고 관리하기: 조직 또는 프로젝트에 대한 태그 관리자 (roles/resourcemanager.tagAdmin)
  • 리소스에 태그를 연결하기: 프로젝트에 대한 태그 사용자 (roles/resourcemanager.tagUser)

역할 부여에 대한 자세한 내용은 프로젝트, 폴더, 조직에 대한 액세스 관리를 참조하세요.

커스텀 역할이나 다른 사전 정의된 역할을 통해 필요한 권한을 얻을 수도 있습니다.

태그 만들기

태그를 클러스터나 노드에 연결하려면 태그가 있어야 합니다. 태그를 만들려면 Cloud NGFW 문서의 방화벽에 태그 사용을 참조하세요.

태그 키는 projects/PROJECT_ID 또는 organizations/ORGANIZATION_ID의 parent를 가질 수 있습니다.

Cloud NGFW에서 보안 태그 키를 사용하려면 purpose 속성을 GCE_FIREWALL로 설정해야 하며 purpose-data 속성 값을 network 또는 organization=auto로 지정해야 합니다.

  1. 태그 키를 만듭니다.

    • 네트워크 범위 태그 키를 만듭니다.

      이 태그 키는 purpose-data 필드에 지정된 VPC 네트워크로 범위가 지정됩니다.

      gcloud resource-manager tags keys create TAG_KEY \
    --parent=projects/PROJECT_ID \
    --purpose=GCE_FIREWALL \
    --purpose-data=network=PROJECT_ID/NETWORK_NAME

      다음을 바꿉니다.

      • TAG_KEY: 태그 키의 이름(예: env)
      • PROJECT_ID: Cloud de Confiance 프로젝트 ID
      • NETWORK_NAME: 태그와 함께 사용할 VPC 네트워크의 이름

    • 조직 범위 태그 키를 만듭니다.

      이 태그 키는 조직 내 모든 VPC 네트워크에서 사용할 수 있습니다.

      gcloud resource-manager tags keys create TAG_KEY \
    --parent=projects/PROJECT_ID \
    --purpose=GCE_FIREWALL \
    --purpose-data=organization=auto

      다음을 바꿉니다.

      • TAG_KEY: 태그 키의 이름(예: env)
      • PROJECT_ID: Cloud de Confiance 프로젝트 ID

      organization=auto는 조직 ID로 자동 대체됩니다. 예를 들면 다음과 같습니다.

      purposeData:
  organization: '123456789012'

  2. 태그 키의 ID를 가져옵니다.

    gcloud resource-manager tags keys describe PROJECT_ID/TAG_KEY \
    --format="value(name)"

    tagKeys/KEY_ID가 출력되며, KEY_ID는 키의 숫자 ID입니다. 나중을 위해 이 ID를 기록해 둡니다.

  3. 태그 키에 태그 값을 추가합니다.

    gcloud resource-manager tags values create TAG_VALUE \
    --parent=tagKeys/KEY_ID

    TAG_VALUE를 해당 태그 키에 허용되는 값의 이름(예: dev)으로 바꿉니다.

gcloud CLI 명령어에 올바른 태그 문법 사용

gcloud CLI를 사용하여 태그를 참조할 때는 다음 문법 중 하나를 사용하여 키-값 쌍의 형식을 지정해야 합니다.

태그 구문 
tagKeys/KEY_ID=tagValues/VALUE_ID

다음을 바꿉니다.

  • KEY_ID: 숫자 키 ID
  • VALUE_ID: 숫자 값 ID

예를 들면 tagKeys/123456789=tagValues/987654321입니다.

 
ORGANIZATION_ID/TAG_KEY=TAG_VALUE

다음을 바꿉니다.

  • ORGANIZATION_ID: 숫자로 된 Cloud de Confiance 조직 ID
  • TAG_KEY: 자신이 만든 태그 키의 이름
  • TAG_VALUE: 자신이 만든 태그 값의 이름

예를 들면 12345678901/env=dev입니다.

 
PROJECT_ID/TAG_KEY=TAG_VALUE

다음을 바꿉니다.

  • PROJECT_ID: Cloud de Confiance 프로젝트 ID
  • TAG_KEY: 자신이 만든 태그 키의 이름
  • TAG_VALUE: 자신이 만든 태그 값의 이름

예를 들면 example-project/env=dev입니다.

 
PROJECT_NUMBER/TAG_KEY=TAG_VALUE

다음을 바꿉니다.

  • PROJECT_ID: Cloud de Confiance 프로젝트의 숫자 식별자
  • TAG_KEY: 자신이 만든 태그 키의 이름
  • TAG_VALUE: 자신이 만든 태그 값의 이름

예를 들면 11223344556/env=dev입니다.

방화벽 정책을 사용한 태그 타겟팅

태그를 만든 후 방화벽 정책 규칙에서 특정 키-값 쌍을 참조할 수 있습니다. 안내는 방화벽에 태그 사용을 참조하세요.

서비스 에이전트에게 IAM 권한 부여

GKE가 수직 확장 이벤트 중에 새 노드에 태그를 자동으로 연결하려면 서비스 에이전트라고도 하는 Cloud de Confiance관리형 서비스 계정에 해당하는 IAM 역할을 부여해야 합니다.

  1. Kubernetes Engine 서비스 에이전트에 태그 사용자 역할(roles/resourcemanager.tagUser)을 부여합니다.

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:service-PROJECT_NUMBER@container-engine-robot.s3ns-system.iam.gserviceaccount.com \
    --role=roles/resourcemanager.tagUser \
    --condition=None

    PROJECT_NUMBER를 클러스터의 Cloud de Confiance프로젝트 번호로 바꿉니다. 프로젝트 번호를 찾으려면 다음 명령어를 실행합니다.

    gcloud projects describe PROJECT_ID --format="value(projectNumber)"

  2. 태그 키-값 쌍의 Kubernetes Engine 서비스 에이전트에 태그 보존 조치 관리자 역할(roles/resourcemanager.tagHoldAdmin)을 부여합니다.

    gcloud resource-manager tags values add-iam-policy-binding PROJECT_ID/TAG_KEY/TAG_VALUE \
    --member=serviceAccount:service-PROJECT_NUMBER@container-engine-robot.s3ns-system.iam.gserviceaccount.com \
    --role=roles/resourcemanager.tagHoldAdmin

    이 역할을 통해 서비스 에이전트는 키-값 쌍이 GKE에서 계속 사용 중인 경우 태그 삭제를 방지할 수 있습니다.

  3. Google API 서비스 에이전트에 태그 사용자 역할(roles/resourcemanager.tagUser)을 부여합니다.

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:PROJECT_NUMBER@cloudservices.s3ns-system.iam.gserviceaccount.com \
    --role=roles/resourcemanager.tagUser \
    --condition=None

프로젝트 외부의 태그에 추가 IAM 역할 부여

조직에서 소유한 태그 또는 클러스터 프로젝트가 아닌 다른 프로젝트에서 소유한 태그를 사용하려면 다음 추가 단계를 수행합니다.

  1. 상위 리소스의 태그에 대한 Kubernetes Engine 서비스 에이전트 액세스 권한에 태그 사용자 역할(roles/resourcemanager.tagUser)을 부여합니다.

    gcloud resource-manager tags keys add-iam-policy-binding PARENT_RESOURCE/TAG_KEY \
    --member=serviceAccount:service-PROJECT_NUMBER@container-engine-robot.s3ns-system.iam.gserviceaccount.com \
    --role=roles/resourcemanager.tagUser \
    --condition=None

    다음을 바꿉니다.

    • PARENT_RESOURCE: 해당 태그를 소유하는 리소스의 프로젝트 ID 또는 조직 ID
    • PROJECT_NUMBER: 클러스터 프로젝트의 프로젝트 번호

  2. 상위 리소스의 태그에 대한 Google API 서비스 에이전트 액세스 권한에 태그 사용자 역할(roles/resourcemanager.tagUser)을 부여합니다.

    gcloud resource-manager tags keys add-iam-policy-binding PARENT_RESOURCE/TAG_KEY \
    --member=serviceAccount:PROJECT_NUMBER@cloudservices.s3ns-system.iam.gserviceaccount.com \
    --role=roles/resourcemanager.tagUser \
    --condition=None

  3. 태그 키-값 쌍의 Kubernetes Engine 서비스 에이전트에 태그 보존 조치 관리자 역할(roles/resourcemanager.tagHoldAdmin)을 부여합니다.

    gcloud resource-manager tags values add-iam-policy-binding PARENT_RESOURCE/TAG_KEY/TAG_VALUE \
    --member=serviceAccount:service-PROJECT_NUMBER@container-engine-robot.s3ns-system.iam.gserviceaccount.com \
    --role=roles/resourcemanager.tagHoldAdmin

Autopilot 클러스터에 방화벽 태그 연결

클러스터 수준에서 Autopilot 클러스터에 방화벽 태그를 연결합니다. GKE가 이러한 클러스터 수준 태그를 모든 노드에 자동으로 적용합니다.

새 Autopilot 클러스터를 만들 때 태그 연결

다음 명령어를 실행합니다.

gcloud container clusters create-auto CLUSTER_NAME \
    --location=LOCATION \
    --autoprovisioning-resource-manager-tags=TAG1,TAG2,...

다음을 바꿉니다.

  • CLUSTER_NAME: 새 클러스터의 이름
  • LOCATION: 클러스터의 Compute Engine 리전
  • TAG1,TAG2,...: 연결할 키-값 쌍의 쉼표로 구분된 집합. 명령어 섹션의 태그 구문에 설명된 대로 각 키-값 쌍은 지원되는 구문을 사용해야 합니다. 예를 들면 example-project/env=dev,1234567901/team=sre입니다.

기존 Autopilot 클러스터에 태그 연결

다음 명령어를 실행합니다.

gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --autoprovisioning-resource-manager-tags=TAG1,TAG2,...

클러스터의 태그를 업데이트하면 GKE가 모든 노드의 기존 태그를 덮어씁니다.

Standard 클러스터 및 노드 풀에 방화벽 태그 연결

태그를 연결하는 데 사용하는 방법은 다음과 같이 클러스터의 다른 노드 풀에서 태그를 상속할지 여부에 따라 다릅니다.

Standard 클러스터 방화벽 태그
--autoprovisioning-resource-manager-tags

클러스터 수준 설정

GKE가 클러스터의 모든 새로운 자동 프로비저닝된 노드 풀에 태그를 적용합니다.

기존 클러스터에서 이 플래그를 사용하면 GKE는 클러스터의 기존 노드 풀에 태그를 적용하지 않습니다. 기존 노드 풀은 업데이트 전에 이미 적용된 태그를 유지합니다. 기존 노드 풀의 태그를 업데이트하려면 --resource-manager-tags 플래그를 사용합니다.
--resource-manager-tags

노드 풀 수준 설정

GKE가 지정된 노드 풀에 태그를 적용합니다. 클러스터를 만드는 동안 이 플래그를 사용하면 GKE가 태그를 GKE가 만드는 기본 노드 풀에 적용합니다. 자동 프로비저닝된 노드 풀에서 이 플래그를 사용하면 GKE가 노드 풀의 기존 태그를 덮어씁니다.

Standard 클러스터에 방화벽 태그 연결

새 Standard 클러스터 또는 기존 Standard 클러스터에 태그를 연결할 수 있습니다. 전체 클러스터에 태그를 연결하면 GKE는 이러한 태그가 클러스터 수준에서 설정된 것으로 간주합니다.

노드 자동 프로비저닝으로 새 Standard 클러스터에 태그 연결

GKE는 기본적으로 새 자동 프로비저닝된 노드에 클러스터 수준 태그를 사용합니다. GKE가 클러스터에 만드는 기본 노드 풀은 자동으로 프로비저닝되지 않으며 해당 태그를 가져오지 않습니다.

gcloud container clusters create CLUSTER_NAME \
    --location=LOCATION \
    --autoprovisioning-resource-manager-tags=TAG1,TAG2,... \
    --enable-autoprovisioning \
    --max-cpu=MAX_CPU \
    --max-memory=MAX_MEMORY

다음을 바꿉니다.

  • CLUSTER_NAME: 새 클러스터의 이름
  • LOCATION: 클러스터의 Compute Engine 리전 또는 영역
  • TAG1,TAG2,...: 연결할 키-값 쌍의 쉼표로 구분된 집합. 명령어 섹션의 태그 구문에 설명된 대로 각 키-값 쌍은 지원되는 구문을 사용해야 합니다. 예를 들면 example-project/env=dev,1234567901/team=sre입니다.
  • MAX_CPU: 클러스터의 최대 코어 수
  • MAX_MEMORY: 클러스터의 최대 메모리 용량(GB)

기존 클러스터에서 노드 자동 프로비저닝을 사용 설정할 때 태그 연결

GKE는 이러한 태그를 새 자동 프로비저닝된 노드 풀에만 적용합니다. 기존 노드 풀은 업데이트 전에 있던 태그를 유지합니다.

  1. 클러스터에 태그를 연결합니다.

    gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --autoprovisioning-resource-manager-tags=TAG1,TAG2,...

  2. 클러스터에 노드 자동 프로비저닝을 사용 설정합니다.

    gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --enable-autoprovisioning \
    --max-cpu=MAX_CPU \
    --max-memory=MAX_MEMORY

노드 풀에 방화벽 태그 연결

노드 자동 프로비저닝 사용 여부에 관계없이 새 노드 풀 또는 기존 노드 풀에 태그를 연결할 수 있습니다. GKE는 이러한 태그를 노드 풀 수준 설정으로 간주합니다.

기본 노드 풀에 태그 연결

GKE는 클러스터를 만들 때 --resource-manager-tags 플래그를 사용하여 지정한 태그를 GKE가 클러스터에서 생성하는 기본 노드 풀에 연결합니다.

gcloud container clusters create CLUSTER_NAME \
    --location=LOCATION \
    --resource-manager-tags=TAG1,TAG2,...

다음을 바꿉니다.

  • CLUSTER_NAME: 새 클러스터의 이름
  • LOCATION: 클러스터의 Compute Engine 리전 또는 영역
  • TAG1,TAG2,...: 연결할 키-값 쌍의 쉼표로 구분된 집합. 명령어 섹션의 태그 구문에 설명된 대로 각 키-값 쌍은 지원되는 구문을 사용해야 합니다. 예를 들면 example-project/env=dev,1234567901/team=sre입니다.

새 노드 풀에 태그 연결

노드 풀을 만드는 동안 --resource-manager-tags 플래그를 사용하면 GKE가 지정된 태그를 해당 노드 풀에 연결합니다.

gcloud container node-pools create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --resource-manager-tags=TAG1,TAG2,...

다음을 바꿉니다.

  • NODE_POOL_NAME: 새 노드 풀의 이름
  • CLUSTER_NAME: 클러스터의 이름입니다.
  • LOCATION: 클러스터의 Compute Engine 리전 또는 영역
  • TAG1,TAG2,...: 연결할 키-값 쌍의 쉼표로 구분된 집합. 명령어 섹션의 태그 구문에 설명된 대로 각 키-값 쌍은 지원되는 구문을 사용해야 합니다. 예를 들면 example-project/env=dev,1234567901/team=sre입니다.

기존 노드 풀에 태그 연결

--resource-manager-tags 플래그를 사용하여 기존 노드 풀의 태그를 업데이트하면 GKE가 해당 노드 풀의 기존 태그를 덮어씁니다. 이 명령어를 사용하여 자동 프로비저닝된 노드 풀의 태그를 업데이트할 수 있습니다.

gcloud container node-pools update NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --resource-manager-tags=TAG1,TAG2,...

NODE_POOL_NAME을 업데이트할 노드 풀의 이름으로 바꿉니다.

기존 클러스터 및 노드 풀에서 자동 프로비저닝 설정 전환

클러스터 수준에서 태그를 업데이트하면 GKE가 클러스터의 모든 새 노드 풀에 새로운 태그를 적용하고 기존 노드 풀에 연결된 태그는 유지합니다.

기존 노드 풀을 업데이트하여 노드 자동 프로비저닝을 사용 설정 또는 중지할 경우 태그에 미치는 다음과 같은 영향을 고려하세요.

  • 노드 자동 프로비저닝을 사용 설정하거나 중지할 경우 노드 풀에 기존 태그가 유지됩니다. GKE는 노드 재생성 중에도 이러한 태그를 클러스터 수준 태그로 덮어쓰지 않습니다.
  • 특정 노드 풀의 태그를 수동으로 업데이트하면 GKE가 기존 태그를 노드 풀에 지정된 태그로 덮어씁니다.

커스텀 ComputeClass를 사용하여 워크로드에 태그 적용

커스텀 ComputeClass (CCC)를 사용하여 Autopilot 클러스터와 노드 자동 프로비저닝 (NAP)을 사용하는 Standard 클러스터의 특정 노드 풀에 방화벽 태그를 적용할 수 있습니다. 맞춤 컴퓨팅 클래스는 노드에 적용할 리소스 관리자 태그를 정의하는 등 노드 그룹의 구성을 정의할 수 있는 리소스입니다.

특정 맞춤 컴퓨팅 클래스 라벨이 있는 노드를 요청하는 워크로드를 배포하면 NAP는 먼저 지정된 리소스 관리자 태그를 비롯한 맞춤 컴퓨팅 클래스의 모든 요구사항을 충족하는 노드 풀이 이미 있는지 확인합니다.

일치하는 노드 풀이 없으면 NAP는 지정된 구성으로 워크로드의 새 노드 풀을 만들고 태그를 기본 Compute Engine VM에 연결합니다. 이 자동 노드 풀 생성은 정책 시행을 위해 올바른 방화벽 태그가 있는 노드에서 워크로드가 실행되도록 지원합니다.

태그를 사용하여 커스텀 ComputeClass 만들기

  1. 태그가 있는 ComputeClass를 만들려면 다음 매니페스트를 my-compute-class.yaml로 저장합니다. resourceManagerTags 필드에서 이 클래스를 사용하여 생성된 노드 풀과 연결할 태그 키와 값을 지정합니다.

    apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: COMPUTE_CLASS_NAME
spec:
    nodePoolConfig:
      resourceManagerTags:
        - key: "PROJECT_ID/TAG_KEY_1"
          value: "TAG_VALUE_1"
        - key: "ORGANIZATION_ID/TAG_KEY_2"
          value: "TAG_VALUE_2"
        - key: "tagKeys/KEY_ID"
          value: "tagValues/VALUE_ID"

    다음을 바꿉니다.

    • COMPUTE_CLASS_NAME: 맞춤 컴퓨팅 클래스의 이름입니다(예: my-custom-class).
    • PROJECT_ID: Cloud de Confiance 프로젝트 ID입니다.
    • TAG_KEY_1: 첫 번째 태그 키의 이름입니다.
    • TAG_VALUE_1: 첫 번째 태그 값의 이름입니다.
    • ORGANIZATION_ID: 숫자로 된 Cloud de Confiance 조직 ID입니다.
    • TAG_KEY_2: 두 번째 태그 키의 이름입니다.
    • TAG_VALUE_2: 두 번째 태그 값의 이름입니다.
    • KEY_ID: 태그 키의 숫자 ID입니다.
    • VALUE_ID: 태그 값의 숫자 ID입니다.

  2. 매니페스트를 적용합니다.

    kubectl apply -f my-compute-class.yaml

잘못된 태그를 지정하거나 GKE 서비스 에이전트에 태그에 필요한 IAM 권한이 없는 경우 GKE는 워크로드의 노드 풀을 프로비저닝하지 않으며 워크로드는 Pending 상태로 유지됩니다. 오류에 대한 자세한 내용은 ComputeClass 리소스의 Status 필드를 참고하세요.

상태를 확인하려면 다음 명령어를 실행하세요.

kubectl get cc COMPUTE_CLASS_NAME -o jsonpath='{.status}' | jq .

COMPUTE_CLASS_NAME을 맞춤 컴퓨팅 클래스의 이름으로 바꿉니다.

워크로드에서 커스텀 컴퓨팅 클래스 타겟팅

  1. 생성한 ComputeClass를 타겟팅하려면 다음 매니페스트를 pod-with-ccc.yaml로 저장합니다. 이 매니페스트는 nodeSelector 필드를 사용하여 컴퓨팅 클래스를 타겟팅합니다.

    apiVersion: v1
kind: Pod
metadata:
  name: nginx-server
spec:
  nodeSelector:
    cloud.google.com/compute-class: "COMPUTE_CLASS_NAME"
  containers:
    - name: nginx
      image: nginx:latest

    COMPUTE_CLASS_NAME을 맞춤 컴퓨팅 클래스의 이름(예: my-custom-class)으로 바꿉니다.

  2. 매니페스트를 적용합니다.

    kubectl apply -f pod-with-ccc.yaml

맞춤 컴퓨팅 클래스를 타겟팅하는 워크로드를 예약하면 GKE는 해당 클래스를 위해 생성된 노드에 자동으로 taint를 적용하고 워크로드의 포드에 해당 내결함성을 추가하여 클래스를 명시적으로 요청하는 포드만 해당 노드에 예약되도록 합니다.

유효성 검사 승인 정책 (VAP)으로 워크로드 승인

태그가 있는 노드 풀에 승인된 워크로드만 예약되도록 하려면 유효성 검사 승인 정책을 사용하는 것이 좋습니다. 이 정책은 기본 제공 Kubernetes 기능으로, 포드를 생성하거나 업데이트하는 요청이 유지되기 전에 이를 가로챕니다. 이 차단으로 인해 태그가 지정된 노드에서 승인되지 않은 워크로드가 실행되지 않습니다.

다음 정책은 포드에 나열된 컴퓨팅 클래스 테인트 중 하나의 허용이 포함되어 및 허용된 네임스페이스에 없는 경우 포드 생성 요청을 거부합니다.

  1. 다음 매니페스트를 restrict-toleration.yaml로 저장합니다.

    # Copyright 2025 Google LLC
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#      http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: restrict-toleration
spec:
  failurePolicy: Fail
  paramKind:
    apiVersion: v1
    kind: ConfigMap
  matchConstraints:
    # GKE will mutate any pod specifying a CC label in a nodeSelector
    # or in a nodeAffinity with a toleration for the CC node label.
    # Mutation hooks will always mutate the K8s object before validating
    # the admission request.  
    # Pods created by Jobs, CronJobs, Deployments, etc. will also be validated.
    # See https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#admission-control-phases for details
    resourceRules:
    - apiGroups:   [""]
      apiVersions: ["v1"]
      operations:  ["CREATE", "UPDATE"]
      resources:   ["pods"]
  matchConditions:
    - name: 'match-tolerations'
      # Validate only if compute class toleration exists
      # and the CC label tolerated is listed in the configmap.
      expression: > 
        object.spec.tolerations.exists(t, has(t.key) &&
        t.key == 'cloud.google.com/compute-class' &&
        params.data.computeClasses.split('\\n').exists(cc, cc == t.value))
  validations:
    # ConfigMap with permitted namespace list referenced via `params`.
    - expression: "params.data.namespaces.split('\\n').exists(ns, ns == object.metadata.namespace)"
      messageExpression: "'Compute class toleration not permitted on workloads in namespace ' + object.metadata.namespace"

---
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: restrict-toleration-binding
spec:
  policyName: restrict-toleration
  validationActions: ["Deny"]
  paramRef:
    name: allowed-ccc-namespaces
    namespace: default
    parameterNotFoundAction: Deny
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: allowed-ccc-namespaces
  namespace: default
data:
  # Replace example namespaces in line-separated list below.
  namespaces: |
    foo
    bar
    baz
  # ComputeClass names to monitor with this validation policy.
  # The 'autopilot' and 'autopilot-spot' CCs are present on
  # all NAP Standard and Autopilot clusters.
  computeClasses: |
    MY_COMPUTE_CLASS
    autopilot
    autopilot-spot

  2. 매니페스트를 적용합니다.

    kubectl apply -f restrict-toleration.yaml

조직의 구체적인 보안 요구사항을 충족하도록 승인 정책 검증을 조정합니다.

클러스터의 방화벽 태그 확인

  • Autopilot 클러스터의 태그를 나열합니다.

    gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --format="value(nodePoolAutoConfig.resourceManagerTags)"

    다음을 바꿉니다.

    • CLUSTER_NAME: 클러스터의 이름입니다.
    • LOCATION: 클러스터의 Compute Engine 리전 또는 영역입니다.

  • 특정 노드 풀의 태그를 나열합니다.

    이 명령어는 커스텀 컴퓨팅 클래스로 자동 프로비저닝된 노드 풀의 태그도 확인합니다.

    gcloud container node-pools describe NODE_POOL_NAME \
  --cluster=CLUSTER_NAME \
  --location=LOCATION \
  --format="value(config.resourceManagerTags)"

    다음을 바꿉니다.

    • NODE_POOL_NAME: 노드 풀의 이름
    • CLUSTER_NAME: 클러스터의 이름입니다.
    • LOCATION: 클러스터의 Compute Engine 리전 또는 영역입니다.

클러스터 및 노드 풀에서 방화벽 태그 분리

클러스터 및 노드 풀에서 방화벽 태그를 삭제하려면 태그에 대한 빈 값으로 리소스를 업데이트합니다.

Autopilot 클러스터에서 태그 분리

다음 명령어를 실행합니다.

gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --autoprovisioning-resource-manager-tags=

노드 풀에서 태그 분리

  1. 클러스터 수준 노드 autoprovisioning 태그를 분리합니다.

    gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --autoprovisioning-resource-manager-tags=

    GKE가 새 자동 프로비저닝된 노드 풀에 태그를 연결하지 않습니다.

  2. 노드 풀 태그를 분리합니다.

    gcloud container node-pools update NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --resource-manager-tags=

    GKE가 이 노드 풀에서 기존 태그를 삭제합니다.

태그 키 및 값 삭제

태그 키 또는 값을 삭제하려면 태그가 모든 리소스에서 분리되었는지 확인하세요. 그런 다음 Resource Manager 문서의 태그 삭제를 참조하세요.

네트워크 태그와 태그 비교

방화벽 정책 적용에 태그를 사용하면 네트워크 태그에 비해 보안 및 사용성 측면에서 상당한 이점이 있습니다. 마찬가지로 네트워크 방화벽 정책도 전체 조직, 폴더, 프로젝트, 네트워크에의 방화벽 규칙 적용을 촉진하여 VPC 방화벽 규칙 기능을 개선합니다.

네트워크 방화벽 정책과 함께 태그를 사용하면 더 안전하고 확장 가능한 방식으로 조직 전체의 GKE 환경에 대한 액세스를 관리할 수 있습니다. 태그와 동일한 클러스터에서 네트워크 태그를 사용할 수 있지만 네트워크 태그를 사용하여 네트워크 방화벽 정책을 적용할 수는 없습니다.

태그와 네트워크 태그를 자세히 비교하려면 Cloud NGFW 문서의 태그와 네트워크 태그 비교를 참조하세요.

자동 프로비저닝된 노드 풀의 기능적 차이

Autopilot 클러스터와 노드 자동 프로비저닝을 사용하지 않는 Standard 노드 풀에서 네트워크 태그 및 태그는 비슷한 동작을 보입니다. 다음 표에서는 Standard 클러스터에서 자동 프로비저닝된 노드 풀의 네트워크 태그와 태그 간의 기능 차이를 보여줍니다.

작업 네트워크 태그 동작 태그 동작
GKE가 노드 풀을 자동 프로비저닝합니다. GKE가 클러스터 수준 네트워크 태그를 적용합니다. GKE가 클러스터 수준 태그를 적용합니다.
자동 프로비저닝된 노드 풀에서 태그 또는 네트워크 태그를 업데이트합니다.
  • 클러스터 수준 네트워크 태그가 있으면 업데이트 작업이 실패합니다.
  • 클러스터 수준 네트워크 태그가 없으면 GKE가 노드 풀의 기존 네트워크 태그를 덮어씁니다.
 클러스터 수준 태그가 있는지 여부와 관계없이 GKE가 노드 풀의 기존 태그를 덮어씁니다.
전체 클러스터의 태그 또는 네트워크 태그를 업데이트합니다. GKE가 클러스터의 신규 및 기존 자동 프로비저닝된 노드 풀에 대한 네트워크 태그를 덮어씁니다. GKE가 새로운 클러스터 수준 태그를 새 자동 프로비저닝된 노드 풀에 적용합니다. 기존 자동 프로비저닝된 노드 풀은 업데이트 전에 있던 태그를 유지합니다.

다음 단계