클러스터 보안 강화

이 문서에서는 Google Kubernetes Engine (GKE) 환경의 보안을 개선하기 위한 권장사항을 제공합니다. 정책과 절차를 정의, 관리, 구현하는 보안 전문가는 이러한 권장사항을 사용하여 조직의 데이터를 보호할 수 있습니다.

다음 사항을 이미 알고 있어야 합니다.

새 GKE 클러스터는 기본적으로 이 문서의 많은 권장사항을 구현합니다. Autopilot 모드 클러스터는 Standard 모드 클러스터보다 기본 보안 태세가 더 엄격합니다.

조직 전체에 이 문서의 권장사항을 구현하고 적용하려면 다음 서비스를 고려하세요.

  • Security Command Center: 클러스터가 이러한 권장사항을 많이 구현하는지 자동으로 확인하고 기타 일반적인 구성 오류를 확인합니다.
  • 조직 정책 서비스: 조직, 폴더 또는 프로젝트의 GKE 리소스에 특정 권장사항을 적용합니다. 이 문서의 특정 섹션에는 이러한 권장사항에 관리 제약 조건을 적용할 수 있는 Google Cloud 콘솔 링크가 있습니다.

Google Cloud 환경 디자인

다음 섹션에서는 Google Cloud에서 리소스를 계획하고 설계할 때 고려해야 하는 보안 조치를 설명합니다. 클라우드 설계자는 아키텍처를 계획하고 정의할 때 Google Cloud 이 권장사항을 사용해야 합니다.

권장사항

Google Cloud 리소스 구조 계획

권장: Google의 권장사항에 기반한 엔터프라이즈 환경의 완전한 기반인 엔터프라이즈 기반 청사진을 구현합니다.

Google Cloud 조직, 폴더, 프로젝트의 아키텍처는 보안 상황에 영향을 미칩니다. 서비스 전반에서 거버넌스 및 보안 제어를 확장할 수 있는 방식으로 이러한 기본 리소스를 설계합니다.

멀티 테넌트 환경 계획

권장: 멀티 테넌트 엔터프라이즈 플랫폼을 위해 Google Cloud 및 GKE 권장사항을 구현합니다.

많은 GKE 고객이 별도의 엔지니어링 워크플로와 책임을 가진 분산된 팀을 관리합니다. 이러한 멀티 테넌트 환경에는 모든 개발자가 사용할 수 있는 공유 인프라가 있어야 하며, 역할과 책임에 따라 구성요소에 대한 액세스를 제한해야 합니다. 엔터프라이즈 애플리케이션 청사진은 엔터프라이즈 기반 청사진을 기반으로 멀티 테넌트 환경에 내부 개발자 플랫폼을 배포할 수 있도록 지원합니다.

자세한 내용은 다음 문서를 참조하세요.

태그를 사용하여 Google Cloud 리소스를 그룹화합니다.

권장: 태그를 사용하여 조건부 정책 시행 및 팀 간 책임성 향상을 위해 GKE 리소스를 정리합니다.

태그는 조직, 폴더, 프로젝트의 리소스에 연결하여Google Cloud 리소스 계층 구조 전반에서 비즈니스 측정기준을 식별할 수 있는 메타데이터입니다. GKE 클러스터 및 노드 풀에 태그를 연결한 다음 이러한 태그를 사용하여 조직 정책, IAM 정책 또는 방화벽 정책을 조건부로 적용할 수 있습니다.

자세한 내용은 다음 문서를 참조하세요.

VPC 네트워크 계획

권장: VPC 네트워크 설계에 Google Cloud 및 GKE 권장사항을 구현합니다.

VPC 네트워크 설계와 사용하는 기능은 네트워크 보안에 영향을 미칩니다. Google Cloud리소스 계층 구조와 보안 목표에 따라 네트워크를 계획합니다. 자세한 내용은 다음 문서를 참조하세요.

사고 대응 계획 설계

권장: 보안 및 안정성 목표를 충족하는 사고 대응 계획을 수립하고 유지관리합니다.

가능한 모든 보안 제어를 구현하더라도 보안 사고가 발생할 수 있습니다. 사고 대응 계획은 보안 제어의 잠재적 격차를 식별하고, 다양한 유형의 사고에 신속하고 효과적으로 대응하며, 서비스 중단 시 다운타임을 줄이는 데 도움이 됩니다. 자세한 내용은 다음 문서를 참조하세요.

Google Cloud 네트워크 보안

다음 섹션에서는 VPC 네트워크에 대한 보안 권장사항을 제공합니다. 네트워크 설계자와 네트워크 관리자는 이러한 권장사항을 적용하여 네트워크 수준에서 공격 표면을 줄이고 의도치 않은 네트워크 액세스의 영향을 제한해야 합니다.

권장사항

최소 권한 방화벽 규칙 사용

권장: 방화벽 규칙을 만들 때 최소 권한의 원칙을 사용하여 필요한 용도로만 액세스 권한을 제공합니다. 가능한 경우 방화벽 규칙이 GKE 기본 방화벽 규칙과 충돌하거나 이를 재정의하지 않도록 합니다.

GKE는 시스템 기능을 사용 설정하고 우수한 보안 관행을 적용하기 위해 기본 VPC 방화벽 규칙을 만듭니다. 기본 방화벽 규칙보다 우선순위가 더 높은 허용 방화벽 규칙 (예: 디버깅을 위해 모든 인그레스 트래픽을 허용하는 방화벽 규칙)을 만들면 클러스터가 의도치 않은 액세스 위험에 노출될 수 있습니다.

