이 문서에서는 Google Kubernetes Engine(GKE)이 클러스터 제어 영역 구성요소를 보호하는 방법을 설명합니다.
공유 책임 모델에 따라 Google은 고객의 GKE 제어 영역 구성요소를 관리합니다. 제어 영역에는 Kubernetes API 서버, etcd 스토리지, 기타 컨트롤러가 포함됩니다. 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 보안 백서에서 관리 액세스를 참조하세요.
etcd 보안
Google Cloud에서 고객 콘텐츠는 기본적으로 파일 시스템 레이어 수준에서 암호화됩니다. 따라서 GKE 클러스터용 etcd 스토리지를 호스팅하는 디스크는 파일 시스템 레이어 수준에서 암호화됩니다. 자세한 내용은 저장 데이터 암호화를 참조하세요.
etcd는 TCP 포트 두 개에서 리슨합니다. 포트 2379는 Kubernetes API 서버와 마찬가지로 etcd 클라이언트를 위한 것입니다. 포트 2379는 로컬 루프백 네트워크 인터페이스에 결합되어 있으므로 Kubernetes API 서버를 실행하는 VM에서만 액세스할 수 있습니다. 포트 2380은 서버 간 통신용입니다. 포트 2380의 트래픽은 상호 TLS에 의해 암호화됩니다. 즉, 각 서버가 서로에게 신원을 증명해야 합니다. 리전 클러스터에서 쿼럼을 형성하는 etcd 서버 간 통신은 상호 TLS에 의해 암호화됩니다.
인증 기관 및 클러스터 트러스트
각 클러스터에는 자체적인 루트 인증 기관(CA)이 있습니다. 내부 Google 서비스가 이 CA의 루트 키를 관리합니다. 또한 클러스터마다 etcd에 대한 자체 CA가 있습니다. etcd CA의 루트 키는 Kubernetes API 서버를 실행하는 VM의 메타데이터에 배포됩니다. 노드와 Kubernetes API 서버 간의 통신은 TLS에 의해 보호됩니다. 자세한 내용은 클러스터 트러스트를 참조하세요.
취약점 및 패치 관리
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에서 관리합니다. 이 섹션과 다음 섹션은 고객이 모니터링하고 구성할 수 있는 보안 기능을 설명합니다.
감사 로깅은 기본적으로 GKE 버전 1.8.3 이후에 생성된 클러스터에 사용 설정됩니다. 이는 Kubernetes API 서버에 대한 호출의 자세한 기록(Google Cloud Observability에서 이용 가능)을 제공합니다. Google Cloud 콘솔의 로그 탐색기에서 로그 항목을 볼 수 있습니다. BigQuery를 사용하여 이 로그를 보고 분석할 수도 있습니다.
구성할 수 있는 항목
기본적으로 Kubernetes API 서버는 공개 IP 주소를 사용합니다. Kubernetes API 서버에 비공개 IP 주소를 할당하고 공개 IP 주소에서 액세스할 수 없도록 하는 승인된 네트워크와 비공개 클러스터를 사용하여 Kubernetes API 서버를 보호할 수 있습니다.
IAM을 ID 공급업체로 사용하여 GKE에서 클러스터 인증을 처리할 수 있습니다. 인증 보안을 강화하기 위해 기본 인증 및 클라이언트 인증서 발급은 GKE 버전 1.12 이상에서 생성된 클러스터에서 기본적으로 사용 중지됩니다.
정기적으로 사용자 인증 정보 순환을 수행하여 제어 영역의 보안을 강화할 수 있습니다. 사용자 인증 정보 순환이 시작되면 TLS 인증서와 클러스터 인증 기관이 자동으로 순환됩니다. GKE는 Kubernetes API 서버의 IP 주소도 순환합니다. 자세한 내용은 역할 기반 액세스 제어(RBAC) 및 사용자 인증 정보 순환을 참조하세요.