개요

이 페이지에서는 Google Distributed Cloud (GDC) 에어 갭의 프로젝트 네트워크 정책을 간략하게 설명합니다.

프로젝트 네트워크 정책은 인그레스 또는 이그레스 규칙을 정의합니다. Kubernetes 네트워크 정책과 달리 정책에 정책 유형을 하나만 지정할 수 있습니다. 정책의 각 규칙은 허용 (기본값) 또는 거부 작업으로 구성할 수 있습니다.

프로젝트 내 트래픽의 경우 GDC는 사전 정의된 프로젝트 네트워크 정책인 기본 프로젝트 내 정책을 각 프로젝트에 적용합니다.

프로젝트의 서비스와 워크로드는 기본적으로 외부 서비스 및 워크로드와 격리됩니다. 하지만 프로젝트 간 트래픽 네트워크 정책을 적용하면 서로 다른 프로젝트 네임스페이스에 속해 있고 동일한 조직 내에 있는 서비스와 워크로드가 서로 통신할 수 있습니다.

마찬가지로 서비스 및 워크로드를 다른 조직의 프로젝트 외부에 있는 대상에 연결하려면 명시적인 승인이 필요합니다. 조직 외부 트래픽을 허용하려면 데이터 무단 반출 방지를 사용 중지해야 합니다.

인그레스 및 이그레스 방화벽 규칙은 프로젝트 네트워크 정책의 주요 구성요소이며 네트워크에 들어오고 나가는 트래픽 유형을 허용하거나 거부합니다. GDC에서 프로젝트 네임스페이스의 방화벽 규칙을 설정하려면 GDC 콘솔을 사용합니다.

보안 및 연결

기본적으로 프로젝트의 서비스와 워크로드는 해당 프로젝트 내에서 격리됩니다. 네트워크 정책을 구성하지 않으면 외부 서비스 및 워크로드와 통신할 수 없습니다.

GDC에서 프로젝트 네임스페이스의 네트워크 정책을 설정하려면 ProjectNetworkPolicy 리소스를 사용합니다. 이 리소스를 사용하면 프로젝트 내, 프로젝트 간, 외부 IP 주소로, 외부 IP 주소에서 통신을 허용하는 정책을 정의할 수 있습니다. 또한 프로젝트의 데이터 무단 반출 방지를 사용 중지하는 경우에만 프로젝트에서 워크로드를 전송할 수 있습니다.

GDC 프로젝트 네트워크 정책은 추가적입니다. 워크로드에 대한 결과 시행은 해당 워크로드에 적용된 모든 정책의 합집합에 대한 트래픽 흐름의 모든 일치입니다. 여러 정책이 있는 경우 각 정책의 규칙이 추가적으로 결합되어 규칙 중 하나 이상과 일치하는 경우 트래픽이 허용됩니다.

명시적 Deny 규칙은 Allow 규칙보다 절대적으로 우선 적용됩니다. 트래픽 흐름이 Deny 규칙과 일치하면 다른 규칙이나 기본 플랫폼 정책에서 허용하더라도 삭제됩니다.

또한 워크로드를 선택하는 단일 정책을 적용하면 지정하지 않은 모든 트래픽이 거부됩니다 (기본 거부 모드). 따라서 워크로드를 주체로 선택하는 정책을 하나 이상 적용하면 명시적으로 허용되고 명시적으로 거부되지 않은 트래픽만 허용됩니다.

프로젝트에 할당하는 잘 알려진 IP 주소를 사용하면 조직의 아웃바운드 트래픽에서 소스 네트워크 주소 변환 (NAT)이 수행됩니다.

기본 프로젝트 내 정책

프로젝트를 만들면 GDC가 프로젝트 네임스페이스에 base-policy-allow-intra-project-traffic라는 전역 프로젝트 네트워크 정책을 자동으로 만듭니다. 이 기본 정책은 다음을 수행합니다.

  • 프로젝트의 모든 사용자 워크로드를 대상으로 선택합니다.
  • 동일한 프로젝트의 모든 워크로드에서 모든 포트의 해당 워크로드로 들어오는 인바운드 트래픽을 허용합니다.
  • 다른 프로젝트 또는 조직 외부의 인바운드 트래픽을 허용하지 않습니다.

GDC는 프로젝트를 만들 때 기본 정책을 한 번만 만듭니다. 정책을 변경하거나 삭제하면 GDC에서 복원하지 않습니다. GDC는 정책을 프로젝트의 각 클러스터에 g-base-policy-allow-intra-project-traffic라는 네트워크 정책으로 전파합니다. 정책의 status.zones[].replicaStatus.propagatedName 필드에 이 이름이 표시됩니다.