프로젝트 간 트래픽에 공유 VPC 사용

권장: 공유 VPC를 사용하여 여러 프로젝트의 리소스가 내부 IP 주소를 사용하여 서로 통신하도록 합니다.

조직의 서로 다른 프로젝트에 있는 리소스가 서로 통신해야 할 수 있습니다. 예를 들어 한 프로젝트의 GKE 클러스터에 있는 프런트엔드 서비스가 다른 프로젝트에 있는 백엔드 Compute Engine 인스턴스와 통신해야 할 수 있습니다.

자세한 내용은 다음 문서를 참조하세요.

별도의 네트워크를 사용하여 환경 격리

권장: 스테이징, 테스트, 프로덕션 환경에 별도의 공유 VPC 네트워크를 사용합니다.

개발 환경을 서로 격리하여 무단 액세스 또는 중단 버그의 영향과 위험을 줄이세요. 자세한 내용은 여러 호스트 프로젝트를 참고하세요.

변경 불가능한 보안 설정

다음 섹션에서는 클러스터 또는 노드 풀을 만들 때만 구성할 수 있는 보안 권장사항을 제공합니다. 기존 클러스터 또는 노드 풀을 업데이트하여 이러한 설정을 변경할 수 없습니다. 플랫폼 관리자는 이러한 권장사항을 새 클러스터와 노드 풀에 적용해야 합니다.

최소 권한 IAM 노드 서비스 계정 사용

권장: 기본 Compute Engine 서비스 계정을 사용하는 대신 GKE 클러스터 및 노드 풀에 커스텀 IAM 서비스 계정을 사용합니다.

GKE는 노드에 연결된 IAM 서비스 계정을 사용하여 로깅 및 모니터링과 같은 시스템 태스크를 실행합니다. 적어도 이러한 노드 서비스 계정에는 프로젝트에 대한 Kubernetes Engine 기본 노드 서비스 계정(roles/container.defaultNodeServiceAccount) 역할이 있어야 합니다. 기본적으로 GKE는 프로젝트에 자동으로 생성되는 Compute Engine 기본 서비스 계정을 노드 서비스 계정으로 사용합니다.

프로젝트 또는 조직의 다른 기능에 Compute Engine 기본 서비스 계정을 사용하는 경우 서비스 계정에 GKE에 필요한 것보다 많은 권한이 있을 수 있으며, 이로 인해 보안 위험이 발생할 수 있습니다.

노드에 연결된 서비스 계정은 로깅 및 모니터링과 같은 태스크를 실행하는 시스템 워크로드에서만 사용해야 합니다. 자체 워크로드의 경우 GKE용 워크로드 아이덴티티 제휴를 사용하여 ID를 프로비저닝합니다.

조직에서 이 권장사항을 적용하려면 constraints/container.managed.disallowDefaultComputeServiceAccount 관리 조직 정책 제약조건을 사용하세요. Google Cloud 콘솔에서 이 관리 제약 조건을 검토하려면 정책 세부정보 페이지로 이동하세요.

정책 세부정보로 이동

Container-Optimized OS 노드 이미지 사용

권장: Ubuntu 또는 Windows를 사용해야 하는 특정 요구사항이 없는 경우 노드에 Container-Optimized OS 노드 이미지를 사용하세요.

Container-Optimized OS는 컨테이너 실행을 위해 특별히 빌드, 최적화, 강화되었습니다. Container-Optimized OS는 Autopilot 모드에서 지원되는 유일한 노드 이미지이며 표준 모드의 기본 노드 이미지입니다.

자세한 내용은 다음 문서를 참조하세요.

노드 보안 구성

다음 섹션에서는 GKE 노드 구성에 대한 보안 권장사항을 제공합니다. 플랫폼 관리자와 보안 엔지니어는 이러한 권장사항을 적용하여 GKE 노드의 무결성을 개선해야 합니다.

권장사항

Shielded GKE Node 사용

권장: 모든 클러스터와 노드 풀에서 보안 GKE 노드, 보안 부트, 무결성 모니터링을 사용 설정합니다.

보안 GKE 노드는 노드의 보안을 개선하는 검증 가능한 ID와 무결성 검사를 제공합니다. 보안 GKE 노드와 노드 무결성 모니터링, 보안 부팅과 같은 기능은 Autopilot 클러스터에서 항상 사용 설정됩니다. Standard 클러스터에서 다음을 실행합니다.

  • 클러스터에서 보안 GKE 노드를 사용 중지하지 마세요.
  • 모든 노드 풀에서 보안 부트를 사용 설정합니다.
  • 노드 풀에서 무결성 모니터링을 사용 중지하지 마세요.

이러한 기능을 사용 설정하는 방법에 대한 자세한 내용은 보안 GKE 노드 사용을 참고하세요.

조직에서 이 권장사항을 적용하려면 constraints/container.managed.enableShieldedNodes 관리 조직 정책 제약조건을 사용하세요. Google Cloud 콘솔에서 이 관리 제약 조건을 검토하려면 정책 세부정보 페이지로 이동하세요.

정책 세부정보로 이동

안전하지 않은 kubelet 읽기 전용 포트 사용 중지

권장: kubelet 읽기 전용 포트를 사용 중지하고 10255 포트를 사용하는 모든 워크로드를 대신 더 안전한 10250 포트를 사용하도록 전환합니다.

