제어 영역 보안

이 문서는 Google Kubernetes Engine에서 클러스터 제어 영역 구성요소를 보호하는 방법을 설명합니다.

공유 책임 모델에 따라 Google은 고객의 GKE 제어 영역 구성요소를 대신 관리합니다. 제어 영역에는 Kubernetes API 서버, etcd, 다수의 컨트롤러가 포함됩니다. Google에서 제어 영역의 보안을 책임지고 있지만, 특정 옵션을 고객의 요구사항에 맞춰 구성할 수도 있습니다. 노드, 컨테이너, 포드의 보안은 고객이 책임집니다.

강화된 운영체제

GKE 제어 영역 구성요소는 Google에서 디자인한 보안이 강화된 운영체제인 Container-Optimized OS에서 실행됩니다. Container-Optimized OS에 내장된 보안 기능에 대한 자세한 설명은 컨테이너 최적화 OS 보안 개요를 참조하세요.

아키텍처 및 격리

GKE 클러스터에서 제어 영역 구성요소는 Google이 관리하는 서버에 있는 Google 소유의 Compute Engine 인스턴스에서 실행됩니다. 각 인스턴스는 단 한 고객을 위해서만 이 구성요소를 실행합니다.

Kubernetes API 서버 및 etcd의 인증은 다른 Google Cloud 서비스에서와 동일한 방식으로 수행됩니다. 애플리케이션 레이어 전송 보안(ALTS)이 이러한 통신을 보호합니다.

클러스터에 대한 관리 액세스

Google 사이트 신뢰성 엔지니어에 의한 SSH 세션은 Google의 내부 감사 인프라를 통해 감사 로깅됩니다. 이러한 인프라는 포렌식 및 보안 응답이 가능합니다. 자세한 내용은 Google 보안 백서에서 관리 액세스를 참조하세요.

etcd 보안

Google Cloud Platform에서 고객 콘텐츠는 기본적으로 파일 시스템 레이어 수준에서 암호화됩니다. 따라서 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는 Container Registry 취약점 스캔을 사용하여 모든 Kubernetes 시스템과 GKE별 컨테이너에서 취약점을 스캔하고 컨테이너를 계속 패치함으로써 전체 Kubernetes 에코시스템에 유용합니다.

Google 엔지니어는 Kubernetes 보안 버그를 찾고, 수정하고, 공개하는 데 참여하고 있습니다. 그리고 Google은 보안 버그를 찾기 위한 Google 전사적 취약점 보상 프로그램을 통해 외부 보안 연구원들에게 보상을 제공합니다. 2017년 10월의 dnsmasq 취약점과 같이 때로는 취약점이 공개적으로 알려지기 전에 GKE가 모든 실행 클러스터를 패치했을 수도 있습니다.

볼 수 있는 항목

이 주제의 앞부분에서 언급한 보안 기능은 Google에서 관리합니다. 이 섹션과 다음 섹션은 고객이 모니터링하고 구성할 수 있는 보안 기능을 설명합니다.

감사 로깅은 출시 버전 1.8.3 이후에 만들어진 클러스터에 대해 기본적으로 사용 설정되어 있습니다. 따라서 Kubernetes API 서버 호출에 관한 자세한 기록을 Stackdriver에서 볼 수 있습니다. GCP Console의 로그 페이지에서 로그 항목을 볼 수 있습니다. BigQuery를 사용하여 이 로그를 보고 분석할 수도 있습니다.

구성할 수 있는 항목

기본적으로 Kubernetes API 서버는 공개 IP 주소를 사용합니다. Kubernetes API 서버에 비공개 IP 주소를 할당하고 공개 IP 주소에서 액세스하지 못하도록 하는 마스터 승인 네트워크비공개 클러스터를 사용하여 Kubernetes API 서버를 보호할 수 있습니다.

Cloud IAM을 ID 공급업체로 사용하여 GKE에서 클러스터 인증을 처리할 수 있습니다. MasterAuth 구성에서 빈 사용자 이름과 비밀번호를 설정하여 기본 인증을 사용 중지해야 합니다. 또한 같은 구성에서 클라이언트 인증서를 사용 중지하면 클러스터에 대한 액세스를 잠글 때 고려할 키가 하나 줄어듭니다.

사용자 인증 정보 순환을 정기적으로 수행함으로써 제어 영역의 보안을 강화할 수 있습니다. 사용자 인증 정보 순환이 시작되면 TSL 인증서와 클러스터 인증 기관이 자동으로 순환됩니다. GKE는 Kubernetes API 서버의 IP 주소도 순환합니다. 자세한 내용은 역할 기반 액세스 제어사용자 인증 정보 순환을 참조하세요.

다음 단계

이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...

Kubernetes Engine