기본 정책을 보려면 다음 명령어를 실행합니다.

kubectl --kubeconfig GLOBAL_API_SERVER get projectnetworkpolicy \
    base-policy-allow-intra-project-traffic -n PROJECT -o yaml

다음을 바꿉니다.

  • GLOBAL_API_SERVER: 전역 API 서버의 kubeconfig 경로입니다. 자세한 내용은 전역 및 영역 API 서버를 참조하세요.
  • PROJECT: 프로젝트의 이름

명령어가 NotFound 오류를 반환하면 기본 정책이 삭제된 것입니다. 다시 추가하려면 인그레스 프로젝트 내부 정책 만들기를 참조하세요.

기본 정책은 다음과 같이 사용자가 만든 정책과 결합됩니다.

  • 인그레스: 기본 정책의 존재 여부와 관계없이 워크로드는 기본적으로 다른 프로젝트 및 조직 외부로부터 격리됩니다. 만든 인그레스 정책은 다른 프로젝트 또는 외부 CIDR 블록과 같은 허용된 소스를 추가합니다. 기본 정책이 있는 동안에는 자체 인그레스 정책에서 프로젝트 내 규칙을 반복할 필요가 없습니다.
  • 워크로드 수준 프로젝트 내 인그레스: 기본 정책이 있는 동안 프로젝트의 모든 워크로드는 모든 포트에서 서로 연결할 수 있습니다. Allow 작업을 사용하는 워크로드 수준 프로젝트 내 인그레스 정책은 기본 정책을 삭제하거나 변경할 때까지 이 트래픽을 제한하지 않습니다. 중단을 방지하려면 기본 정책을 삭제하기 전에 워크로드 수준 정책을 적용하고 준비되었는지 확인하세요. 기본 정책을 유지하면서 특정 프로젝트 내부 트래픽을 차단하려면 프리뷰 기능인 명시적 거부 규칙을 사용하면 됩니다. 자세한 내용은 인그레스 워크로드 수준 프로젝트 내 정책 만들기를 참조하세요.
  • 이그레스: 프로젝트에는 기본적으로 이그레스 정책이 없습니다. 아웃바운드 트래픽은 조직 내에서 제한되지 않지만 데이터 무단 반출 보호(기본적으로 사용 설정됨)는 조직을 나가는 트래픽을 차단합니다. 이그레스 정책은 프로젝트에 대해 데이터 무단 반출 보호를 사용 중지한 후에만 적용됩니다. 데이터 무단 반출 방지가 사용 설정되어 있으면 영역 API 서버가 이그레스 정책을 거부하고 전역 이그레스 정책이 준비되지 않습니다.

전역 프로젝트 네트워크 정책

전역 프로젝트 네트워크 정책을 만들 수 있습니다. 전역 프로젝트 네트워크 정책의 범위는 GDC 유니버스 전반에 걸쳐 있습니다. 각 GDC 유니버스는 상호 연결되고 컨트롤 플레인을 공유하는 리전으로 구성된 여러 GDC 영역으로 구성될 수 있습니다. 예를 들어 각각 3개의 영역이 있는 2개의 리전으로 구성된 유니버스는 us-virginia1-a, us-virginia1-b, us-virginia1-c 및 eu-ams1-a, eu-ams1-b, eu-ams1-c와 같이 표시될 수 있습니다.

영역 프로젝트 네트워크 정책의 범위는 생성 시 지정된 영역으로 제한됩니다. 각 영역은 독립적인 재해 도메인입니다. 영역은 로컬 컨트롤 플레인을 사용하는 인프라, 서비스, API, 도구를 관리합니다.

GDC 유니버스의 전역 리소스에 대한 자세한 내용은 멀티 영역 개요를 참조하세요.

네트워킹 Kubernetes 리소스 모델 (KRM) API를 사용하여 전역 프로젝트 네트워크 정책을 만들 수 있습니다. API 버전 networking.global.gdc.goog을 사용하여 전역 리소스를 만듭니다.

KRM API 또는 GDC 콘솔을 사용하여 영역 프로젝트 네트워크 정책을 만들 수 있습니다. API 버전 networking.gdc.goog을 사용하여 영역 리소스를 만듭니다.

모두 허용 네트워크 정책

모두 허용 네트워크 정책을 만들어 프로젝트에 대한 광범위한 기본 액세스 규칙을 설정할 수 있습니다.

다음 유형의 모두 허용 네트워크 정책을 구성할 수 있습니다.

  • 모두 허용 네트워크 정책: 다른 프로젝트 및 외부 IP를 포함한 모든 소스와의 트래픽을 허용합니다.
  • Allow-all-external 네트워크 정책: 조직 외부의 IP 주소로 들어오고 나가는 트래픽을 허용합니다.
  • 모든 프로젝트 허용 네트워크 정책: 조직 내 모든 프로젝트를 오가는 트래픽을 허용합니다.