노드에서 실행되는 kubelet 프로세스는 안전하지 않은 포트 10255를 사용하여 읽기 전용 API를 제공합니다. Kubernetes는 이 포트에서 인증 또는 승인 검사를 수행하지 않습니다. kubelet는 보다 안전하고 인증된 포트 10250에서 동일한 엔드포인트를 제공합니다.

자세한 내용은 GKE 클러스터에서 kubelet 읽기 전용 포트 사용 중지를 참고하세요.

조직에서 이 권장사항을 적용하려면 constraints/container.managed.disableInsecureKubeletReadOnlyPort 관리 조직 정책 제약조건을 사용하세요. Google Cloud 콘솔에서 이 관리 제약 조건을 검토하려면 정책 세부정보 페이지로 이동하세요.

정책 세부정보로 이동

액세스 제어

다음 섹션에서는 클러스터에서 승인되지 않은 액세스를 제한하는 권장사항을 설명합니다. 보안 엔지니어와 ID 및 계정 관리자는 이러한 권장사항을 적용하여 공격 표면을 줄이고 무단 액세스의 영향을 제한해야 합니다.

권장사항

클러스터 API 검색에 대한 액세스 제한

권장: 클러스터 API 검색 엔드포인트에 대한 의도치 않은 액세스를 방지하기 위해 인터넷에서 컨트롤 플레인 및 노드에 대한 액세스를 제한합니다.

기본적으로 Kubernetes는 방임적인 기본 API 검색 역할 집합으로 클러스터를 만듭니다. 이러한 기본 역할은 system:authenticated와 같은 다양한 기본 그룹에 클러스터의 API 정보에 대한 광범위한 액세스 권한을 부여합니다. 이러한 기본 역할은 GKE 클러스터에 의미 있는 수준의 보안을 제공하지 않습니다. 예를 들어 CustomResources와 같은 API에 관한 정보를 읽을 수 있는 system:authenticated 그룹은 인증된 모든 사용자 (Google 계정이 있는 사용자 포함)에게 할당됩니다.

클러스터 검색 API에 대한 액세스를 제한하려면 다음 단계를 따르세요.

  • 컨트롤 플레인에 대한 액세스 제한: 컨트롤 플레인 액세스에는 DNS 기반 엔드포인트만 사용합니다. IP 기반 엔드포인트를 사용하는 경우 승인된 네트워크를 구성하여 알려진 주소 범위 집합에 대한 액세스를 제한합니다.
  • 비공개 노드 구성: 네트워크 외부의 클라이언트가 노드에 액세스할 수 없도록 노드의 외부 IP 주소를 사용 중지합니다.

자세한 내용은 네트워크 격리 정보를 참고하세요.

이러한 네트워크 격리 기능을 사용 설정하지 않으면 모든 API 검색 정보 (특히 CustomResources의 스키마, APIService 정의, 확장 API 서버에서 호스팅하는 검색 정보)를 공개로 취급해야 합니다.

팀과 환경을 별도의 네임스페이스 또는 클러스터에 배치

각 팀과 환경별로 별도의 네임스페이스 또는 클러스터를 생성하여 팀에 Kubernetes에 대한 최소 권한 액세스를 부여하세요. 각 네임스페이스 또는 클러스터에 책임성 및 지불 거절을 위한 비용 센터와 라벨을 할당합니다.

네임스페이스와 함께 IAM 및 RBAC 권한을 사용하여 Google Cloud 콘솔에서 클러스터 리소스와의 사용자 상호작용을 제한할 수 있습니다. 자세한 내용은 액세스 권한을 사용 설정하고 네임스페이스별 클러스터 리소스 보기를 참조하세요.

액세스 정책에 최소 권한 원칙 사용

권장: 특히 프로덕션 환경에서 개발자에게 네임스페이스의 애플리케이션을 배포하고 관리하는 데 필요한 액세스 권한만 부여합니다. 액세스 제어 정책을 설계할 때 사용자가 클러스터에서 해야 하는 작업을 매핑하고 이러한 작업을 수행할 수 있는 권한만 부여하세요.

GKE에서는 IAM 및 Kubernetes 역할 기반 액세스 제어 (RBAC)를 사용하여 리소스에 대한 권한을 부여할 수 있습니다. 이러한 액세스 제어 메커니즘은 함께 작동합니다. 액세스 관리의 복잡성을 줄이려면 다음 단계를 따르세요.

  • 프로젝트 또는 Google Cloud 리소스에 대한 액세스 권한을 부여하려면 IAM 역할을 사용하세요.

  • 네임스페이스와 같은 클러스터의 Kubernetes 리소스에 대한 액세스 권한을 부여하려면 RBAC를 사용하세요.

IAM 및 RBAC 정책 계획 및 설계에 대한 자세한 내용은 다음 문서를 참고하세요.

GKE용 워크로드 아이덴티티 제휴를 사용하여 Google Cloud API에 액세스

권장: GKE 워크로드에서 Google Cloud 리소스에 액세스하려면 GKE용 워크로드 아이덴티티 제휴를 사용하세요.

GKE용 워크로드 아이덴티티 제휴는Google Cloud API에 인증하는 데 권장되는 방법입니다. 특정 Kubernetes ServiceAccount 또는 포드와 같은 클러스터의 주 구성원에게 다양한 리소스에 대한 IAM 역할을 부여할 수 있습니다. GKE용 워크로드 아이덴티티 제휴는 노드의 민감한 메타데이터를 보호하고 정적 토큰 파일과 같은 대안보다 더 안전한 인증 워크플로를 제공합니다.

