CIS 벤치마크

이 페이지에서는 Google Kubernetes Engine(GKE)에서 Kubernetes 및 GKE의 인터넷 보안 센터(CIS) 벤치마크 준수를 개선하기 위해 취하는 방법을 설명합니다. 이 페이지에는 다음 정보가 포함되어 있습니다.

  • CIS Kubernetes 벤치마크를 준수하도록 관리형 GKE 컨트롤 플레인을 구성하는 방법
  • CIS Google Kubernetes Engine(GKE) 벤치마크를 준수하도록 GKE 노드와 워크로드를 구성하는 방법

CIS 벤치마크 정보

CIS는 Kubernetes의 보안 구성 가이드라인이 포함된 다음 벤치마크를 출시합니다.

  • CIS Kubernetes 벤치마크: 오픈소스 Kubernetes 프로젝트에 적용됩니다. 이는 다양한 자체 관리형 및 호스팅된 Kubernetes 구현에 대한 안내를 제공하기 위함입니다.
  • CIS GKE 벤치마크: GKE 클러스터에서 제어할 수 있는 구성요소의 보안 구성에 대한 가이드라인을 설정합니다. Google Cloud의 GKE에 대한 권장사항이 포함됩니다.

CIS GKE 벤치마크를 우선시하는 것이 좋습니다. Google Cloud의 GKE에만 해당되기 때문입니다. CIS Kubernetes 벤치마크에는 GKE에서 보거나 수정할 수 없는 제어에 대한 다양한 권장사항이 포함되어 있습니다. Google의 클러스터 보안 방법에는 오픈소스 Kubernetes 벤치마크의 범위를 벗어나고 이러한 권장사항과 충돌할 수 있는 완화 조치가 포함됩니다.

GKE에 적용되는 기타 벤치마크

CIS GKE 벤치마크와 CIS Kubernetes 벤치마크 외에도 다음 벤치마크가 GKE에서 사용할 수 있는 운영체제에 적용됩니다. 특정 OS 벤치마크에서 Kubernetes 사용을 명시적으로 다루지 않더라도 추가 보안 안내를 위해 해당 벤치마크를 계속 참조해야 합니다.

기본 컨테이너 런타임인 containerd에는 벤치마크가 없습니다.

공유 책임 모델

Google은 GKE 공유 책임 모델에 따라 다음 구성요소를 자동으로 관리합니다.

  • 컨트롤 플레인 VM, API 서버, 구성요소(예: etcd, kube-controller-manager, kube-scheduler)가 포함된 컨트롤 플레인
  • 노드 운영체제

이러한 구성요소는 GKE에서 소유한 프로젝트에 있으므로 해당 CIS 벤치마크 컨트롤에 대해 이러한 구성요소를 수정하거나 평가할 수 없습니다. 하지만 워커 노드와 워크로드에 적용되는 CIS 벤치마크 제어를 평가하고 해결할 수 있습니다. GKE 공유 책임 모델에 따라 개발자가 이러한 구성요소를 담당합니다.

CIS 벤치마크를 위한 Google의 GKE 보안 강화 방법

GKE는 오픈소스 Kubernetes의 관리형 구현입니다. Google은 컨트롤 플레인을 완전히 관리하고 컨트롤 플레인 구성요소 구성을 보호할 책임이 있습니다. 다음 표에는 CIS 벤치마크의 점수에 영향을 줄 수 있는 Google의 결정사항 일부가 나와 있습니다.

GKE 보안 방법
인증
  • 일부 GKE 모니터링 구성요소에는 측정항목을 얻기 위해 익명 인증이 사용됩니다. GKE에서는 kubelet에 대해 익명 인증이 허용되지만 추가 디버깅 핸들러가 사용 중지되므로 노출은 읽기 전용 포트와 동일합니다.
  • 일부 컨트롤 플레인 구성요소는 정적 토큰을 통해 부트스트랩된 후 API 서버 인증에 사용됩니다. 이러한 토큰은 VM이 시작되거나 다시 시작될 때마다 생성됩니다.
허용 컨트롤러

GKE는 다음 허용 컨트롤러를 사용 중지합니다.

  • EventRateLimit: Kubernetes의 알파 기능입니다.
  • AlwaysPullImages: 이 컨트롤러는 클러스터에 새 포드를 만들기 위해 이미지 레지스터를 단일 장애점으로 만드는 대신 비협업 멀티테넌트 클러스터의 비공개 레지스트리 이미지에 대한 일부 보호를 제공합니다.
  • SecurityContextDeny: 포드 보안 허용 컨트롤러가 선호되며 모든 GKE 버전에서 사용 가능합니다. GKE Enterprise를 사용하는 경우 정책 컨트롤러를 사용하여 포드 보안 표준을 적용할 수도 있습니다.
  • ImagePolicyWebhook: GKE에는 이미지 관리 및 보안을 위한 자체 메커니즘이 있으므로 기본적으로 ImagePolicyWebhook가 사용 중지됩니다. 이를 통해 GKE는 환경을 더 엄격하게 제어하고 보안 관행이 일관되게 적용되도록 보장할 수 있습니다. 하지만 정책 관리에 Binary Authorization 또는 정책 컨트롤러를 사용할 수 있습니다.
감사 로깅 GKE는 GKE 감사 정책을 사용하여 감사 로그를 캡처합니다. 따라서 Kubernetes API 서버 감사 로깅 플래그를 설정할 필요가 없습니다.
디버깅 GKE는 디버깅용 프로파일링을 사용합니다.
암호화
kubelet
  • GKE는 인증되지 않은 kubelet 읽기 전용 포트를 사용 설정합니다.
  • GKE Standard 모드를 사용하면 워크로드에서 필요한 경우 커널 기본값을 수정할 수 있습니다.
  • GKE는 DoS 공격의 위험을 줄이기 위해 kubelet의 Kubernetes 이벤트 수를 제한합니다.
  • GKE는 mTLS를 사용하여 kubelet과 API 서버 간의 트래픽을 보호합니다.
  • GKE는 기본적으로 서버 인증서를 순환하고 보안 GKE 노드가 사용 설정되면 클라이언트 인증서를 순환합니다.
  • GKE는 Kubernetes의 기본값이기도 한 golang 기본 허용 암호화 세트를 사용합니다.

CIS 벤치마크에 따라 GKE 평가

다음 방법 중 하나를 사용하여 벤치마크에 대한 클러스터 평가를 자동화할 수 있습니다.

  • CIS GKE 벤치마크:

    • 모든 GKE 버전:
      • kube-bench를 실행하여 벤치마크를 기준으로 워커 노드를 평가합니다. 자세한 내용은 kube-bench GitHub 저장소를 참조하세요.
      • Twistlock Defender와 같은 서드 파티 도구를 사용하여 벤치마크를 기준으로 노드를 평가합니다.
    • GKE Enterprise 버전: 규정 준수 대시보드를 사용하여 모든 클러스터가 CIS GKE 벤치마크를 준수하는지 평가합니다. 자세한 내용은 GKE Compliance 대시보드 정보를 참조하세요.

  • CIS Kubernetes 벤치마크: kube-bench를 실행하여 벤치마크를 기준으로 워커 노드를 평가합니다. 벤치마크의 권장사항에 따라 관리형 컨트롤 플레인을 평가할 수 없습니다.

다음 단계