자세한 내용은 모든 트래픽 허용 네트워크 정책 만들기를 참조하세요.

명시적 거부 네트워크 정책

프로젝트 네트워크 정책에서 명시적 거부 규칙을 구성하여 지정된 프로젝트 또는 CIDR 블록 간의 연결을 제한할 수 있습니다.

거부 규칙의 주요 기능 및 제약조건은 다음과 같습니다.

  • 우선순위: 거부 규칙은 허용 규칙 (기본 플랫폼 정책 포함)보다 절대적으로 우선합니다.
  • 이그레스 안전 규칙: 중요 기반 시설 트래픽이 실수로 차단되는 것을 방지하기 위해 이그레스 거부 규칙은 시스템 및 비프로젝트 네임스페이스를 자동으로 제외합니다.
  • 피어 제한: 안전한 구성을 위해 인그레스 거부 규칙은 from 필드에 소스 피어를 명시적으로 지정해야 하며 이그레스 거부 규칙은 to 필드에 대상 피어를 명시적으로 지정해야 합니다. 피어 필드를 비워두면 모든 소스 또는 대상을 선택할 수 없습니다. 피어 필드를 비워두는 것은 허용되지 않으며 정책이 거부됩니다.
  • DEP를 사용한 이그레스 거부 없음: 프로젝트에 데이터 무단 반출 보호 (DEP)가 사용 설정된 경우 이그레스 거부 규칙을 구성할 수 없습니다.

자세한 내용은 명시적 거부 네트워크 정책 만들기를 참조하세요.

워크로드 수준 네트워크 정책

워크로드 수준 네트워크 정책을 만들어 프로젝트 내 개별 VM 및 포드에 대한 세분화된 액세스 제어를 정의할 수 있습니다. 이러한 정책은 워크로드의 방화벽 역할을 하며 라벨을 기반으로 트래픽 흐름을 제어하여 보안을 강화하고 애플리케이션을 격리합니다. 이러한 세분화 덕분에 프로젝트 내에서, 그리고 프로젝트 간에 서로 통신할 수 있는 워크로드를 더 엄격하게 제어할 수 있습니다.

워크로드 수준 네트워크 정책은 단일 영역에서 PNP를 적용하는 기능도 제공합니다.

자세한 내용은 워크로드 수준 프로젝트 내 정책 만들기 및 워크로드 수준 교차 프로젝트 정책 만들기를 참조하세요.

정책 구조 및 검증

ProjectNetworkPolicy 리소스에서 워크로드 라벨 선택기는 여러 수준 깊이로 중첩됩니다. 다음 인그레스 정책은 각 선택기의 올바른 위치를 보여줍니다.

apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT
  name: allow-frontend-to-backend
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
    userWorkloadSelector:
      labelSelector:
        workloads:
          matchLabels:
            app: backend
  ingress:
  - from:
    - projectSelector:
        projects:
          matchNames:
          - PEER_PROJECT
        workloadSelector:
          labelSelector:
            workloads:
              matchLabels:
                app: frontend
    ports:
    - protocol: TCP
      port: 8080

다음을 바꿉니다.

  • PROJECT: 프로젝트의 이름
  • PEER_PROJECT: 클라이언트 워크로드가 포함된 프로젝트의 이름입니다.

이 정책은 PEER_PROJECT에서 app: frontend 라벨이 지정된 워크로드가 TCP 포트 8080에서 프로젝트의 app: backend 라벨이 지정된 워크로드에 연결하도록 허용합니다.

정책을 작성할 때는 다음 규칙을 따르세요.

  • 항상 spec.policyType를 Ingress 또는 Egress로 명시적으로 설정합니다. Ingress 정책에는 from 피어가 있는 ingress 규칙만 포함될 수 있고 Egress 정책에는 to 피어가 있는 egress 규칙만 포함될 수 있습니다. policyType를 생략하면 정책이 기본적으로 Ingress로 설정되고 API 서버는 egress 규칙만 포함하는 정책을 거부합니다.
  • 라벨로 주체 워크로드를 선택하려면 spec.subject.userWorkloadSelector.labelSelector.workloads를 사용합니다. userWorkloadSelector를 생략하면 정책이 프로젝트의 모든 사용자 워크로드에 적용됩니다.
  • 라벨 선택기를 spec.subject 바로 아래에 배치하지 마세요. 기본적으로 kubectl는 strict decoding error: unknown field 메시지와 함께 spec.subject.matchLabels와 같은 필드를 거부합니다.
  • 라벨로 피어 워크로드를 선택하려면 from 또는 to 항목에서 projectSelector.workloadSelector.labelSelector.workloads를 사용합니다.
  • 주체 또는 피어 워크로드가 VM인 경우 라벨 키 앞에 user-label.gpc.gke.io/를 추가합니다. 예를 들어 user-label.gpc.gke.io/app: backend를 사용하세요.
  • 자동으로 생성된 기본 프로젝트 내 정책과 일부 기존 정책은 라벨 선택기를 직접 사용하는 지원 중단된 spec.subject.workloadSelector 필드를 사용합니다. 새 정책에서 userWorkloadSelector를 사용합니다.