GKE용 워크로드 아이덴티티 제휴는 항상 Autopilot 클러스터에서 사용 설정됩니다. Standard 클러스터에서는 모든 클러스터와 노드 풀에 GKE용 워크로드 아이덴티티 제휴를 사용 설정합니다. 또한 다음 권장사항을 따르세요.

  • 애플리케이션 코드에서 Google Cloud 클라이언트 라이브러리를 사용하는 경우 Google Cloud 사용자 인증 정보를 워크로드에 배포하지 마세요. 클라이언트 라이브러리를 사용하는 코드는 GKE용 워크로드 아이덴티티 제휴의 사용자 인증 정보를 자동으로 가져옵니다.
  • 고유한 아이덴티티가 필요한 모든 워크로드에 대해 별도의 네임스페이스와 ServiceAccount를 사용합니다. 특정 ServiceAccount에 IAM 권한을 부여합니다.

자세한 내용은 GKE 워크로드에서 Google Cloud API에 인증을 참고하세요.

조직에서 이 권장사항을 적용하려면 constraints/container.managed.enableWorkloadIdentityFederation 관리 조직 정책 제약조건을 사용하세요. Google Cloud 콘솔에서 이 관리 제약 조건을 검토하려면 정책 세부정보 페이지로 이동하세요.

정책 세부정보로 이동

그룹을 사용하여 액세스 관리

권장: 액세스 정책에서 개인 대신 사용자 그룹에 권한을 부여합니다.

그룹에서 사용자를 관리하면 ID 관리 시스템과 ID 관리자가 다양한 그룹의 사용자 멤버십을 수정하여 ID를 중앙에서 제어할 수 있습니다. 이러한 유형의 관리를 사용하면 특정 사용자의 권한을 업데이트해야 할 때마다 RBAC 또는 IAM 정책을 업데이트할 필요가 없습니다.

IAM 또는 RBAC 정책에서 Google 그룹스를 지정할 수 있습니다. 자세한 내용은 다음 문서를 참조하세요.

조직에서 이 권장사항을 적용하려면 constraints/container.managed.enableGoogleGroupsRBAC 관리 조직 정책 제약조건을 사용하세요. Google Cloud 콘솔에서 이 관리 제약 조건을 검토하려면 정책 세부정보 페이지로 이동하세요.

정책 세부정보로 이동

클러스터 엔드포인트에 대한 익명 액세스 제한

권장: 모든 Autopilot 및 Standard 클러스터에서 상태 점검 엔드포인트를 제외한 모든 클러스터 엔드포인트에 대한 익명 요청을 방지합니다.

기본적으로 Kubernetes는 클러스터 엔드포인트에 대한 익명 요청에 system:anonymous 사용자와 system:unauthenticated 그룹을 할당합니다. RBAC 정책에서 이 사용자 또는 그룹에 추가 권한을 부여하는 경우 익명 사용자가 서비스 또는 클러스터 자체의 보안을 손상시킬 수 있습니다.

GKE 버전 1.32.2-gke.1234000 이상에서는 익명 요청이 도달할 수 있는 엔드포인트 집합을 /healthz, /livez, /readyz Kubernetes API 서버 상태 점검 엔드포인트로만 제한할 수 있습니다. 클러스터가 올바르게 작동하는지 확인하려면 이러한 상태 점검 엔드포인트에 대한 익명 액세스가 필요합니다.

클러스터 엔드포인트에 대한 익명 액세스를 제한하려면 gcloud CLI 또는 GKE API를 사용하여 Standard 및 Autopilot 클러스터를 만들거나 업데이트할 때 --anonymous-authentication-config 플래그에 LIMITED를 지정합니다. GKE는 인증 중에 상태 점검 엔드포인트가 아닌 클러스터 엔드포인트에 대한 익명 요청을 거부합니다. RBAC 정책에서 익명 사용자 및 그룹에 대한 액세스 권한을 부여하더라도 익명 요청은 엔드포인트에 도달하지 않습니다. 거부된 요청은 HTTP 상태 401를 반환합니다.

조직 정책을 사용하여 조직, 폴더 또는 프로젝트에서 이 권장사항을 적용하려면 resource.anonymousAuthenticationConfig.mode 조건으로 맞춤 제약 조건을 만드세요. 자세한 내용과 제약 조건 예시는 커스텀 조직 정책을 사용하여 GKE 리소스에 대한 작업 제한을 참고하세요.

이 기능으로만 클러스터를 보호하지 마세요. 다음과 같은 추가 보안 조치를 구현합니다.

GKE 네트워크 보안

다음 섹션에서는 클러스터의 네트워크 보안을 개선하기 위한 권장사항을 제공합니다. 네트워크 관리자와 보안 엔지니어는 의도하지 않은 외부 또는 내부 액세스로부터 워크로드와 인프라를 보호하기 위해 이러한 권장사항을 적용해야 합니다.

권장사항

컨트롤 플레인에 대한 액세스 제한

권장: 컨트롤 플레인 액세스에 DNS 기반 엔드포인트를 사용 설정하고 모든 IP 기반 컨트롤 플레인 엔드포인트를 사용 중지합니다.

기본적으로 인터넷의 클라이언트와 같은 외부 엔티티가 컨트롤 플레인에 도달할 수 있습니다. 네트워크 격리를 구성하여 컨트롤 플레인에 액세스할 수 있는 사용자를 제한할 수 있습니다.

