이 문서에서는 Google Kubernetes Engine (GKE)이 클러스터 컨트롤 플레인 구성요소를 보호하는 방법을 설명합니다. 이 문서에서는 사용자가 다음 사항을 알고 있다고 가정합니다.
이 문서는 Google에서 GKE 컨트롤 플레인 구성요소를 관리하는 방법과 위험을 효과적으로 평가하고 GKE 배포의 보안을 보장하기 위해 마련된 보안 조치를 이해하려는 보안 전문가를 대상으로 합니다.
GKE에는 보안 강화 OS, 강력한 아키텍처 및 격리, 보안 컨트롤 플레인 액세스, etcd 또는 Spanner 기반 클러스터 상태 데이터베이스 보안, 인증 기관 및 클러스터 신뢰, 취약점 및 패치 관리와 같은 기본 제공 보안 기능이 포함되어 있습니다.
공유 책임 모델에 따라 Google은 고객의 GKE 제어 영역 구성요소를 관리합니다. 제어 영역에는 Kubernetes API 서버, Kubernetes API 객체 스토리지, 기타 컨트롤러가 포함됩니다. Google에서 컨트롤 플레인의 보안을 책임지고 있지만, 특정 옵션을 고객의 요구사항에 맞춰 구성할 수도 있습니다. 노드, 컨테이너, 포드의 보안은 고객이 책임집니다.
강화된 운영체제
GKE 제어 영역 구성요소는 Google에서 설계하고 보안이 강화된 운영체제인 컨테이너 최적화 OS에서 실행됩니다. Container-Optimized OS에 기본 제공되는 보안 기능에 대한 자세한 내용은 Container-Optimized OS 보안 개요를 참조하세요.
아키텍처 및 격리
GKE 클러스터에서 제어 영역 구성요소는 Google 관리 프로젝트에 있는 Google 소유의 Compute Engine 인스턴스에서 실행됩니다. 각 인스턴스는 한 클러스터를 위해서만 이러한 구성요소를 실행합니다.
클러스터 구성요소가 서로 인증하는 방법에 대한 자세한 내용은 클러스터 신뢰를 참조하세요.
프로젝트에 대한 제어 영역 액세스
GKE는 Kubernetes Engine 서비스 에이전트라는 서비스 에이전트를 사용하여 노드, 디스크, 부하 분산기 등의 클러스터 리소스를 사용자를 대신하여 활성화합니다. 서비스 계정에는 프로젝트의 Kubernetes Engine 서비스 에이전트 역할(roles/container.serviceAgent)이 자동으로 부여됩니다.
Kubernetes Engine 서비스 에이전트의 이메일 주소는 다음과 같습니다.
service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com
이 이메일 주소에서 PROJECT_NUMBER는 프로젝트 번호입니다.
클러스터에 대한 관리 액세스
Google 사이트 신뢰성 엔지니어에 의한 SSH 세션은 Google의 내부 감사 인프라를 통해 감사 로깅됩니다. 이러한 인프라는 포렌식 및 보안 응답이 가능합니다. 자세한 내용은 Google 보안 백서에서 관리 액세스를 참조하세요.
클러스터 상태 데이터베이스 보안
Google Cloud에서 고객 콘텐츠는 기본적으로 파일 시스템 레이어에서 암호화됩니다. 이 암호화에는 클러스터의 Kubernetes API 객체 상태를 저장하는 etcd 또는 Spanner 기반 데이터베이스를 호스팅하는 인프라가 포함됩니다. 클러스터 상태 데이터베이스에 대한 자세한 내용은 GKE 클러스터 아키텍처를 참고하세요.
클러스터 상태 데이터베이스는 클러스터에 있는 모든 Kubernetes API 객체의 구성을 키-값 쌍으로 저장합니다. GKE는 클러스터 상태 데이터베이스와의 다음 유형의 통신을 위해 제어 영역 VM에서 특정 TCP 포트를 사용합니다.
etcd API 클라이언트: GKE는 모든 컨트롤 플레인 VM에서 etcd API를 제공합니다. 컨트롤 플레인의 etcd API 클라이언트(예: Kubernetes API 서버)는 다음 포트 중 하나를 사용합니다.
- 포트 2379: 이 포트는 GKE가 각 컨트롤 플레인 VM에서 실행되는 etcd 데이터베이스 인스턴스에 클러스터 상태를 저장할 때 사용됩니다.
- 포트 3379: 이 포트는 GKE가 컨트롤 플레인과 별도의 Spanner 데이터베이스에 클러스터 상태를 저장할 때 사용됩니다.
etcd API 클라이언트가 사용하는 포트는 로컬 루프백 네트워크 인터페이스에 바인딩되어 있으며 Kubernetes API 서버를 실행하는 컨트롤 플레인 VM에서만 액세스할 수 있습니다.
etcd 데이터베이스 인스턴스: 컨트롤 플레인 VM이 etcd 데이터베이스 인스턴스를 실행하는 경우 각 VM의 etcd API 서버는 포트 2380을 사용하여 서로 통신합니다. 여러 컨트롤 플레인 VM (예: 지역 클러스터)의 etcd 데이터베이스 인스턴스 간 포트 2380의 트래픽은 상호 TLS에 의해 암호화됩니다. 상호 TLS를 사용하면 각 서버가 서로에게 신원을 증명해야 합니다.
데이터베이스가 컨트롤 플레인 VM에서 실행되지 않으므로 Spanner 데이터베이스에 클러스터 상태를 저장하는 클러스터에서는 포트 2380이 사용되지 않습니다.
인증 기관 및 클러스터 트러스트
각 클러스터에는 자체적인 루트 인증 기관(CA)이 있습니다. 내부 Google 서비스가 이 CA의 루트 키를 관리합니다. 이 CA의 루트 키는 Kubernetes API 서버를 실행하는 VM의 메타데이터에 배포됩니다. 노드와 Kubernetes API 서버 간의 통신은 TLS에 의해 보호됩니다. 또한 클러스터마다 etcd API에 대한 자체 CA가 있으며, 클러스터가 etcd 데이터베이스 인스턴스를 실행하는 경우 etcd 인스턴스 간 트래픽에 대한 자체 CA가 있습니다. 자세한 내용은 클러스터 트러스트를 참고하세요.
취약점 및 패치 관리
GKE는 Google 표준을 준수하면서 변경사항을 테스트하고, 심사하고, 제어 영역에 점진적으로 롤아웃합니다. 따라서 제어 영역 구성요소를 사용할 수 없게 되는 위험이 최소화됩니다. GKE는 가용성의 여러 측면을 정의하는 서비스수준계약을 준수합니다.
GKE 제어 영역 구성요소는 Google 사이트 신뢰성 엔지니어 팀에 의해 관리되며, 최신 보안 패치를 통해 최신 상태로 유지됩니다. 여기에는 호스트 운영체제, Kubernetes 구성요소, 제어 영역 VM에서 실행 중인 컨테이너의 패치가 포함됩니다.
GKE는 새로운 커널, OS, Kubernetes 수준 수정사항을 제어 영역 VM에 즉시 적용합니다. 알려진 취약점에 대한 수정사항이 포함된 경우에는 GKE 보안 게시판에서 추가 정보가 제공됩니다. GKE는 Artifact Analysis를 사용하여 모든 Kubernetes 시스템과 GKE별 컨테이너에서 취약점을 검사하고 컨테이너를 계속 패치하므로 전체 Kubernetes 생태계에 유용합니다.
Google 엔지니어는 Kubernetes 보안 버그를 찾고, 수정하고, 공개하는 데 참여하고 있습니다. Google은 보안 버그를 찾기 위한 Google 전사적 취약점 보상 프로그램을 통해 외부 보안 연구원들에게 보상도 제공합니다. 2017년 10월의 dnsmasq 취약점과 같이 때로는 취약점이 공개적으로 알려지기 전에 GKE가 모든 실행 클러스터를 패치할 수 있었습니다.
볼 수 있는 항목
이전 섹션에서 설명한 보안 기능은 Google에서 관리합니다. 이 섹션과 구성할 수 있는 항목 섹션에서는 모니터링하고 구성할 수 있는 보안 기능을 설명합니다.
- 감사 로그: 감사 로깅은 기본적으로 사용 설정되어 있습니다. 이는 Kubernetes API 서버에 대한 호출의 자세한 기록(Google Cloud Observability에서 이용 가능)을 제공합니다.Google Cloud 콘솔의 로그 탐색기에서 로그 항목을 볼 수 있습니다. BigQuery를 사용하여 이 로그를 보고 분석할 수도 있습니다.
컨트롤 플레인 VM 이미지 무결성: GKE는 노드 VM 생성 및 부팅 이벤트에 대한 상세 로그를 Cloud Logging에 추가합니다. 또한 컨트롤 플레인 및 워커 노드 머신 이미지에 해당하는 SLSA VSA를 GitHub에 게시합니다. VM에서 해당 VSA가 있는 OS 이미지를 사용하는지 확인하고 각 컨트롤 플레인 VM의 부팅 무결성을 확인할 수 있습니다.
VM 무결성 확인을 수행하려면 GKE 컨트롤 플레인 VM 무결성 확인을 참조하세요.
구성할 수 있는 항목
GKE가 대부분의 컨트롤 플레인을 관리하지만 다음은 제어할 수 있습니다.
컨트롤 플레인 액세스: 컨트롤 플레인에는 클러스터 액세스를 위한 두 가지 종류의 엔드포인트가 있습니다.
- DNS 기반 엔드포인트
- IP 기반 엔드포인트
기본적으로 Kubernetes API 서버는 외부 IP 주소를 사용합니다. 컨트롤 플레인에 액세스하기 위한 DNS 기반 엔드포인트를 사용 설정하여 Kubernetes API 서버를 보호할 수 있습니다. VPC 서비스 제어를 사용하여 DNS 엔드포인트에 액세스할 수 있는 사용자를 제어할 수 있습니다. VPC 서비스 제어를 사용하면 프로젝트의 모든 Google API에 대한 하나의 보안 파라미터를 정의할 수 있습니다. 컨트롤 플레인 액세스에 IP 기반 엔드포인트를 사용하는 경우 승인된 네트워크를 사용하고 컨트롤 플레인 외부 엔드포인트에서 액세스를 사용 중지하는 것이 좋습니다. 네트워크 격리에 관한 자세한 내용은 네트워크 격리 맞춤설정 정보를 참고하세요.
인증: IAM을 ID 공급업체로 사용하여 GKE에서 클러스터 인증을 처리할 수 있습니다. 인증 보안을 강화하기 위해 기본 인증 및 클라이언트 인증서 발급은 기본적으로 사용 중지됩니다.
사용자 인증 정보 순환: 사용자 인증 정보 순환을 실행하여 클러스터 인증 기관 (CA)과 TLS 인증서를 정기적으로 순환합니다. 이 과정에서 GKE는 Kubernetes API 서버의 IP 주소도 순환합니다. 자세한 내용은 사용자 인증 정보 순환을 참고하세요.
또한 조직에 컨트롤 플레인과 관련된 엄격한 규정 준수 또는 정책 요구사항이 있는 경우 GKE 컨트롤 플레인 권한은 다음을 비롯한 컨트롤 플레인의 특정 측면에 대한 가시성과 제어 기능을 향상하는 기능 집합입니다.
- Cloud KMS 및 CA 서비스를 사용하여 ID 발급을 위한 자체 CA와 키를 실행합니다.
- Cloud KMS에서 자체 키를 사용하여 etcd 및 컨트롤 플레인 부팅 디스크를 암호화합니다.
이러한 기능을 사용하는 이유와 사용 가능한 모든 기능에 대한 자세한 내용은 GKE control plane authority 정보를 참고하세요.