정책을 적용하지 않고 전역 API 서버에 대해 정책을 검증하려면 서버 측 드라이 런을 실행합니다.

kubectl --kubeconfig GLOBAL_API_SERVER apply --dry-run=server \
    --validate=strict -f POLICY_FILE

드라이 런은 알 수 없는 필드 또는 Ingress 정책의 egress 규칙과 같은 실제 kubectl apply 명령어와 동일한 스키마 및 검증 오류를 보고하지만 정책을 만들거나 변경하지는 않습니다. 드라이 런에는 정책 적용과 동일한 권한이 필요합니다. 드라이 런이 성공했다고 해서 정책이 시행되는 것은 아닙니다. 정책을 적용한 후 준비되었는지 확인합니다.

전역 API 서버에서 허용하는 필드를 나열하려면 다음 명령어를 실행합니다.

kubectl --kubeconfig GLOBAL_API_SERVER explain projectnetworkpolicy.spec \
    --api-version=networking.global.gdc.goog/v1 --recursive

다음을 바꿉니다.

  • GLOBAL_API_SERVER: 전역 API 서버의 kubeconfig 경로입니다.
  • POLICY_FILE: ProjectNetworkPolicy 매니페스트의 경로입니다.

사전 정의된 역할 및 액세스 준비

프로젝트 네트워크 정책을 구성하려면 필요한 ID 및 액세스 역할이 있어야 합니다.

  • 프로젝트 네트워크 정책 관리자: 전역 프로젝트 네임스페이스의 모든 멀티 영역 PNP 리소스에 대한 쓰기 권한이 있습니다. IAM 조직 관리자에게 global-project-networkpolicy-admin 역할을 부여해 달라고 요청하세요. 자세한 내용은 사전 정의된 역할 설명을 참조하세요.

IP 블록을 사용하는 대상 클러스터 노드

ProjectNetworkPolicy 리소스의 ipBlocks 필드를 사용하여 개별 노드 IP 주소 또는 노드 CIDR 범위를 지정하고 포드와 특정 클러스터 노드 간의 트래픽을 제어할 수 있습니다 (예: 컨트롤 플레인 노드에서 커스텀 웹훅 포드로의 인그레스 허용 또는 컨트롤 플레인 노드로의 포드 이그레스 제한). 자세한 내용은 Standard 클러스터에 대한 프로젝트 내 정책 만들기를 참조하세요.

확장 고려사항

특정 노드를 타겟팅하도록 프로젝트 네트워크 정책을 구성하거나 광범위한 CIDR 범위를 사용하는 경우 정책 구성 선택이 확장성과 성능에 영향을 미칠 수 있습니다.

  • 0.0.0.0/0 동작: ipBlocks 규칙에서 0.0.0.0/0와 같은 광범위한 CIDR 범위를 사용하면 외부 IP 주소 외에도 클러스터의 모든 노드가 일치합니다.
  • 확장: 클러스터의 각 노드에 고유한 CIDR ID가 할당됩니다. 각 워크로드 엔드포인트 (VM 또는 포드)에는 네트워크 규칙을 저장하는 내부 정책 테이블이 있습니다. 대규모 클러스터에서는 0.0.0.0/0와 같은 광범위한 ipBlocks 규칙이 노드 수에 비례하여 정책 테이블 사용량을 증가시킵니다. 시스템이 모든 고유 노드 CIDR ID에 대한 항목을 만들어야 하기 때문입니다.
  • 경고: 노드 수가 많거나 복잡한 정책이 많은 경우 엔드포인트의 정책 테이블 한도에 도달할 수 있으므로 ipBlocks 규칙에서 지나치게 광범위한 CIDR 범위를 사용하지 마세요. 엔드포인트가 이 한도에 도달하면 새 네트워크 정책이 적용되지 않아 네트워크 연결이 중단되거나 해당 워크로드에 대한 정책 시행이 방해받을 수 있습니다.

다음 단계