컨트롤 플레인을 격리하려면 다음 중 하나를 수행하세요.

  • DNS 기반 엔드포인트만 사용 (권장): 컨트롤 플레인에 DNS 기반 엔드포인트를 사용 설정하고 내부 및 외부 IP 기반 엔드포인트를 사용 중지합니다. 모든 컨트롤 플레인 액세스는 DNS 기반 엔드포인트를 사용해야 합니다. VPC 서비스 제어를 사용하여 DNS 기반 엔드포인트에 액세스할 수 있는 사용자를 제어할 수 있습니다.

    조직에서 이 권장사항을 적용하려면 constraints/container.managed.enableControlPlaneDNSOnlyAccess 관리 조직 정책 제약조건을 사용하세요. Google Cloud 콘솔에서 이 관리 제약 조건을 검토하려면 정책 세부정보 페이지로 이동하세요.

    정책 세부정보로 이동

  • 외부 IP 기반 엔드포인트 사용 중지: 컨트롤 플레인의 외부 IP 주소를 삭제합니다. VPC 네트워크 외부에 있는 클라이언트는 외부 IP 주소를 사용하여 컨트롤 플레인에 액세스할 수 없습니다.

    Cloud Interconnect 및 Cloud VPN과 같은 기술을 사용하여 회사 네트워크를 VPC 네트워크에 연결하는 경우 이 옵션이 적합합니다.

  • 외부 IP 기반 엔드포인트와 함께 승인된 네트워크 사용: 외부 IP 기반 엔드포인트에 대한 액세스를 신뢰할 수 있는 소스 IP 주소 범위로만 제한합니다.

    이 옵션은 기존 VPN 인프라가 없거나 공개 인터넷을 사용하여 클러스터에 액세스하는 원격 사용자나 지사가 있는 경우에 적합합니다.

대부분의 시나리오에서는 컨트롤 플레인 액세스에 DNS 기반 엔드포인트만 사용합니다. IP 기반 엔드포인트를 사용 설정해야 하는 경우 승인된 네트워크를 사용하여 다음 항목에 대한 컨트롤 플레인 액세스를 제한하세요.

  • 지정한 IP 주소 범위
  • 클러스터와 동일한 VPC 네트워크에 있는 GKE 노드
  • 클러스터 관리를 위해 Google에서 예약한 IP 주소

인터넷에서 노드 격리

기본적으로 모든 GKE 노드에는 인터넷의 클라이언트가 연결할 수 있는 외부 IP 주소가 있습니다. 이 외부 IP 주소를 삭제하려면 비공개 노드를 사용 설정하세요.

조직에서 이 권장사항을 적용하려면 constraints/container.managed.enablePrivateNodes 관리 조직 정책 제약조건을 사용하세요. Google Cloud 콘솔에서 이 관리 제약 조건을 검토하려면 정책 세부정보 페이지로 이동하세요.

정책 세부정보로 이동

포드 간 네트워크 트래픽 제한

권장사항: NetworkPolicy, 서비스 메시 또는 둘 다를 사용하여 Pod 간 네트워크 트래픽을 제어합니다.

기본적으로 클러스터의 모든 포드는 다른 모든 포드와 통신할 수 있습니다. 서비스 간 네트워크 액세스를 제한하면 클러스터 내에서 공격자의 측면 이동이 더 어려워집니다. 또한 실수로 인한 서비스 거부나 고의적인 서비스 거부로부터 서비스를 보호할 수 있습니다. 요구사항에 따라 다음 방법 중 하나 또는 둘 모두를 사용하여 Pod 간 트래픽을 제한합니다.

  • 부하 분산, 서비스 승인, 제한, 할당량, 측정항목과 같은 기능을 사용하려면 Cloud Service Mesh를 사용하세요. 서비스 메시는 서로 복잡하게 상호작용하는 개별 서비스가 많은 경우에 유용합니다.

  • 기본 트래픽 흐름 제어 메커니즘이 필요한 경우 Kubernetes NetworkPolicies 사용 NetworkPolicy가 예상대로 작동하는지 확인하려면 네트워크 정책 로깅을 구성하세요.

    조직에서 이 권장사항을 적용하려면 constraints/container.managed.enableNetworkPolicy 관리 조직 정책 제약조건을 사용하세요. Google Cloud 콘솔에서 이 관리 제약 조건을 검토하려면 정책 세부정보 페이지로 이동하세요.

    정책 세부정보로 이동

Sensitive Data Protection

다음 섹션에서는 데이터를 암호화하고 사용자 인증 정보와 같은 민감한 정보를 보호하는 방법을 권장합니다. 보안 엔지니어와 플랫폼 관리자는 이러한 권장사항을 적용하여 중요한 데이터에 의도치 않게 액세스할 위험을 줄여야 합니다.

권장사항

사용 중인 워크로드 데이터 암호화

컨피덴셜 GKE 노드를 사용하여 워크로드에서 사용 중인 데이터를 하드웨어 기반 메모리 암호화로 보호합니다. 요구사항에 따라 컨피덴셜 컴퓨팅 기술을 선택할 수 있습니다. 자세한 내용은 Confidential GKE Node로 사용 중인 워크로드 데이터 암호화를 참고하세요.

클러스터 외부에 보안 비밀 저장

권장사항: Secret Manager와 같은 외부 보안 비밀 관리자를 사용하여 클러스터 외부에 API 키와 같은 민감한 정보를 저장합니다.

Kubernetes에서는 클러스터의 보안 비밀에 민감한 정보를 저장할 수 있습니다. 보안 비밀을 사용하여 애플리케이션 코드에 해당 데이터를 포함하지 않고도 애플리케이션에 기밀 데이터를 제공할 수 있습니다. 하지만 클러스터에 이 데이터를 저장하면 다음과 같은 위험이 있습니다.

  • 네임스페이스에서 포드를 만들 수 있는 사용자는 해당 네임스페이스의 모든 보안 비밀 데이터를 읽을 수 있습니다.
  • 모든 Kubernetes API 객체를 읽을 수 있는 RBAC 또는 IAM 액세스 권한이 있는 사용자는 보안 비밀을 읽을 수 있습니다.

이러한 위험 때문에 다른 방법으로 워크로드에 해당 데이터를 제공할 수 없는 경우에만 클러스터에서 보안 비밀을 만드세요. 민감한 정보를 저장하고 액세스하는 데는 다음 방법을 선호도 순으로 사용하는 것이 좋습니다.

  • Secret Manager 클라이언트 라이브러리: GKE용 워크로드 아이덴티티 제휴와 함께 Secret Manager API를 사용하여 애플리케이션 코드에서 보안 비밀에 프로그래매틱 방식으로 액세스합니다. 자세한 내용은 클라이언트 라이브러리를 사용하여 GKE 클러스터 외부에 저장된 보안 비밀에 액세스를 참조하세요.
  • Secret Manager 데이터를 마운트된 볼륨으로 제공: GKE용 Secret Manager 부가기능을 사용하여 민감한 정보를 마운트된 볼륨으로 포드에 제공합니다. 이 방법은 Secret Manager 클라이언트 라이브러리를 사용하도록 애플리케이션 코드를 수정할 수 없는 경우에 유용합니다. 자세한 내용은 Google Kubernetes Engine에 Secret Manager 부가기능 사용을 참조하세요.

  • 서드 파티 보안 비밀 관리 도구: HashiCorp Vault와 같은 서드 파티 도구는 Kubernetes 워크로드에 보안 비밀 관리 기능을 제공합니다. 이러한 도구는 Secret Manager보다 초기 구성이 더 많이 필요하지만 클러스터에서 보안 비밀을 만드는 것보다 더 안전한 옵션입니다. 보안 비밀 관리를 위한 서드 파티 도구를 구성하려면 해당 제공업체의 문서를 참조하세요. 또한 다음 권장사항을 고려하세요.

    • 서드 파티 도구가 클러스터에서 실행되는 경우 워크로드를 실행하는 클러스터와 다른 클러스터를 사용합니다.
    • Cloud Storage 또는 Spanner를 사용하여 도구의 데이터를 저장합니다.
    • 내부 패스 스루 네트워크 부하 분산기를 사용하여 VPC 네트워크에서 실행되는 포드에 서드 파티 비밀 관리 도구를 노출합니다.

  • Kubernetes 보안 비밀 사용(권장하지 않음): 위의 옵션 중 사용 사례에 맞는 옵션이 없다면 Kubernetes 보안 비밀로 데이터를 저장할 수 있습니다. Google Cloud는 기본적으로 스토리지 레이어에서 데이터를 암호화합니다. 이러한 스토리지 레이어 기본 암호화에는 etcd 또는 Spanner를 기반으로 하는 클러스터의 상태를 저장하는 데이터베이스가 포함됩니다. 또한 관리하는 키를 사용하여 애플리케이션 레이어에서 이러한 보안 비밀을 암호화할 수 있습니다. 자세한 내용은 애플리케이션 계층의 보안 비밀 암호화를 참조하세요.

워크로드 보안

다음 섹션에서는 워크로드 문제에 대비하여 클러스터의 보안을 개선하기 위한 권장사항을 제공합니다. 보안 엔지니어와 플랫폼 관리자는 이러한 권장사항을 적용하여 워크로드로부터 GKE 인프라를 보호해야 합니다.

권장사항

GKE Sandbox를 사용하여 워크로드 격리

권장: GKE Sandbox를 사용하여 악성 코드가 클러스터 노드의 호스트 커널에 영향을 미치지 않도록 합니다.

샌드박스 환경에서 컨테이너를 실행하면 대부분의 컨테이너 이스케이프 공격(로컬 권한 에스컬레이션 공격이라고도 함)을 완화할 수 있습니다. GKE 보안 게시판에 설명된 대로 이 유형의 공격은 공격자가 컨테이너의 호스트 VM에 액세스할 수 있도록 허용합니다. 공격자는 이 호스트 액세스를 사용하여 동일한 VM의 다른 컨테이너에 액세스할 수 있습니다. GKE Sandbox는 이러한 공격의 영향을 제한하는 데 도움이 될 수 있습니다.

다음과 같은 시나리오에서 GKE Sandbox를 사용하세요.

  • 신뢰할 수 없는 코드를 실행하는 워크로드가 있습니다.
  • 공격자가 워크로드의 컨테이너에 침투하여 발생하는 영향을 제한해야 합니다.

자세한 내용은 GKE Sandbox로 워크로드 격리 강화를 참고하세요.

워크로드가 자체 수정하는 기능을 제한

권장: 승인 컨트롤러를 사용하여 워크로드가 자체 수정되지 않도록 하거나 ServiceAccounts와 같은 위험한 워크로드 속성이 수정되지 않도록 합니다.

특정 Kubernetes 워크로드, 특히 시스템 워크로드에는 자체 수정 권한이 있습니다. 예를 들어 일부 워크로드는 수직적으로 자동 확장됩니다. 편리한 기능이지만 자체 수정으로 인해 노드를 이미 손상시킨 공격자가 클러스터에서 추가로 에스컬레이션할 수 있습니다. 예를 들어 공격자는 네임스페이스에 있는 워크로드가 동일한 네임스페이스에서 권한이 높은 ServiceAccount로 실행되도록 변경할 수 있습니다.

필요하지 않은 경우 포드에 자체 수정 권한을 부여하지 마세요. 일부 포드를 자체 수정해야 하는 경우 정책 컨트롤러를 사용하여 워크로드가 변경할 수 있는 항목을 제한합니다. 예를 들어 NoUpdateServiceAccount 제약 조건 템플릿을 사용하여 포드가 ServiceAccount를 변경하지 못하도록 할 수 있습니다. 정책을 만들 때는 다음 예와 같이 클러스터 관리 구성요소를 제약 조건에서 제외하세요.

parameters:
  allowedGroups:
  - system:masters
  allowedUsers:
  - system:addon-manager

정책 기반 시행

다음 섹션에서는 정책을 사용하여 여러 리소스에 보안 제약 조건을 적용하는 방법을 권장합니다. ID 및 계정 관리자와 보안 엔지니어는 이러한 권장사항을 적용하여 클러스터와 워크로드가 조직의 보안 요구사항을 준수하도록 해야 합니다.

권장사항

Google Cloud 리소스 계층 구조 전반에 정책 적용

권장: 조직, 폴더 또는 프로젝트에서 보안 관행을 적용하려면 조직 정책 서비스를 사용하세요.

조직 정책을 사용하면 중앙에서 제약 조건을 정의하고 리소스 계층 구조의 다양한 수준에서 이를 적용할 수 있습니다. 다양한 Google Cloud 제품에서 해당 제품에 권장사항을 적용할 수 있는 관리형 제약 조건을 게시합니다. 예를 들어 GKE는 이 문서에 설명된 많은 권장사항에 따라 관리형 제약 조건을 게시합니다.

조직 정책을 사용 설정하는 방법에 대한 자세한 내용은 조직 정책 만들기 및 관리를 참고하세요.

워크로드 허용 시 정책 적용

권장: 정책 컨트롤러 또는 PodSecurity 허용 컨트롤러와 같은 허용 컨트롤러를 사용하여 수신 API 요청을 검토하고 이러한 요청에 정책을 적용합니다.

허용 컨트롤러는 인증되고 승인된 Kubernetes API 요청을 가로채 API에 리소스가 유지되도록 허용하기 전에 검증 또는 변형 작업을 실행합니다.

GKE 클러스터에서 허용 제어를 위해 다음 방법을 사용할 수 있습니다.

클러스터 관리

다음 섹션에서는 업그레이드, 모니터링, 로그 구성 등 시간이 지남에 따라 클러스터를 관리하기 위한 권장사항을 제공합니다. 보안 엔지니어, 플랫폼 관리자, SRE는 이러한 권장사항을 사용하여 GKE 플랫폼의 보안 상황을 유지해야 합니다.

권장사항

GKE 인프라를 정기적으로 업그레이드

권장: 새로운 보안 기능에 액세스하고 보안 패치를 적용하려면 GKE 버전을 최신 상태로 유지하세요. 출시 채널, 가속화된 패치 자동 업그레이드, 자동 노드 업그레이드를 사용합니다.

Kubernetes와 GKE는 보안 개선사항과 취약점 수정사항이 포함된 새 패치 버전을 자주 출시합니다. 모든 클러스터에서 GKE는 컨트롤 플레인을 자동으로 업그레이드하여 더 안정적인 마이너 버전과 패치 버전으로 업그레이드합니다.

GKE 클러스터가 최신 버전을 실행하도록 하려면 다음 단계를 따르세요.

  • 출시 채널에 클러스터를 등록합니다. Autopilot 클러스터는 항상 출시 채널에 등록됩니다.
  • 출시 채널에 있는 클러스터의 경우 가속화된 패치 자동 업그레이드를 사용 설정하여 출시 채널에서 보안 패치 버전을 사용할 수 있게 되는 즉시 가져옵니다.
  • 출시 채널에 없는 표준 클러스터의 경우 자동 노드 업그레이드를 사용 설정합니다. 2019년 6월 이후Google Cloud 콘솔을 사용하여 생성된 클러스터와 2019년 11월 11일 이후 GKE API를 사용하여 생성된 클러스터에는 기본적으로 노드 자동 업그레이드가 사용 설정되어 있습니다.
  • 유지보수 정책을 사용하는 경우 유지보수 기간을 사용하여 GKE가 한 달에 한 번 이상 노드를 자동 업그레이드하도록 합니다.
  • 노드 자동 업그레이드를 사용하지 않는 노드 풀의 경우 자체 일정에 따라 한 달에 한 번 이상 노드 풀을 업그레이드하세요.
  • GKE 보안 게시판 및 GKE 출시 노트에서 보안 패치에 관한 정보를 확인하세요.

보안 게시판 알림 사용 설정

권장: 클러스터에 영향을 미치는 새로운 보안 게시판에 대한 알림을 구성합니다.

클러스터와 관련된 보안 게시판을 사용할 수 있으면 GKE가 해당 이벤트에 대한 알림을 사용자가 구성하는 Pub/Sub 주제에 대한 메시지로 게시합니다. Pub/Sub 구독에서 이러한 알림을 수신하고, 서드 파티 서비스와 통합하고, Cloud Logging에서 알림을 수신할 수 있습니다.

조직에서 이 권장사항을 적용하려면 constraints/container.managed.enableSecurityBulletinNotifications 관리 조직 정책 제약조건을 사용하세요. Google Cloud 콘솔에서 이 관리 제약 조건을 검토하려면 정책 세부정보 페이지로 이동하세요.

정책 세부정보로 이동

로그 수집 구성

권장: 운영 오버헤드를 줄이고 로그의 통합 보기를 유지하려면 클러스터 전반에서 일관된 로깅 전략을 구현하세요. Standard 클러스터에서 로그 수집을 사용 중지하지 마세요.

GKE 클러스터는 특정 로그를 Google Cloud Observability로 전송합니다. 원하는 경우 추가 유형의 로그 수집을 구성할 수 있습니다. 시스템 및 워크로드 로그 외에도 모든 GKE 클러스터는 다음 감사 로그를 Logging으로 전송합니다.

  • Kubernetes 감사 로그: Kubernetes API 서버로 전송된 호출을 시간순으로 기록합니다. Kubernetes 감사 로그 항목은 의심스러운 API 요청을 조사하거나, 통계를 수집하거나, 원치 않는 API 호출에 대한 모니터링 알림을 생성하는 데 유용합니다.
  • GKE 감사 로그: GKE API의 관리 및 액세스 활동 기록입니다.

자세한 내용은 다음 문서를 참조하세요.

조직에서 이 권장사항을 적용하려면 constraints/container.managed.enableCloudLogging 관리 조직 정책 제약조건을 사용하세요. Google Cloud 콘솔에서 이 관리 제약 조건을 검토하려면 정책 세부정보 페이지로 이동하세요.

정책 세부정보로 이동

리소스에서 보안 문제 모니터링

GKE 보안 상황 대시보드와 Security Command Center를 사용하여 클러스터와 워크로드에서 잠재적인 문제를 모니터링합니다. 이러한 서비스를 사용하여 GKE 인프라에 영향을 미치는 활성 취약점, 위협, 보안 게시판을 확인할 수 있습니다.

기본 보안 구성

다음 섹션에서는 취약점이나 위험과 같은 특정 보안 문제를 완화하기 위해 새 클러스터에서 기본적으로 구성되는 옵션을 설명합니다. 보안 엔지니어와 플랫폼 관리자는 기존 클러스터가 이러한 설정을 사용하는지 확인해야 합니다.

권장사항

기존 클라이언트 인증 방법 사용 안 함

권장: 정적 인증서 및 비밀번호와 같은 기존 API 서버 인증 방법을 사용 중지합니다.

Kubernetes API 서버에 인증하는 방법은 몇 가지가 있습니다. GKE에서 지원되는 방법은 서비스 계정 Bearer 토큰, OAuth 토큰, X.509 클라이언트 인증서입니다. gcloud CLI는 OAuth 토큰을 사용하여 GKE 사용자를 인증합니다.

정적 비밀번호와 같은 기존 인증 방법은 클러스터 손상의 공격 범위를 늘리므로 사용 중지됩니다. Autopilot 클러스터에서는 이러한 인증 방법을 사용 설정하거나 사용할 수 없습니다.

다음 방법 중 하나를 사용하여 Kubernetes API 서버에 인증합니다.

  • 사용자: gcloud CLI를 사용하여 GKE가 사용자를 인증하고, 클러스터의 OAuth 액세스 토큰을 생성하고, 토큰을 최신 상태로 유지하도록 합니다.
  • 애플리케이션: 워크로드 아이덴티티 제휴를 사용하여Google Cloud 또는 다른 환경의 애플리케이션이 클러스터에 인증하도록 합니다.

인증 방법 및 기존 인증 방법을 사용 중지하는 방법에 대한 자세한 내용은 Kubernetes API 서버에 인증을 참고하세요.

조직에서 이 권장사항을 적용하려면 constraints/container.managed.disableLegacyClientCertificateIssuance 관리 조직 정책 제약조건을 사용하세요. Google Cloud 콘솔에서 이 관리 제약 조건을 검토하려면 정책 세부정보 페이지로 이동하세요.

정책 세부정보로 이동

ABAC 사용 안 함

권장: IAM 및 RBAC를 사용하여 GKE에서 액세스를 제어합니다. 속성 기반 액세스 제어 (ABAC)를 사용 설정하지 마세요.

ABAC는 모든 GKE 클러스터에서 기본적으로 사용 중지되는 기존 승인 방법이며 Autopilot 클러스터에서는 사용 설정할 수 없습니다.

조직에서 이 권장사항을 적용하려면 constraints/container.managed.disableABAC 관리 조직 정책 제약조건을 사용하세요. Google Cloud 콘솔에서 이 관리 제약 조건을 검토하려면 정책 세부정보 페이지로 이동하세요.

정책 세부정보로 이동

DenyServiceExternalIPs 허용 컨트롤러를 사용 설정 상태로 유지

권장: DenyServiceExternalIPs 허용 컨트롤러를 사용 중지하지 마세요.

이 허용 컨트롤러는 서비스에 ExternalIP가 사용되지 않도록 차단하고 GCP-2020-015를 완화합니다. 이 허용 컨트롤러는 GKE 버전 1.21 이상에서 생성된 클러스터에서 기본적으로 사용 설정됩니다. 이전 GKE 버전에서 원래 생성된 클러스터의 경우 허용 컨트롤러를 사용 설정합니다.

gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --no-enable-service-externalips
조직에서 이 권장사항을 적용하려면 constraints/container.managed.denyServiceExternalIPs 관리 조직 정책 제약조건을 사용하세요. Google Cloud 콘솔에서 이 관리 제약 조건을 검토하려면 정책 세부정보 페이지로 이동하세요.

정책 세부정보로 이동

다음 단계